https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193386
--- Comment #1 from Rodney W. Grimes ---
Please do not put bugs on stable@, current@, hackers@, etc
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193364
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--- Comment #5 from Rodney W.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229694
--- Comment #4 from Rodney W. Grimes ---
Please do not put bugs on stable@, current@, hackers@, etc
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230620
Rodney W. Grimes changed:
What|Removed |Added
Assignee|sta...@freebsd.org |b...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169898
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |rgri...@freebsd.org
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169898
Rodney W. Grimes changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221146
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--- Comment #25 from Rodney
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--- Comment #57 from Rodney
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213
Rodney W. Grimes changed:
What|Removed |Added
Assignee|sta...@freebsd.org |b...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193360
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |rgri...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
Rodney W. Grimes changed:
What|Removed |Added
CC||rgri...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--- Comment #16 from Rodney
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Rodney W. Grimes changed:
What|Removed |Added
CC|sta...@freebsd.org |
--- Comment #15 from Rodney
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006
--- Comment #15 from commit-h...@freebsd.org ---
A commit references this bug:
Author: mm
Date: Tue Feb 12 23:24:47 UTC 2019
New revision: 344065
URL: https://svnweb.freebsd.org/changeset/base/344065
Log:
MFV r344063:
Sync libarchive
Thanks guys! That was fast
On 12/02/2019 20:13, Kristof Provost wrote:
On 2019-02-12 13:54:21 (-0600), Eric van Gyzen wrote:
> I see the same behavior on head (and stable/12).
>
> (kgdb) f
> #16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800,
> m=0xf8000c88b100)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #14 from Andrey V. Elsukov ---
(In reply to Sergey Anokhin from comment #13)
> (In reply to Andrey V. Elsukov from comment #11)
>
> I'd preferred to try to rebuild kernel if it's no difference between turning
> off VIMAGE from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #13 from Sergey Anokhin ---
(In reply to Andrey V. Elsukov from comment #11)
I'd preferred to try to rebuild kernel if it's no difference between turning
off VIMAGE from kernel config and applying patch because kernel building
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #12 from Sergey Anokhin ---
(In reply to Andrey V. Elsukov from comment #9)
Sure, now I'm building kernel without VIMAGE. I'll let you know about testing
result
--
You are receiving this mail because:
You are on the CC list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006
--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:
Author: mm
Date: Tue Feb 12 22:29:45 UTC 2019
New revision: 344063
URL: https://svnweb.freebsd.org/changeset/base/344063
Log:
Update vendor/libarchive/dist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #11 from Andrey V. Elsukov ---
Created attachment 201968
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201968=edit
Proposed patch
Also, you can test this patch instead, it should fix panic with VIMAGE option.
The
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #10 from Sergey Anokhin ---
(In reply to Jan Bramkamp from comment #6)
Will it ok?
(pts/1)[root@server:~]# sysctl kern.maxssiz=1073741824
kern.maxssiz: 536870912 -> 1073741824
(pts/1)[root@server:~]#
Hello Eugene,
Tuesday, February 12, 2019, 10:18:09 PM, you wrote:
>> I'm have same problem.
>>
>> According to top(1) I have 29G Wired, but only 17G Total ARC (12G
>> difference! System has 32G of RAM), and this statistic shows:
>>
>> 5487.5 zio_data_buf_524288
>>920.125
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #9 from Andrey V. Elsukov ---
Can you try to remove `option VIMAGE` from your kernel config? It looks like
the problem is similar to the one described in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235699
--
You are
On 2019-02-12 13:54:21 (-0600), Eric van Gyzen wrote:
> I see the same behavior on head (and stable/12).
>
> (kgdb) f
> #16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800,
> m=0xf8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468
> 468 switch
On 2/12/19 8:53 AM, Pete French wrote:
> I found my panic. If I take everything out of rc.conf and loader.conf
> and sysctl.conf and boot the system it works fine when I add an IP
> address. If I add this one line to sysctl.conf
>
> net.link.ether.inet.garp_rexmit_count=2
>
> Then I get a
On 2/12/2019 2:38 PM, Eugene Grosbein wrote:
>
> mbuf* numbers represent memory being wasted IMHO.
>
> In contrast to ZFS memory that can contain useful cached data,
> contents of freed mbufs cannot be re-used, right?
>
> Some amount of "free" mbufs in the zone's just fine to serve bursts of
13.02.2019 2:18, Mike Tancsa wrote:
> On an nfs server, serving a few large files, my 32G box is showing
>
> vmstat -z | sed 's/:/,/' | awk -F, '{printf "%10s %s\n",
> $2*$5/1024/1024, $1}' | sort -k1,1 -rn | head
>11014.3 abd_chunk
> 2090.5 zio_data_buf_131072
>1142.67
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #8 from Sergey Anokhin ---
(In reply to Jan Bramkamp from comment #6)
Did you mean try to set kern.maxssiz into /boot/loader.conf?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #7 from Sergey Anokhin ---
btw, perhaps it can be helpful: if port security/ipsec-tools was built with
default options (make rmconfig), so the bug doesn't reproduced
--
You are receiving this mail because:
You are on the CC
On 2/12/2019 1:03 PM, Eugene Grosbein wrote:
> It seems page daemon is broken somehow as it did not reclaim several
> gigs of wired memory
> despite of long period of vm thrashing:
>
> $ sed 's/:/,/' vmstat-z.txt | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024,
> $1}' | sort -k1,1 -rn | head
>
13.02.2019 1:50, Lev Serebryakov wrote:
> I'm have same problem.
>
> According to top(1) I have 29G Wired, but only 17G Total ARC (12G
> difference! System has 32G of RAM), and this statistic shows:
>
> 5487.5 zio_data_buf_524288
>920.125 zio_data_buf_131072
>626
13.02.2019 1:18, Mark Johnston wrote:
> Depending on the system's workload, it is possible for the caches to
> grow quite quickly after a reclaim. If you are able to run kgdb on the
> kernel, you can find the time of the last reclaim by comparing the
> values of lowmem_uptime and time_uptime.
On Mon, Feb 11, 2019 at 12:31:19AM +0700, Eugene Grosbein wrote:
> Hi!
>
> Why our 32-bit run-time linker looks for shared libraries in the
> /usr/local/lib despite of its absence in /var/run/ld-elf32.so.hints
> while 32-bit binary is started under FreeBSD 11.2-STABLE/amd64 ?
Most likely because
On 12.02.2019 21:48, Eugene Grosbein wrote:
> I will reach the console next day only. Is it wise to use kgdb over ssh for
> running remote system? :-)
It works for me :-)
BTW, my is:
(kgdb) p time_uptime
$1 = 81369
(kgdb) p lowmem_uptime
$2 = 0
(yes, this system have been rebooted less than
On Wed, Feb 13, 2019 at 01:48:21AM +0700, Eugene Grosbein wrote:
> 13.02.2019 1:42, Mark Johnston wrote:
>
> >> Yes, I have debugger compiled into running kernel and have console access.
> >> What commands should I use?
> >
> > I meant kgdb(1). If you can run that, try:
> >
> > (kgdb) p
13.02.2019 1:42, Mark Johnston wrote:
>> Yes, I have debugger compiled into running kernel and have console access.
>> What commands should I use?
>
> I meant kgdb(1). If you can run that, try:
>
> (kgdb) p time_uptime
> (kgdb) p lowmem_uptime
>
> If you are willing to drop the system into
On 12.02.2019 21:37, Eugene Grosbein wrote:
>> vfs.zfs.arc_max=1216348160
>
> Each line shows how many megabytes is allocated but currently unused by
> corresponding
> UMA zone (and unavailable for other consumers). Your numbers are pretty low,
> you have nothing to worry about IMHO. I have
On Wed, Feb 13, 2019 at 01:40:06AM +0700, Eugene Grosbein wrote:
> 13.02.2019 1:18, Mark Johnston wrote:
>
> > On Wed, Feb 13, 2019 at 01:03:37AM +0700, Eugene Grosbein wrote:
> >> 12.02.2019 23:34, Mark Johnston wrote:
> >>
> >>> I suspect that the "leaked" memory is simply being used to cache
13.02.2019 1:18, Mark Johnston wrote:
> On Wed, Feb 13, 2019 at 01:03:37AM +0700, Eugene Grosbein wrote:
>> 12.02.2019 23:34, Mark Johnston wrote:
>>
>>> I suspect that the "leaked" memory is simply being used to cache UMA
>>> items. Note that the values in the FREE column of vmstat -z output
13.02.2019 1:29, Kurt Jaeger wrote:
> On a 8 GB 11.2p8 box doing mostly routing:
>
> 42.3047 abd_chunk
> 40 zio_buf_131072
> 31.75 zio_data_buf_131072
>19.8901 swblk
>12.9224 RADIX NODE
>11.7344 zio_buf_16384
>10.0664 zio_data_buf_12288
>9.84375
Hi!
> > Use following command to see how much memory is wasted in your case:
> >
> > vmstat -z | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024, $1}' | sort
> > -k1,1 -rn | head
>
> Oops, small correction:
>
> vmstat -z | sed 's/:/,/' | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024,
> $1}' |
13.02.2019 1:14, Eugene Grosbein wrote:
> Use following command to see how much memory is wasted in your case:
>
> vmstat -z | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024, $1}' | sort -k1,1
> -rn | head
Oops, small correction:
vmstat -z | sed 's/:/,/' | awk -F, '{printf "%10s %s\n",
On Wed, Feb 13, 2019 at 01:03:37AM +0700, Eugene Grosbein wrote:
> 12.02.2019 23:34, Mark Johnston wrote:
>
> > I suspect that the "leaked" memory is simply being used to cache UMA
> > items. Note that the values in the FREE column of vmstat -z output are
> > quite large. The cached items are
13.02.2019 0:57, Garrett Wollman wrote:
> In article
> eu...@grosbein.net writes:
>
>> Long story short: 11.2-STABLE/amd64 r335757 leaked over 4600MB kernel
>> wired memory over 81 days uptime
>> out of 8GB total RAM.
>
> Not a whole lot of evidence yet, but anecdotally I'm seeing the same
>
12.02.2019 23:34, Mark Johnston wrote:
> I suspect that the "leaked" memory is simply being used to cache UMA
> items. Note that the values in the FREE column of vmstat -z output are
> quite large. The cached items are reclaimed only when the page daemon
> wakes up to reclaim memory; if there
In article
eu...@grosbein.net writes:
>Long story short: 11.2-STABLE/amd64 r335757 leaked over 4600MB kernel
>wired memory over 81 days uptime
>out of 8GB total RAM.
Not a whole lot of evidence yet, but anecdotally I'm seeing the same
thing on some huge-memory NFS servers running releng/11.2.
On 2/12/2019 10:49, Eugene Grosbein wrote:
> 12.02.2019 23:34, Mark Johnston wrote:
>
>> I suspect that the "leaked" memory is simply being used to cache UMA
>> items. Note that the values in the FREE column of vmstat -z output are
>> quite large. The cached items are reclaimed only when the
12.02.2019 23:49, Eugene Grosbein wrote:
> 12.02.2019 23:34, Mark Johnston wrote:
>
>> I suspect that the "leaked" memory is simply being used to cache UMA
>> items. Note that the values in the FREE column of vmstat -z output are
>> quite large. The cached items are reclaimed only when the page
12.02.2019 23:34, Mark Johnston wrote:
> I suspect that the "leaked" memory is simply being used to cache UMA
> items. Note that the values in the FREE column of vmstat -z output are
> quite large. The cached items are reclaimed only when the page daemon
> wakes up to reclaim memory; if there
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Jan Bramkamp changed:
What|Removed |Added
CC||cr...@bultmann.eu
--- Comment #6
On Tue, Feb 12, 2019 at 11:14:31PM +0700, Eugene Grosbein wrote:
> Hi!
>
> Long story short: 11.2-STABLE/amd64 r335757 leaked over 4600MB kernel wired
> memory over 81 days uptime
> out of 8GB total RAM.
>
> Details follow.
>
> I have a workstation running Xorg, Firefox, Thunderbird,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
VVD changed:
What|Removed |Added
Summary|11.1-RELEASE amd64: GENERIC |12.0-RELEASE amd64: any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
VVD changed:
What|Removed |Added
Attachment #201961|Photo for screen from boot |Photo of screen from boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #5 from Andrey V. Elsukov ---
(In reply to Sergey Anokhin from comment #4)
> (In reply to Andrey V. Elsukov from comment #3)
>
> There is a mind that if turn off
>
> options IPSEC_DEBUG
>
> kernel panic will
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
VVD changed:
What|Removed |Added
Version|11.1-RELEASE|12.0-RELEASE
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
--- Comment #5 from VVD ---
Created attachment 201961
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201961=edit
Photo for screen from boot -v with kernel 12.0-RELEASE-p3 amd64
--
You are receiving this mail because:
You are
Hi!
Long story short: 11.2-STABLE/amd64 r335757 leaked over 4600MB kernel wired
memory over 81 days uptime
out of 8GB total RAM.
Details follow.
I have a workstation running Xorg, Firefox, Thunderbird, LibreOffice and
occasionally VirtualBox for single VM.
It has two identical 320GB HDDs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221376
--- Comment #4 from VVD ---
Created attachment 201960
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201960=edit
dmesg from boot -v with GENERIC kernel 11.2-RELEASE-p8 amd64
11.2 GENERIC kernel from freebsd-update boot fine.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #4 from Sergey Anokhin ---
(In reply to Andrey V. Elsukov from comment #3)
There is a mind that if turn off
options IPSEC_DEBUG
kernel panic will disappear
--
You are receiving this mail because:
You are on the CC
I found my panic. If I take everything out of rc.conf and loader.conf
and sysctl.conf and boot the system it works fine when I add an IP
address. If I add this one line to sysctl.conf
net.link.ether.inet.garp_rexmit_count=2
Then I get a panic when I configure the interface:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #3 from Andrey V. Elsukov ---
KEYDBG() macro executed only when net.key.debug is set to non-zero value. It
looks like your sysctl.conf didn't set it. Also, it looks impossible to get
page fault with fault address 0x28 in this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683
Andriy Voskoboinyk changed:
What|Removed |Added
CC||a...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
--- Comment #2 from Sergey Anokhin ---
(In reply to Andrey V. Elsukov from comment #1)
kernel config:
(pts/2)[root@server:~]# cat /usr/src/sys/amd64/conf/SERVER
#
# GENERIC -- Generic kernel configuration file for FreeBSD/amd64
#
# For
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Sergey Anokhin changed:
What|Removed |Added
CC||b...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683
Sergey Anokhin changed:
What|Removed |Added
CC||sta...@freebsd.org
--
You are
67 matches
Mail list logo
