Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Peter Moody]

On Mon, Feb 12, 2018 at 1:49 PM, Don Lewis  wrote:
> On 31 Jan, Eugene Grosbein wrote:
>> 31.01.2018 4:36, Mike Tancsa пишет:
>>> On 1/30/2018 2:51 PM, Mike Tancsa wrote:

 And sadly, I am still able to hang the compile in about the same place.
 However, if I set
>>>
>>>
>>> OK, here is a sort of work around. If I have the box a little more busy,
>>> I can avoid whatever deadlock is going on.  In another console I have
>>> cat /dev/urandom | sha256
>>> running while the build runs
>>>
>>> ... and I can compile net/samba47 from scratch without the compile
>>> hanging.  This problem also happens on HEAD from today.  Should I start
>>> a new thread on freebsd-current ? Or just file a bug report ?
>>> The compile worked 4/4
>>
>> That's really strange. Could you try to do "sysctl 
>> kern.eventtimer.periodic=1"
>> and re-do the test without extra load?
>
> I'm having really good luck with the kernel patch attached to this
> message:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers

I'm new to this; what are the chances that this gets into -STABLE in
the near future?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Mike Tancsa]

On 2/12/2018 4:49 PM, Don Lewis wrote:
> On 31 Jan, Eugene Grosbein wrote:
>> 31.01.2018 4:36, Mike Tancsa пишет:
>>> On 1/30/2018 2:51 PM, Mike Tancsa wrote:

 And sadly, I am still able to hang the compile in about the same place.
 However, if I set
>>>
>>>
>>> OK, here is a sort of work around. If I have the box a little more busy,
>>> I can avoid whatever deadlock is going on.  In another console I have
>>> cat /dev/urandom | sha256
>>> running while the build runs
>>>
>>> ... and I can compile net/samba47 from scratch without the compile
>>> hanging.  This problem also happens on HEAD from today.  Should I start
>>> a new thread on freebsd-current ? Or just file a bug report ?
>>> The compile worked 4/4
>>
>> That's really strange. Could you try to do "sysctl 
>> kern.eventtimer.periodic=1"
>> and re-do the test without extra load?
> 
> I'm having really good luck with the kernel patch attached to this
> message:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
> 
> Since applying that patch, I did three poudriere runs to build the set
> of ~1700 ports that I use.  Other than one gmake-related build runaway
> that I've also seen on my AMD FX-8320E, I didn't see any random port
> build failures.  When I was last did some testing a few weeks ago,
> lang/go would almost always fail.  I also would seem random build
> failures in lang/guile or finance/gnucash (which uses guile during its
> build) on both my Ryzen and FX-8320E machines, but those built cleanly
> all three times.
> 
> I even built samba 16 times in a row without a hang.
> 


Cool!  I will give it a try!

In other news, the latest BIOS patch from ASUS for my motherboard
*seems* to have fixed the random hangs.  In the BIOS, I had to dial down
the memory one notch, disable q-states and disable core boost for my non
X Ryzen CPUs.  I did that Friday, and running a load that would
typically lock up the box, survived the weekend.  Same with the box I
have in Zoo.  No random freeze ups.

I was also able to take the amdtemp and amdsmn code from HEAD and
compile it on STABLE to confirm the CPU is / was not overheating.  Peak
temp in the low 50s even with the CPU cores are all maxed out.

---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ryzen issues on FreeBSD (can we sum up yet)?

[George Mitchell]

On 02/12/18 16:49, Don Lewis wrote:
> [...]
> I'm having really good luck with the kernel patch attached to this
> message:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
> 
> Since applying that patch, I did three poudriere runs to build the set
> of ~1700 ports that I use.  Other than one gmake-related build runaway
> that I've also seen on my AMD FX-8320E, I didn't see any random port
> build failures.  When I was last did some testing a few weeks ago,
> lang/go would almost always fail.  I also would seem random build
> failures in lang/guile or finance/gnucash (which uses guile during its
> build) on both my Ryzen and FX-8320E machines, but those built cleanly
> all three times.
> 
> I even built samba 16 times in a row without a hang.
> [...]

