Re: hw.vga.acpi_ignore_no_vga=1 for installation media

[Eugene Grosbein]

18.03.2019 0:34, Konstantin Belousov wrote:

> Can anybody provide an example of machine where the flag is set but VGA
> works ?  For me, it is set on headless NUC when there is no monitor
> attached, and then BIOS does not configure framebuffer at all.

http://freebsd.1045724.x6.nabble.com/vt-4-related-hang-of-11-2-td6299125.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229235

> > So the proposal is about reversing the set of broken machines, but only
> in installer ?  In other words, if it worked for installer, the installed
> system would be broken (again) ?

VGA-based installation session won't event start unless this is fixed.

It should be easy to make installer generate the knob for target machine
if installer sees wrong ACPI flag with working VGA hardware.

___
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: Observations from a ZFS reorganization on 12-STABLE

[Eugene Grosbein]

17.03.2019 21:58, Karl Denninger wrote:

> Huh?  A simple *filesystem copy* managed to force a 16Gb system into
> requiring page file backing store?
> 
> I was able to complete the copy by temporarily adding the swap space
> back on (where it would be when the move was complete) but that
> requirement is pure insanity and it appears, from what I was able to
> determine, that it came about from the same root cause that's been
> plaguing VM/ZFS interaction since 2014 when I started work this issue --
> specifically, when RAM gets low rather than evict ARC (or clean up UMA
> that is allocated but unused) the system will attempt to page out
> working set.  In this case since it couldn't page out working set since
> there was nowhere to page it to the process involved got an OOM error
> and was terminated.
> 
> *I continue to argue that this decision is ALWAYS wrong.*

I agree. Recently I've found kind-of-workaround for this problem:
increase vm.v_free_min so when "FREE" memory goes low,
page daemon wakes earlier and shrinks UMA (and ZFS ARC too) moving some memory
from WIRED to FREE quick enough so it can be re-used before bad things happen.

But avoid increasing vm.v_free_min too much (e.g. over 1/4 of total RAM)
because kernel may start behaving strange. For 16Gb system it should be enough
to raise vm.v_free_min upto 262144 (1GB) or 131072 (512M).

This is not permanent solution in any way but it really helps.

___
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: hw.vga.acpi_ignore_no_vga=1 for installation media

[Konstantin Belousov]

On Sun, Mar 17, 2019 at 10:10:45AM -0600, Warner Losh wrote:
> I generally like this idea... But two caveats...
> 
> First, we'd need to update the docs so that folks doing serial installs can
> unset it Though serial installs are a weird beast
> Second, if it's really needed, we should have the installer generate it.
> alas, only vt can tell us that, but it should be easy to add a sysctl to it
> that says that it has done video by ignoring the absence of the vga node...
It is not about VGA node (what is that ?).
It is about ignoring FACP flag IAPC_BOOT_ARCH={NO_VGA}, and there are
machines which actually break when trying to access VGA hardware despite
the flag is set.
Can anybody provide an example of machine where the flag is set but VGA
works ?  For me, it is set on headless NUC when there is no monitor
attached, and then BIOS does not configure framebuffer at all.

So the proposal is about reversing the set of broken machines, but only
in installer ?  In other words, if it worked for installer, the installed
system would be broken (again) ?

> 
> Warner
> 
> On Sun, Mar 17, 2019 at 6:58 AM Leon Christopher Dietrich <
> dorali...@chaotikum.org> wrote:
> 
> > Sound's like solid idea.
> >
> > A lot of systems out there lack propper ACPI description for VGA and it
> > would definitly make the installation on such a system much more easy.
> >
> > As far as I can tell it doesn't seam to break other things and even low
> > power system without VGA (like a pcengines apu2) don't seam to suffer.
What apu2 reports in FACP flags ?  Do
acpidump -dt | grep IAPC_BOOT_ARCH

