Re: kernel 100% CPU

[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 to
>> narrow it down.
>
>
> I had what might be the same issue this afternoon, for the first time in
> weeks. With the slowdown, it took a few minutes for me to find your
> email, unfortunately the symptoms subsided moments before finding it.
>
> So, I collected the information, but it's probably another missed
> opportunity (the information collected too late).
>
> The busy period lasted for around six minutes:
>
> root@mowa219-gjp4-8570p-freebsd:~ # poudriere bulk -j main -J 3 -Ctv
> devel/pkgconf
> [00:00:00] Creating the reference jail... done
> [00:00:01] Mounting system devices for main-default
> [00:00:02] Warning: Using packages from previously failed, or
> uncommitted, build:
> /usr/local/poudriere/data/packages/main-default/.building
> [00:00:02] Mounting ccache from: /usr/.ccache
> [00:00:02] Mounting ports from: /usr/local/poudriere/ports/default
> [00:00:02] Mounting packages from:
> /usr/local/poudriere/data/packages/main-default
> [00:00:02] Mounting distfiles from: /usr/ports/distfiles
> [00:00:02] Copying /var/db/ports from:
> /usr/local/etc/poudriere.d/main-options
> [00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> /etc/resolv.conf ->
> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
> [00:00:02] Starting jail main-default
> [00:00:02] Will build as nobody:nobody (65534:65534)
> [00:00:05] Logs:
> /usr/local/poudriere/data/logs/bulk/main-default/2023-10-14_16h16m30s
> [00:00:05] Loading MOVED for
> /usr/local/poudriere/data/.m/main-default/ref/usr/ports
> [00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
> [00:00:06] Inspecting ports tree for modifications to git checkout... yes
> [00:06:39] Ports top-level git hash: e843b8293c (dirty)
> …
>

sysctl output you pasted privately shows you are running a kernel form
October 9th, fee14577d590. This predates a slew of fixes to vnlru I
committed the day after.

They fix some of the problems (not all of them!), but it should be good enough.

tl;dr just update to newest main and it should be fine.

-- 
Mateusz Guzik 

Re: kernel 100% CPU

[Graham Perrin]

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 
weeks. With the slowdown, it took a few minutes for me to find your 
email, unfortunately the symptoms subsided moments before finding it.


So, I collected the information, but it's probably another missed 
opportunity (the information collected too late).


The busy period lasted for around six minutes:

root@mowa219-gjp4-8570p-freebsd:~ # poudriere bulk -j main -J 3 -Ctv 
devel/pkgconf

[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for main-default
[00:00:02] Warning: Using packages from previously failed, or 
uncommitted, build: 
/usr/local/poudriere/data/packages/main-default/.building

[00:00:02] Mounting ccache from: /usr/.ccache
[00:00:02] Mounting ports from: /usr/local/poudriere/ports/default
[00:00:02] Mounting packages from: 
/usr/local/poudriere/data/packages/main-default

[00:00:02] Mounting distfiles from: /usr/ports/distfiles
[00:00:02] Copying /var/db/ports from: 
/usr/local/etc/poudriere.d/main-options

[00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf

[00:00:02] Starting jail main-default
[00:00:02] Will build as nobody:nobody (65534:65534)
[00:00:05] Logs: 
/usr/local/poudriere/data/logs/bulk/main-default/2023-10-14_16h16m30s
[00:00:05] Loading MOVED for 
/usr/local/poudriere/data/.m/main-default/ref/usr/ports

[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:06] Inspecting ports tree for modifications to git checkout... yes
[00:06:39] Ports top-level git hash: e843b8293c (dirty)
…

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

[Graham Perrin]

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 https://git.freebsd.org/ports.git` work for you?
(currently it's not working from where I am). Maybe related.

Best
Michael


Today, yes.

Sorry for not replying sooner, Gmail sent your 2nd September email to spam.

% pwd
/tmp
% time git clone https://git.freebsd.org/ports.git && rm -r ports
Cloning into 'ports'...
remote: Enumerating objects: 5943170, done.
remote: Counting objects: 100% (943/943), done.
remote: Compressing objects: 100% (127/127), done.
remote: Total 5943170 (delta 923), reused 816 (delta 816), pack-reused 
5942227

Receiving objects: 100% (5943170/5943170), 1.11 GiB | 6.29 MiB/s, done.
Resolving deltas: 100% (3586216/3586216), done.
Updating files: 100% (156931/156931), done.
941.630u 59.980s 10:11.66 163.7%    +442k 14+0io 58pf+16w
override r--r--r-- grahamperrin/wheel for 
ports/.git/objects/pack/pack-d72c55d78249720bb87ae380c69ecb3c6dc5fe94.idx? 
^C

% sudo rm -r /tmp/ports
grahamperrin's password:
%

Re: kernel 100% CPU

[Mateusz Guzik]

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 begin a trace and then reproduce the
> issue
> (before the trace ends)?
>
> …
 Looks like you have a lot of unrelated traffic in there.

 …
>>> Instead,  the
>>> two files from 09:21 this morning. Are these useful?
>>>
>>> Before this run of DTrace, I quit Firefox and other applications that
>>> might be causing noise (and the OS has been restarted since my last run
>>> of poudriere-bulk(8)).
>>>
>>> dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count();
>>> } tick-60s { exit(0); }' -o out.kern_stacks
>>>
>> Post your "sysctl -a" somewhere.
>>
> sysctl-a-2023-09-03-18-22.txt added to the MEGA folder is complete,
> including TSLOG-related lines.
>
> Alternatively, tslog under
>  is automatically
> pruned to exclude such lines. Hopefully not excessively pruned.
>
> TSLOG is one of three things in a Git stash that I apply before most
> builds, .
>

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.

-- 
Mateusz Guzik 

Re: kernel 100% CPU

[Graham Perrin]

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

…

Looks like you have a lot of unrelated traffic in there.

…

Instead,  the
two files from 09:21 this morning. Are these useful?

Before this run of DTrace, I quit Firefox and other applications that
might be causing noise (and the OS has been restarted since my last run
of poudriere-bulk(8)).

dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count();
} tick-60s { exit(0); }' -o out.kern_stacks


Post your "sysctl -a" somewhere.

sysctl-a-2023-09-03-18-22.txt added to the MEGA folder is complete, 
including TSLOG-related lines.


Alternatively, tslog under 
 is automatically 
pruned to exclude such lines. Hopefully not excessively pruned.


TSLOG is one of three things in a Git stash that I apply before most 
builds, .

Re: kernel 100% CPU

[Mateusz Guzik]

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 like you have a lot of unrelated traffic in there.
>>
>> …
>
> Instead,  the
> two files from 09:21 this morning. Are these useful?
>
> Before this run of DTrace, I quit Firefox and other applications that
> might be causing noise (and the OS has been restarted since my last run
> of poudriere-bulk(8)).
>
> dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count();
> } tick-60s { exit(0); }' -o out.kern_stacks
>

Post your "sysctl -a" somewhere.


-- 
Mateusz Guzik 

Re: kernel 100% CPU

[Graham Perrin]

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.

…


Instead,  the 
two files from 09:21 this morning. Are these useful?


Before this run of DTrace, I quit Firefox and other applications that 
might be causing noise (and the OS has been restarted since my last run 
of poudriere-bulk(8)).


dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count(); 
} tick-60s { exit(0); }' -o out.kern_stacks

Re: kernel 100% CPU

[Graham Perrin]

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: 
<https://lists.freebsd.org/archives/freebsd-current/2023-September/004539.html>, 
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

[Mateusz Guzik]

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 guess that I'm still doing something wrong:
>
>
> root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu
>
> # time dtrace -s script.d -o /tmp/out
> dtrace: script 'script.d' matched 4 probes
> ^C0.246u 4.049s 27:25.70 0.2%   14+91k 261+0io 274pf+0w
> root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu
>
> # cat /tmp/out
>
> CPU IDFUNCTION:NAME
>3  2 :END
>
> root@mowa219-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 

Re: kernel 100% CPU

[Graham Perrin]

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:


root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
# time dtrace -s script.d -o /tmp/out

dtrace: script 'script.d' matched 4 probes
^C0.246u 4.049s 27:25.70 0.2%   14+91k 261+0io 274pf+0w
root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
# cat /tmp/out


CPU ID    FUNCTION:NAME
  3  2 :END

root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
#

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

[Michael Gmelin]

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 for you?
(currently it's not working from where I am). Maybe related.

Best
Michael


-- 
Michael Gmelin

Re: kernel 100% CPU

[Juraj Lutter]

> 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” line).


—
Juraj Lutter
o...@freebsd.org

Re: kernel 100% CPU

[Graham Perrin]

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 threads.
  */

sched:::off-cpu
/execname == "find"/
{
 self->ts = timestamp;
}

sched:::on-cpu
/self->ts/
{
 @offcpu[stack(30), "offcpu"] = sum(timestamp - self->ts);
 self->ts = 0;
}

dtrace:::END
{
 normalize(@offcpu, 100);
 printa("%k\n%s\n%@d\n\n", @offcpu);
 printa("%k\n%s\n%@d\n\n", @oncpu);
}

dtrace -s script.d -o out



# pwd
/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu
# ./2023-09-02-18-31.sh
./2023-09-02-18-31.sh: profile:::profile-997: not found
./2023-09-02-18-31.sh: /execname: not found
./2023-09-02-18-31.sh: 6: Syntax error: "(" unexpected (expecting "}")
# whoami
root
# echo $
$
# echo $0
sh
# echo $SHELL
/bin/csh
# exit
root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
#

Re: kernel 100% CPU …

[Graham Perrin]

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


% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT 
amd64 150 #11 main-n265135-07bc20e4740d-dirty: Sat Sep  2 19:40:08 
BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 150 150

%

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily 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 took more than half an hour.
>>>
>>> Anyone else?
>>>
>>> A screenshot: 
>>>
>>> % pkg iinfo poudriere-devel
>>> poudriere-devel-3.3.99.20220831
>>> % uname -aKU
>>> FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
>>> amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31
>>> BST 2023
>>> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
>>>
>>> amd64 150 150
>>> %
>> get a flamegraph with dtrace
>>
>> https://github.com/brendangregg/FlameGraph
>
> Thanks! TIL, it's ported.
>
> Graph attached, as a PNG, although I don't know whether it'll be useful,
> because 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)?
>
> 
>
> root@mowa219-gjp4-8570p-freebsd:/tmp # dtrace -x stackframes=100 -n
> 'profile-997 /arg0/ { @[stack()] = count(); } tick-60s { exit(0); }' -o
> out.kern_stacks
> dtrace: description 'profile-997 ' matched 2 probes
> root@mowa219-gjp4-8570p-freebsd:/tmp # stackcollapse.pl out.kern_stacks
>  > out.kern_folded
> root@mowa219-gjp4-8570p-freebsd:/tmp # flamegraph.pl out.kern_folded >
> kernel.svg
> root@mowa219-gjp4-8570p-freebsd:/tmp #
>

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 threads.
 */

sched:::off-cpu
/execname == "find"/
{
self->ts = timestamp;
}

sched:::on-cpu
/self->ts/
{
@offcpu[stack(30), "offcpu"] = sum(timestamp - self->ts);
self->ts = 0;
}

dtrace:::END
{
normalize(@offcpu, 100);
printa("%k\n%s\n%@d\n\n", @offcpu);
printa("%k\n%s\n%@d\n\n", @oncpu);
}

dtrace -s script.d -o out

this can be fed to generate a flamegraph the same way; upload it to freefall

-- 
Mateusz Guzik 

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

[Alexander Motin]

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, the original SVG was scalable and searchable in browser.  Your 
PNG inside PDF is not.


--
Alexander Motin

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

[Graham Perrin]

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 iinfo poudriere-devel
poudriere-devel-3.3.99.20220831
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31
BST 2023
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

amd64 150 150
%




get a flamegraph with dtrace

https://github.com/brendangregg/FlameGraph


Thanks!

See  for a 
PDF of a reply that probably did not reach the list.

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

[Mateusz Guzik]

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
> poudriere-devel-3.3.99.20220831
> % uname -aKU
> FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
> amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31
> BST 2023
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
>
> amd64 150 150
> %
>
>
>

get a flamegraph with dtrace

https://github.com/brendangregg/FlameGraph

-- 
Mateusz Guzik 

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

[Graham Perrin]

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 mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT 
amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31 
BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 150 150

%

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

[Ngie Cooper (yaneurabeya)]

> 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 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 head version of syslogd only, maybe MFC'd to stable/11, but
>>> not released.  If it was MFC'd we need to fix it before the 11.1 release.
>> 
>> This was a syslogd from head for sure.
>> 
>> So the issue was that for an intermediate period of time a bug was in
>> syslogd in head which was causing this, and if I would have upgraded a
>> system were the jail would have been head from before the or after the
>> bug, then I wouldn't have noticed it?
>> 
> 
> Yes, that's my understanding.  So it's ultimately a non-issue for
> releases since it is just a temporary issue on head.

Yes. syslogd was refactored on ^/head. Some of the refactoring caused the issue 
Alexander brought up. The changes were never backported though, so the concern 
you had in the previous message isn’t something to be worried about, since the 
code hasn’t seen the changes the ^/head copy has.
Cheers!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Bryan Drewery]

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 revision is the syslogd? From my understanding the bug
>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
>> not released.  If it was MFC'd we need to fix it before the 11.1 release.
> 
> This was a syslogd from head for sure.
> 
> So the issue was that for an intermediate period of time a bug was in
> syslogd in head which was causing this, and if I would have upgraded a
> system were the jail would have been head from before the or after the
> bug, then I wouldn't have noticed it?
> 

Yes, that's my understanding.  So it's ultimately a non-issue for
releases since it is just a temporary issue on head.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Alexander Leidinger]

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 head version of syslogd only, maybe MFC'd to stable/11, but
not released.  If it was MFC'd we need to fix it before the 11.1 release.


This was a syslogd from head for sure.

So the issue was that for an intermediate period of time a bug was in  
syslogd in head which was causing this, and if I would have upgraded a  
system were the jail would have been head from before the or after the  
bug, then I wouldn't have noticed it?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp2kvZESRNjH.pgp
Description: Digitale PGP-Signatur

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

[Alexander Leidinger]

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 COMPAT_FREEBSD32
options COMPAT_FREEBSD10
options COMPAT_FREEBSD11
---snip---


new kernel and new syslog = OK

Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpoa2pSQdNGR.pgp
Description: Digitale PGP-Signatur