Until this thread started last year, I had been on the verge of
upgrading the build server on my net to a Ryzen.  Needless to say, I
postponed the change.  Now it seems there is hope that a resolution for
the issue may be in sight.  Is it time to survey everyone's experience
with the problem, and determine whether the cited patch helps?  My
sincere thanks in advance.  -- George



signature.asc
Description: OpenPGP digital signature

Re: Clock occasionally jumps backwards on 11.1-RELEASE

[Ian Lepore]

On Mon, 2018-02-12 at 17:29 -0700, Alan Somers wrote:
> On Tue, Jan 23, 2018 at 8:40 AM, Alan Somers  wrote:
> 
> > 
> > On Tue, Jan 23, 2018 at 3:48 AM, Mike Pumford 
> > wrote:
> > 
> > > 
> > > On 22/01/2018 17:07, Alan Somers wrote:
> > > 
> > > > 
> > > > Since upgrading my jail server to 11.1-RELEASE, the clock occasionally
> > > > jumps backwards by 5-35 minutes for no apparent reason.  Has anybody 
> > > > seen
> > > > something like this?
> > > > 
> > > > Details
> > > > =
> > > > 
> > > > * Happens about once a day on my jail server, and has happened at least
> > > > once on a separate bhyve server.
> > > > 
> > > > * The jumps almost always happen between 1 and 3 AM, but I've also seen
> > > > them happen at 06:30 and 20:15.
> > > > 
> > > > That's the window when the period scripts are run which if you have a
> > > default configuration and a lot of jails will put the system under a lot 
> > > of
> > > stress.
> > > 
> > That did not fail to escape my notice.  However, none of the jails'
> > periodic jobs involve the clock in any way.  And I wouldn't think that a
> > high CPU load could cause clock drift, could it?  This isn't Windows XP,
> > after all.
> > 
> > 
> > > 
> > > * I'm using the default ntp.conf file.
> > > > 
> > > > 
> > > > Are you running ntpd inside the jail or on the jail host? On my jail
> > > systems (which are 10.3 and 11.1) I run ntpd out the jail host (outside 
> > > all
> > > jails) and not inside the jails and the jails then get the accurate time 
> > > as
> > > the underlying host has accurate time.
> > > 
> > Only on the host.
> > 
> > New info: there is a possibility that my NFS server is hanging for
> > awhile.  That would explain my problem's timing.  However, ntpd shouldn't
> > be accessing any NFS shares, and I wouldn't think that a hung NFS server
> > should be able to pause the clock.  I'm doing a new experiment that should
> > be more informative.  But I'll have to wait until the problem recurs to
> > learn anything.
> > 
> I have a little more data now.  The problem happens much more frequently
> than I originally realized, but usually for just a few seconds at a time.
> It looks like the system is hanging for awhile and then recovering.  Or at
> least, the clocks are hanging.  The only other possibility would be for
> both the realtime _and_ monotonic clocks to jump backwards.  In any case,
> the problem is not ntpd's fault.  I don't know what could cause a system to
> hang for up to 30 minutes without crashing, and I'm not sure how to tell
> unless it happens during working hours.  I'll send another update if I
> learn more.
> 
> -Alan