> >
> > On 17.03.19 13:00, freebsd-stable-requ...@freebsd.org wrote:
> > > Date: Sun, 17 Mar 2019 02:59:12 +0700
> > > From: Eugene Grosbein 
> > > To: FreeBSD stable 
> > > Subject: hw.vga.acpi_ignore_no_vga=1 for installation media
> > > Message-ID: <912fc95d-5a5e-012b-7385-0f43f50dc...@grosbein.net>
> > > Content-Type: text/plain; charset=koi8-r
> > >
> > > Hi!
> > >
> > > Since 11.2-RELESE, default console driver vt(4) checks ACPI table for
> > presence of VGA in the system.
> > > It does not initialize console (no input, no output) if ACPI states
> > there is no VGA adapter.
> > >
> > > There are PRs describing many cases when VGA is present but ACPI lies
> > > and we have a regression compared with 11.1 and earlier:
> > > FreeBSD cannot be installed interactively onto such a system, leaving
> > aside serial console.
> > >
> > > vt(4) has loader knob to restore pre-11.2 behaviour and ignore ACPI:
> > >
> > > hw.vga.acpi_ignore_no_vga=1
> > >
> > > Should we add this unconditionally to the installation media designed
> > for interactive VGA-based installation?
> > >
> > >
> > > --
> > >
> >
> >
> ___
> 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: hw.vga.acpi_ignore_no_vga=1 for installation media

[Warner Losh]

I generally like this idea... But two caveats...

First, we'd need to update the docs so that folks doing serial installs can
unset it Though serial installs are a weird beast
Second, if it's really needed, we should have the installer generate it.
alas, only vt can tell us that, but it should be easy to add a sysctl to it
that says that it has done video by ignoring the absence of the vga node...

Warner

On Sun, Mar 17, 2019 at 6:58 AM Leon Christopher Dietrich <
dorali...@chaotikum.org> wrote:

> Sound's like solid idea.
>
> A lot of systems out there lack propper ACPI description for VGA and it
> would definitly make the installation on such a system much more easy.
>
> As far as I can tell it doesn't seam to break other things and even low
> power system without VGA (like a pcengines apu2) don't seam to suffer.
>
> On 17.03.19 13:00, freebsd-stable-requ...@freebsd.org wrote:
> > Date: Sun, 17 Mar 2019 02:59:12 +0700
> > From: Eugene Grosbein 
> > To: FreeBSD stable 
> > Subject: hw.vga.acpi_ignore_no_vga=1 for installation media
> > Message-ID: <912fc95d-5a5e-012b-7385-0f43f50dc...@grosbein.net>
> > Content-Type: text/plain; charset=koi8-r
> >
> > Hi!
> >
> > Since 11.2-RELESE, default console driver vt(4) checks ACPI table for
> presence of VGA in the system.
> > It does not initialize console (no input, no output) if ACPI states
> there is no VGA adapter.
> >
> > There are PRs describing many cases when VGA is present but ACPI lies
> > and we have a regression compared with 11.1 and earlier:
> > FreeBSD cannot be installed interactively onto such a system, leaving
> aside serial console.
> >
> > vt(4) has loader knob to restore pre-11.2 behaviour and ignore ACPI:
> >
> > hw.vga.acpi_ignore_no_vga=1
> >
> > Should we add this unconditionally to the installation media designed
> for interactive VGA-based installation?
> >
> >
> > --
> >
>
>
___
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: Observations from a ZFS reorganization on 12-STABLE

[Rainer Duffner]

> Am 17.03.2019 um 15:58 schrieb Karl Denninger :
> 
> I've long argued that the VM system's interaction with ZFS' arc cache
> and UMA has serious, even severe issues.  12.x appeared to have
> addressed some of them, and as such I've yet to roll forward any part of
> the patch series that is found here [
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 
>  ] or the
> Phabricator version referenced in the bug thread (which is more-complex
> and attempts to dig at the root of the issue more effectively,
> particularly when UMA is involved as it usually is.)
> 
> Yesterday I decided to perform a fairly significant reorganization of
> the ZFS pools on one of my personal machines, including the root pool
> which was on mirrored SSDs, changing to a Raidz2 (also on SSDs.)  This
> of course required booting single-user from a 12-Stable memstick.



Interesting.

The patches published before Christmas 2018 solved all of the problems I had 
(shared by many others, probably also visible on the FreeBSD project’s own 
infrastructure) with 11.2 and 12.0

I run a decently sized syslog-server and the 25MB/s stream of syslog-data was 
killing 11.2 almost instantly.

I have a few 11.2 systems that I haven’t patched yet - but they have north of 
128GB of RAM and ARC had been configured down to 70% long before that - so I 
never saw the issue there.


___
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"

Observations from a ZFS reorganization on 12-STABLE

[Karl Denninger]

