On 3 Apr, Cy Schubert wrote:
> Try arbitrarily reducing arc_max through sysctl. ARC is immediately
> reduced and free memory increased however wired pages remains the
> same.
One thing that I've noticed is that with r329844 and earlier is that
there can be a difference of multiple GB between the
On 3 Apr, Don Lewis wrote:
> On 1 Apr, Don Lewis wrote:
>> On 27 Mar, Andriy Gapon wrote:
>>> On 24/03/2018 01:21, Bryan Drewery wrote:
On 3/20/2018 12:07 AM, Peter Jeremy wrote:
>
> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson
> wrote:
>> Also, if you could try going back
If you're thinking on it, you should know that the DVD version works. The
difference, AFAICT, is that it simply calls loader.efi directly. Ie:
bootx64.efi is loader.efi, not boot1.efi.
Loader.efi doesn't seem to change the screen mode when it starts. When the
kernel starts afterwards, this all
Thanks for that hint. I thought that arc_max was a tunable, but now knowing
it's sysctl, that helps a lot.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 4
Try arbitrarily reducing arc_max through sysctl. ARC is immediately reduced and
free memory increased however wired pages remains the same.
---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.
Cy Schubert
or
The
Agreed. I've come to the same conclusion that there may be multiple issues.
---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.
Cy Schubert
or
The need of the many outweighs the greed of the few.
---
-Origin
When my full backups run (1st Sunday -> Monday of the month) the box becomes
unusable after 5-10 hours of that backup with LOTS of SWAP usage
And ARC using 100+G.
Is anyone looking into this?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640
+1
However under certain circumstances it will release some memory. To reproduce,
when bsdtar unpacks some tarballs (when building certain ports) tar will use 12
GB or more forcing ARC to release memory.
BTW, I haven't stopped to grok whether the bsdtar issue is local to me or
another proble
On 1 Apr, Don Lewis wrote:
> On 27 Mar, Andriy Gapon wrote:
>> On 24/03/2018 01:21, Bryan Drewery wrote:
>>> On 3/20/2018 12:07 AM, Peter Jeremy wrote:
On 2018-Mar-11 10:43:58 -1000, Jeff Roberson
wrote:
> Also, if you could try going back to r328953 or r326346 and let me know
On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote:
> Hi,
>
> Right- so, `gop set 0` should've immediately cleared your screen and
> put it into 1920x1080, full stop. If it did not, I think that's
> indicative of some kind of interestingly broken firmware...
>
> Regardless! We're clearly bad at tryi
Hi,
Right- so, `gop set 0` should've immediately cleared your screen and
put it into 1920x1080, full stop. If it did not, I think that's
indicative of some kind of interestingly broken firmware...
Regardless! We're clearly bad at trying to set a mode before the
kernel starts, so r331904 sets the
I did as you asked. You can see the result at:
https://owncloud.towernet.ca/s/6K3pGknCyGTi7du
... but the long and short of it is that even though the loader is printing
in the center of the screen (text mode?), it sees the 1920x1080 mode as the
"mode 0" ... I even tried "gop set 0" ... which it
Booting a kernel from
% uname -a
FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \
Thu Mar 22 13:41:30 AKDT 2018 \
kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64
gives the following from dmesg
% dmesg | grep linux
link_elf_obj: symbol elf64_linux_vdso_fixup
I am successfully running a diskless TrueOS, a FreeBSD 12-CURRENT derivate,
desktop with the net/istgt port installed in a FreeBSD 11-RELEASE server. I
am using this setup without any error, but it is a bit slow.
I want to test ctld on my server, but when the diskless PC loads the isboot
driver it
14 matches
Mail list logo