Under the hood, CLOCK_REALTIME and CLOCK_MONOTONIC are the same
hardware; if one stops, both do.  CLOCK_REALTIME is simply offset
somewhat from MONOTONIC, and the offset can change (which is why
REALTIME isn't monotonic).

If you want to take a snapshot of some independently-running clocks,
you can use sysctl kern.timecounter.tc..counter, but that is
a snapshot of the raw hardware counter for the clock, which usually
rolls over pretty quickly (.mask tells you how many bits the counter
has, that and .frequency can be used to figure out how fast it rolls
over).

-- Ian

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Clock occasionally jumps backwards on 11.1-RELEASE

[Alan Somers]

On Tue, Jan 23, 2018 at 8:40 AM, Alan Somers  wrote:

> On Tue, Jan 23, 2018 at 3:48 AM, Mike Pumford 
> wrote:
>
>> On 22/01/2018 17:07, Alan Somers wrote:
>>
>>> Since upgrading my jail server to 11.1-RELEASE, the clock occasionally
>>> jumps backwards by 5-35 minutes for no apparent reason.  Has anybody seen
>>> something like this?
>>>
>>> Details
>>> =
>>>
>>> * Happens about once a day on my jail server, and has happened at least
>>> once on a separate bhyve server.
>>>
>>> * The jumps almost always happen between 1 and 3 AM, but I've also seen
>>> them happen at 06:30 and 20:15.
>>>
>>> That's the window when the period scripts are run which if you have a
>> default configuration and a lot of jails will put the system under a lot of
>> stress.
>>
>
> That did not fail to escape my notice.  However, none of the jails'
> periodic jobs involve the clock in any way.  And I wouldn't think that a
> high CPU load could cause clock drift, could it?  This isn't Windows XP,
> after all.
>
>
>> * I'm using the default ntp.conf file.
>>>
>>> Are you running ntpd inside the jail or on the jail host? On my jail
>> systems (which are 10.3 and 11.1) I run ntpd out the jail host (outside all
>> jails) and not inside the jails and the jails then get the accurate time as
>> the underlying host has accurate time.
>>
>
> Only on the host.
>
> New info: there is a possibility that my NFS server is hanging for
> awhile.  That would explain my problem's timing.  However, ntpd shouldn't
> be accessing any NFS shares, and I wouldn't think that a hung NFS server
> should be able to pause the clock.  I'm doing a new experiment that should
> be more informative.  But I'll have to wait until the problem recurs to
> learn anything.
>

I have a little more data now.  The problem happens much more frequently
than I originally realized, but usually for just a few seconds at a time.
It looks like the system is hanging for awhile and then recovering.  Or at
least, the clocks are hanging.  The only other possibility would be for
both the realtime _and_ monotonic clocks to jump backwards.  In any case,
the problem is not ntpd's fault.  I don't know what could cause a system to
hang for up to 30 minutes without crashing, and I'm not sure how to tell
unless it happens during working hours.  I'll send another update if I
learn more.

-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ryzen issues on FreeBSD ? (with sort of workaround)

[Don Lewis]

On 31 Jan, Eugene Grosbein wrote:
> 31.01.2018 4:36, Mike Tancsa пишет:
>> On 1/30/2018 2:51 PM, Mike Tancsa wrote:
>>>
>>> And sadly, I am still able to hang the compile in about the same place.
>>> However, if I set
>> 
>> 
>> OK, here is a sort of work around. If I have the box a little more busy,
>> I can avoid whatever deadlock is going on.  In another console I have
>> cat /dev/urandom | sha256
>> running while the build runs
>> 
>> ... and I can compile net/samba47 from scratch without the compile
>> hanging.  This problem also happens on HEAD from today.  Should I start
>> a new thread on freebsd-current ? Or just file a bug report ?
>> The compile worked 4/4
> 
> That's really strange. Could you try to do "sysctl kern.eventtimer.periodic=1"
> and re-do the test without extra load?

I'm having really good luck with the kernel patch attached to this
message:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers

Since applying that patch, I did three poudriere runs to build the set
of ~1700 ports that I use.  Other than one gmake-related build runaway
that I've also seen on my AMD FX-8320E, I didn't see any random port
build failures.  When I was last did some testing a few weeks ago,
lang/go would almost always fail.  I also would seem random build
failures in lang/guile or finance/gnucash (which uses guile during its
build) on both my Ryzen and FX-8320E machines, but those built cleanly
all three times.

I even built samba 16 times in a row without a hang.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Warner Losh]

On Mon, Feb 12, 2018 at 10:38 AM, Ask Bjørn Hansen 
wrote:

>
> real memory  = 67108864 (64 MB)
> avail memory = 42098688 (40 MB)
>
> The 24MB are for the kernel?  I wonder my 11.1 kernel is less
> discriminating with what I compiled in...
>

I'd suggest a non-GENERIC kernel. The GENERIC kernel is like 24MB these
days, while a tailored one is more like 5MB or 6MB leaving you with ~55MB
after initial memory allocations.

Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Erich Dollansky]

Hi,

I do not know if this helps here. I faced also memory problems on the
older Raspberry generations. Enabling swap helped even with no swap
in use.