I've long argued that the VM system's interaction with ZFS' arc cache
and UMA has serious, even severe issues.  12.x appeared to have
addressed some of them, and as such I've yet to roll forward any part of
the patch series that is found here [
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 ] or the
Phabricator version referenced in the bug thread (which is more-complex
and attempts to dig at the root of the issue more effectively,
particularly when UMA is involved as it usually is.)

Yesterday I decided to perform a fairly significant reorganization of
the ZFS pools on one of my personal machines, including the root pool
which was on mirrored SSDs, changing to a Raidz2 (also on SSDs.)  This
of course required booting single-user from a 12-Stable memstick.

A simple "zfs send -R zs/root-save/R | zfs recv -Fuev zsr/R" should have
done it, no sweat.  The root that was copied over before I started is
uncomplicated; it's compressed, but not de-duped.  While it has
snapshots on it too it's by no means complex.

*The system failed to execute that command with an "out of swap space"
error, killing the job; there was indeed no swap configured since I
booted from a memstick.*

Huh?  A simple *filesystem copy* managed to force a 16Gb system into
requiring page file backing store?

I was able to complete the copy by temporarily adding the swap space
back on (where it would be when the move was complete) but that
requirement is pure insanity and it appears, from what I was able to
determine, that it came about from the same root cause that's been
plaguing VM/ZFS interaction since 2014 when I started work this issue --
specifically, when RAM gets low rather than evict ARC (or clean up UMA
that is allocated but unused) the system will attempt to page out
working set.  In this case since it couldn't page out working set since
there was nowhere to page it to the process involved got an OOM error
and was terminated.

*I continue to argue that this decision is ALWAYS wrong.*

It's wrong because if you invalidate cache and reclaim it you *might*
take a read from physical I/O to replace that data back into the cache
in the future (since it's not in RAM) but in exchange for a *potential*
I/O you perform a GUARANTEED physical I/O (to page out some amount of
working set) and possibly TWO physical I/Os (to page said working set
out and, later, page it back in.)

It has always appeared to me to be flat-out nonsensical to trade a
possible physical I/O (if there is a future cache miss) for a guaranteed
physical I/O and a possible second one.  It's even worse if the reason
you make that decision is that UMA is allocated but unused; in that case
you are paging when no physical I/O is required at all as the "memory
pressure" is a phantom!  While UMA is a very material performance win in
the general case to allow allocated-but-unused UMA to force paging, from
a performance perspective, appears to be flat-out insanity.  I find it
very difficult to come up with any reasonable scenario where releasing
allocated-but-unused UMA rather than paging out working set is a net
performance loser.

In this case since the system was running in single user mode the
process that got selected to be destroyed when that circumstance arose
and there was no available swap was the copy process itself.  The copy
itself did not require anywhere near all of the available non-kernel RAM.

I'm going to dig into this further but IMHO the base issue still exists,
even though the impact of it for my workloads with everything "running
normally" has materially decreased with 12.x.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: hw.vga.acpi_ignore_no_vga=1 for installation media

[Leon Christopher Dietrich]

Sound's like solid idea.

A lot of systems out there lack propper ACPI description for VGA and it
would definitly make the installation on such a system much more easy.

As far as I can tell it doesn't seam to break other things and even low
power system without VGA (like a pcengines apu2) don't seam to suffer.

On 17.03.19 13:00, freebsd-stable-requ...@freebsd.org wrote:
> Date: Sun, 17 Mar 2019 02:59:12 +0700
> From: Eugene Grosbein 
> To: FreeBSD stable 
> Subject: hw.vga.acpi_ignore_no_vga=1 for installation media
> Message-ID: <912fc95d-5a5e-012b-7385-0f43f50dc...@grosbein.net>
> Content-Type: text/plain; charset=koi8-r
>
> Hi!
>
> Since 11.2-RELESE, default console driver vt(4) checks ACPI table for 
> presence of VGA in the system.
> It does not initialize console (no input, no output) if ACPI states there is 
> no VGA adapter.
>
> There are PRs describing many cases when VGA is present but ACPI lies
> and we have a regression compared with 11.1 and earlier:
> FreeBSD cannot be installed interactively onto such a system, leaving aside 
> serial console.
>
> vt(4) has loader knob to restore pre-11.2 behaviour and ignore ACPI:
>
> hw.vga.acpi_ignore_no_vga=1
>
> Should we add this unconditionally to the installation media designed for 
> interactive VGA-based installation?
>
>
> --
>



signature.asc
Description: OpenPGP digital signature