> On 17 Mar 2019, at 19:34, Konstantin Belousov wrote:
>
> 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
On Mon, Mar 18, 2019 at 05:09:31AM +0700, Eugene Grosbein wrote:
> 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
It also happens on some supermicro atom boards that definitely don't run
Intel reference BIOS software. I can't provide any serial numbers dough
since it's Sunday at my location.
On 18.03.19 11:22, Konstantin Belousov wrote:
> On Mon, Mar 18, 2019 at 05:09:31AM +0700, Eugene Grosbein wrote:
>> 18.
18.03.2019 17:22, Konstantin Belousov wrote:
> That said, did anybody considered ignoring NO_VGA FACP flag on Silvermonts
> only ? Or even better, gather SMBIOS identifications for affected BIOSes
> and ignore the flag for them ?
Is SMBIOS-bases blacklisting reliable considering future BIOS upda
On 17/03/2019 21:57, Eugene Grosbein wrote:
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-u
On 3/18/2019 08:07, Pete French wrote:
>
>
> On 17/03/2019 21:57, Eugene Grosbein wrote:
>> 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 memo
I suggest caution in raising vm.v_free_min, at least on 11.2-RELEASE
systems with less RAM. I tried "65536" (256MB) on a 4GB mini-server, with
vfs.zfs.arc_max of 2.5GB. Bad things happened when the cron daemon merely
tried to run `periodic daily`.
A few more details - ARC was mostly full, an
On 3/18/2019 08:37, Walter Cramer wrote:
> I suggest caution in raising vm.v_free_min, at least on 11.2-RELEASE
> systems with less RAM. I tried "65536" (256MB) on a 4GB mini-server,
> with vfs.zfs.arc_max of 2.5GB. Bad things happened when the cron
> daemon merely tried to run `periodic daily`.
Same here using mfsbsd from 11-RELEASE. First attempt I forgot to add swap - it
killed the ssh I was using to issue a zfs send on the remote system.
Next attempt I added swap, but ssh got killed too.
Third attempt I used mfsbsd from 12-RELEASE. It succeeded.
Now I am using mfsbsd 11-RELEASE wit
Hi,
Apart from the performance benefit as per the section for bhyve in the
handbook, can the size of the zfs-backed guest:
1. be resized from the host?
2. does the guest need to be inactive?
3. can linux guests (or even windows ones) be resized as well?
thanks,
--
J.
signature.asc
Description
On Mon, Mar 18, 2019 at 9:05 AM tech-lists wrote:
>
> Hi,
>
> Apart from the performance benefit as per the section for bhyve in the
> handbook, can the size of the zfs-backed guest:
>
> 1. be resized from the host?
> 2. does the guest need to be inactive?
> 3. can linux guests (or even windows on
On Mon, Mar 18, 2019 at 09:08:31AM -0600, Alan Somers wrote:
Do you mean using a zvol as the backing store for a VM? If so, then:
1) Yes. You can just do "zfs set volsize" on the host.
2) In theory no, but the guest may need to be rebooted to notice the
change. And I'm not sure if the current
I have been building FreeBSD for many years, as in since 2.2.8.
Currently my amd64 build of 12-STABLE is built with the following src.conf:
WITHOUT_BHYVE=1
WITHOUT_CAPSICUM=1
WITHOUT_CDDL=1
WITHOUT_CLANG_EXTRAS=1
WITHOUT_CLANG_FULL=1
WITHOUT_CROSS_COMPILER=1
WITHOUT_DEBUG_FILES=1
WITHOUT_EXAMPLES
The ifuncs check for buildkernel is identical to the one in
/usr/src/lib/libc/Makefile
and is here:
/usr/src/sys/conf/kern.pre.mk
Dan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubs
Well, everything built fine, but the kernel faults on boot, so the checks are
probably needed. ;-)
I still do not understand why the linker that is part of 12-STABLE does not
provide the support needed.
The directives in my src.conf and make.conf do not delete the lld linker. They
just cut do
tech-lists wrote on 2019/03/18 16:25:
On Mon, Mar 18, 2019 at 09:08:31AM -0600, Alan Somers wrote:
Do you mean using a zvol as the backing store for a VM? If so, then:
1) Yes. You can just do "zfs set volsize" on the host.
2) In theory no, but the guest may need to be rebooted to notice the
c
Another data point:
I did the whole experiment with the latest 12-STABLE but for amd64 and
everything builds fine without changes, and runs fine too.
I used the same src.conf and make.conf. So the problem is definitely with i386.
Dan
___
freebsd-sta
On Mon, Mar 18, 2019 at 06:56:03PM +0100, Miroslav Lachman wrote:
[...]
Thanks for the example, I've saved it.
Ok just one other question, which I might have found the answer to, or
might not. I'm new to this virtualising on zfs even though ive used zfs
for years. It's basically:
I made a zvol
On Mon, Mar 18, 2019 at 6:24 PM tech-lists wrote:
>
> On Mon, Mar 18, 2019 at 06:56:03PM +0100, Miroslav Lachman wrote:
>
> [...]
>
> Thanks for the example, I've saved it.
>
> Ok just one other question, which I might have found the answer to, or
> might not. I'm new to this virtualising on zfs e
tech-lists wrote on 2019/03/19 01:23:
Am I correct? In that I should have used UFS in the guest rather than
zfs? Or was it the encryption?
As Alan already wrote - you can use ZFS inside of the guest but I would
never choose ZFS in zvol backed guest. I prefere UFS. It is faster and
does not n
20 matches
Mail list logo