Maybe, you also try it.

Erich


 On Sun, 11 Feb 2018 20:56:02 -0800 Ask Bjørn Hansen
 wrote:

> Hi,
> 
> I have an old Soekris system with 64MB memory that I upgraded from
> 10.3 to 11.1 recently. Since then it’s started hanging every few days.
> 
> Today I happened to have a “top” instance running on the serial
> console. The system is minimally responsive to the network (ICMP and
> CARP are working, but no services).
> 
> From the top output it’s not clear what resource it’s out of.
> There’s no swap configured, but that what it looks like it’s trying
> to do? 
> 
> The ‘pf purge’ process is suspicious. There are no pf rules
> configured on the system (it should be all disabled).
> 
> Any suggestions?  (Other than “seriously … 64MB memory?!”).
> 
> 
> Ask
> 
> 
> last pid:  2228;  load averages:  0.63,  0.65,  0.70  up
> 0+21:13:5604:50:47 36 processes:  2 running, 33 sleeping, 1
> waiting CPU:  0.1% user,  0.0% nice, 11.3% system,  2.4% interrupt,
> 86.2% idle Mem: 1616K Active, 10M Inact, 28M Wired, 3099K Buf, 1768K
> Free Swap:
> 
>   PIDUIDTHR PRI NICE   SIZERES STATETIMEWCPU
> COMMAND 11  0  1 155 ki31 0K 8K RUN 16.8H  75.53%
> idle 0  0  7 -16- 0K64K swapin 155:10  12.00%
> kernel 16  0  3 -16- 0K24K psleep  10:04   8.15%
> pagedaemon 12  0 14 -64- 0K   112K WAIT27:21
> 2.80% intr 6  0  1 -16- 0K 8K pftm 8:56
> 0.73% pf purge 1027  0  1  200  7272K  1140K RUN
> 6:04   0.52% top 7  0  1 -16- 0K 8K -
> 2:57   0.18% rand_harvestq 21  0  1  16- 0K 8K
> syncer   0:22   0.05% syncer 22  0  1  21- 0K 8K
> vlruwt   0:07   0.01% vnlru 19  0  1  20- 0K 8K
> psleep   0:08   0.01% bufdaemon 788  0  1  200  5920K
> 1752K select   0:04   0.01% syslogd 20  0  1  20-
> 0K 8K -0:07   0.01% bufspacedaemon 911  0  1
> 200  8816K  8844K kmem a  43:41   0.00% ntpd 996  0  1
> 200 13628K  4620K kmem a   0:06   0.00% sshd 985  0  1
> 200  5952K   584K kmem a   0:07   0.00% cron 709  0  1
> 200  7300K  3364K kmem a   0:01   0.00% devd 2227  0  1
> 240  5952K  1232K kmem a   0:00   0.00% cron
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable To
> unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Ian Lepore]

On Tue, 2018-02-13 at 01:40 +0700, Eugene Grosbein wrote:
> 13.02.2018 1:30, Ian Lepore wrote:
> 
> > 
> > > 
> > > > 
> > > >   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
> > > >   911 root1  220  8816K  8844K select   0:39   4.20% ntpd
> > > Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
> > > to periodically check your clock with cron, unless you need to 
> > > re-distribute
> > > NTP to your LAN.
> > > 
> > Heh.  I think 1) you don't realize you're saying "you don't need ntpd"
> > to, and 2) you didn't notice the hostname of the system in some of the
> > debugging output (ntp1.us.grundclock.com).  :)
> You are partialy right :-) I skipped hostname.
> 
> Btw, is Soektris system has good enough hardware clock and/or
> enough horsepower to provide quality public NTP service?
> Also thinking of lots of garbage traffic these days UDP/123 suffers from...

Should be plenty of horsepower.  For years I ran a pool.ntp.org server
using a 60mhz armv4 system with 64MB ram.

You don't need anything special in the way of a clock to run a public
ntp server at stratum 2 or lower and achieve millisecond accuracy (or
sub-millisecond at stratum 1, with a PPS input).  I've never seen a
system whose kernel timekeeping was so bad that ntpd couldn't steer the
clock and provide accurate time.

-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: [HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

[Meny Yossefi]

No, interface names will remain as is.

-Meny



From: owner-freebsd-stable@freebsd.orgOn Behalf OfWilhelm Schuster
Sent: Monday, February 12, 2018 6:02:11 PM (UTC+00:00) Monrovia, Reykjavik
To: freebsd-stable@freebsd.org
Subject: Re: [HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 
11-stable

On 2018-02-12 12:55, Hans Petter Selasky wrote:
> Hi,
>
> The change will happen this week.
> This is part of ongoing work in FreeBSD 11-stable.
>
> Make sure to update your /boot/loader.conf by adding mlx4en_load="YES" 
> if you are using the mlxen.ko kernel modules.

Does that mean, that interface names will also change? For example from
mlxen0 to mlx4en0? If so, I also have to update network configuration in 
/etc/rc.conf for example.
___
freebsd-stable@freebsd.org mailing list
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-stable=02%7C01%7Cfreebsd-commits-tracker%40mellanox.com%7C0271be467f734782062f08d57242f763%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636540554308599515=hzhwlzZ3mDAveb8vjgW7PCQAilyykqipUeLshDaTges%3D=0
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Eugene Grosbein]

13.02.2018 1:30, Ian Lepore wrote:

>>>   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
>>>   911 root1  220  8816K  8844K select   0:39   4.20% ntpd
>> Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
>> to periodically check your clock with cron, unless you need to re-distribute
>> NTP to your LAN.
>>
> 
> Heh.  I think 1) you don't realize you're saying "you don't need ntpd"
> to, and 2) you didn't notice the hostname of the system in some of the
> debugging output (ntp1.us.grundclock.com).  :)

You are partialy right :-) I skipped hostname.

Btw, is Soektris system has good enough hardware clock and/or
enough horsepower to provide quality public NTP service?
Also thinking of lots of garbage traffic these days UDP/123 suffers from...

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Ian Lepore]

On Tue, 2018-02-13 at 01:04 +0700, Eugene Grosbein wrote:
> 13.02.2018 0:38, Ask Bjørn Hansen wrote:
> 
> > 
> > > 
> > > > 
> > > > I have an old Soekris system with 64MB memory that I upgraded from 10.3 
> > > > to 11.1 recently. Since then it’s started hanging every few days.
> > > Please show output of commands:
> > > 
> > > grep memory /var/run/dmesg.boot
> > real memory  = 67108864 (64 MB)
> > avail memory = 42098688 (40 MB)
> > 
> > The 24MB are for the kernel?  I wonder my 11.1 kernel is less 
> > discriminating with what I compiled in...
> You should be running custom kernel with absolute minimum.
> For example, use "options NO_SWAPPING" to compile out swapping code if your 
> system
> cannot have any swap area.
> 
> > 
> > > 
> > > top -ores -d1
> > Shortly after boot:
> > 
> > last pid:  1008;  load averages:  0.57,  0.62,  0.53up 0+00:19:31  
> > 06:24:50
> > 8 processes:   1 running, 7 sleeping
> > CPU: % user, % nice, % system, % interrupt, % idle
> > Mem: 9084K Active, 3644K Inact, 29M Wired, 4862K Buf, 492K Free
> > Swap:
> > 
> >   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
> >   911 root1  220  8816K  8844K select   0:39   4.20% ntpd
> Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
> to periodically check your clock with cron, unless you need to re-distribute
> NTP to your LAN.
> 

Heh.  I think 1) you don't realize you're saying "you don't need ntpd"
to, and 2) you didn't notice the hostname of the system in some of the
debugging output (ntp1.us.grundclock.com).  :)

24MB physmem gone before the kernel even starts seems a little much.  I
wonder if some amount of that is being eaten up by a video frame buffer
that maybe isn't needed on a headless system?

-- Ian

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Eugene Grosbein]

13.02.2018 0:38, Ask Bjørn Hansen wrote:

>>> I have an old Soekris system with 64MB memory that I upgraded from 10.3 to 
>>> 11.1 recently. Since then it’s started hanging every few days.
>> Please show output of commands:
>>
>> grep memory /var/run/dmesg.boot
> 
> real memory  = 67108864 (64 MB)
> avail memory = 42098688 (40 MB)
> 
> The 24MB are for the kernel?  I wonder my 11.1 kernel is less discriminating 
> with what I compiled in...

You should be running custom kernel with absolute minimum.
For example, use "options NO_SWAPPING" to compile out swapping code if your 
system
cannot have any swap area.

>> top -ores -d1
> 
> Shortly after boot:
> 
> last pid:  1008;  load averages:  0.57,  0.62,  0.53up 0+00:19:31  
> 06:24:50
> 8 processes:   1 running, 7 sleeping
> CPU: % user, % nice, % system, % interrupt, % idle
> Mem: 9084K Active, 3644K Inact, 29M Wired, 4862K Buf, 492K Free
> Swap:
> 
>   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
>   911 root1  220  8816K  8844K select   0:39   4.20% ntpd

Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
to periodically check your clock with cron, unless you need to re-distribute
NTP to your LAN.

>   959 root1  520 10756K  5196K select   0:00   0.00% sshd
>   709 root1  200  7300K  3224K select   0:00   0.00% devd

Stop using devd (devd_enable="NO"), Soekris system does not need it, at all.

>> sysctl kern.ipc.nmbclusters
> 
> kern.ipc.nmbclusters: 898

Way too low. You should double this at very least.

>> It would be also very useful to obtain output of "vmstat -z" in a moment of 
>> breakage.

> ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP

> audit_record:  1112,  0,   0,   0,   0,   0,   0

Remove "options AUDIT" from the kernel config unless you really use this.
Same for every other non-mandatory kernel option including PF that may be
loaded using kernel modules.

> mbuf_packet:256,   5745, 259,   0,  418909,   2,   0
> mbuf:   256,   5745, 263, 273,  773249,  18,   0
> mbuf_cluster:  2048,898, 259, 131,  204839,1868,   0

This is very bad as FreeBSD TCP/IP stack just live-locks when it runs
out of mbufs/mbuf clusters. You want to eliminate mbuf* allocation failures at 
any cost.


> ===
> ~25 minutes after boot:
> 
> ntp1.us.grundclock.com# vmstat -z
> ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
> mbuf_packet:256,   5745, 128, 253,   32698,   0,   0
> mbuf:   256,   5745,   1, 263,   57270,   0,   0
> mbuf_cluster:  2048,898, 381,   3, 726,   0,   0

This is very strange because FAIL counters should not decrease.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

[Wilhelm Schuster]

On 2018-02-12 12:55, Hans Petter Selasky wrote:
> Hi,
> 
> The change will happen this week.
> This is part of ongoing work in FreeBSD 11-stable.
> 
> Make sure to update your /boot/loader.conf by adding
> mlx4en_load="YES" if you are using the mlxen.ko kernel modules.

Does that mean, that interface names will also change? For example from
mlxen0 to mlx4en0? If so, I also have to update network configuration in
/etc/rc.conf for example.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD on 64MB memory

[Ask Bjørn Hansen]

> On Feb 11, 2018, at 9:19 PM, Eugene Grosbein  wrote:
> 
> 12.02.2018 11:56, Ask Bjørn Hansen пишет:
>> Hi,
>> 
>> I have an old Soekris system with 64MB memory that I upgraded from 10.3 to 
>> 11.1 recently. Since then it’s started hanging every few days.
>> 
>> Today I happened to have a “top” instance running on the serial console. The 
>> system is minimally responsive to the network (ICMP and CARP are working, 
>> but no services).
>> 
>>> From the top output it’s not clear what resource it’s out of.
> 
> I suspect it is out of many types of kernel memory including mbuf clusters,
> hence no working TCP/UDP but ICMP works.

That makes sense. The console locks up, too (as soon as I ctrl-c’ed the running 
top process the console was frozen).

>> There’s no swap configured, but that what it looks like it’s trying to do? 
>> 
>> The ‘pf purge’ process is suspicious. There are no pf rules configured on 
>> the system (it should be all disabled).
>> 
>> Any suggestions?  (Other than “seriously … 64MB memory?!”).
> 
> Please show output of commands:
> 
> grep memory /var/run/dmesg.boot

real memory  = 67108864 (64 MB)
avail memory = 42098688 (40 MB)

The 24MB are for the kernel?  I wonder my 11.1 kernel is less discriminating 
with what I compiled in...

> top -ores -d1

Shortly after boot:

last pid:  1008;  load averages:  0.57,  0.62,  0.53up 0+00:19:31  06:24:50
8 processes:   1 running, 7 sleeping
CPU: % user, % nice, % system, % interrupt, % idle
Mem: 9084K Active, 3644K Inact, 29M Wired, 4862K Buf, 492K Free
Swap:

  PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
  911 root1  220  8816K  8844K select   0:39   4.20% ntpd
  959 root1  520 10756K  5196K select   0:00   0.00% sshd
  709 root1  200  7300K  3224K select   0:00   0.00% devd
 1002 root1  200  6712K  2876K pause0:01   0.49% csh
 1008 root1  490  7272K  2356K RUN  0:00   0.00% top
  991 root1  260  6400K  2196K wait 0:01   0.00% login
  985 root1  200  5952K  1848K nanslp   0:00   0.00% cron
  788 root1  200  5920K  1776K select   0:01   0.00% syslogd

> sysctl kern.ipc.nmbclusters

kern.ipc.nmbclusters: 898

kern.ipc.nmbufs: 5745
kern.ipc.maxmbufmem: 7350272

> It would be also very useful to obtain output of "vmstat -z" in a moment of 
> breakage.


I made it run on the console every 30 seconds, this is the last one I got. For 
comparison there’s a “shortly after boot” version below the ===’s.

Ask


Shortly before it stopped responding:

ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP

UMA Kegs:   256,  0, 128,   7, 128,   0,   0
UMA Zones:  408,  0, 129,   6, 129,   0,   0
UMA Slabs:   56,  0,1655,  73,   20845,   0,   0
UMA Hash:   128,  0,  11,  20,  14,   0,   0
4 Bucket:16,  0,   0, 504, 364,   0,   0
6 Bucket:24,  0,   0, 336, 118,   0,   0
8 Bucket:32,  0,   0, 378,   54150,   0,   0
12 Bucket:   48,  0,   0,   0,   0,   0,   0
16 Bucket:   64,  0,   2, 313,1840,   8,   0
32 Bucket:  128,  0,   3, 152,1516,   0,   0
64 Bucket:  256,  0,   1,  74, 221,   0,   0
128 Bucket: 512,  0,   4,  28,1324,   0,   0
256 Bucket:1024,  0,   3,  13,3917,   4,   0
vmem btag:   28,  0,3169, 143,3847,  56,   0
VM OBJECT:  148,  0,1208, 115,   38997,   0,   0
RADIX NODE:  44,  10738,1749, 344,   88089,   0,   0
MAP:140,  0,   3,  81,   3,   0,   0
KMAP ENTRY:  72,  0,   5, 163,   5,   0,   0
MAP ENTRY:   72,  0, 244, 148,   89326,   0,   0
VMSPACE:232,  0,  10,  75,2062,   0,   0
fakepg:  68,  0,   0,   0,   0,   0,   0
mt_zone:   2060,  0, 352,   0, 352,   0,   0
16:  16,  0,1159, 353,  813531,   0,   0
32:  32,  0, 957, 303,   23866,   0,   0
64:  64,  0,1385, 253,   29315,   0,   0
128:128,  0, 734, 134,   14162,   0,   0
256:256,  0, 378,  57,5062,   0,   0
512:512,  0,  57,   7,4807,   0,   0
1024:  1024,  0,  31,  33, 539,   0,   0
2048:  2048,  0, 208,   2,2908,   0,   0
4096:  4096,  0,  86,   0,2165,   0,   0
8192:  8192,  0,  

[HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

[Hans Petter Selasky]

Hi,

The change will happen this week.
This is part of ongoing work in FreeBSD 11-stable.

Make sure to update your /boot/loader.conf by adding
mlx4en_load="YES" if you are using the mlxen.ko kernel modules.

--HPS
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"