Re: Call for Testing: UEFI Changes

On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420 (with nvidia GPU) at r331864. > > No benefit (VGA resolution) but no new harm (no panic nor silent > reboot). > > *Maybe

Re: Call for Testing: UEFI Changes

Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694 On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI wrote: > Confirmed both loader (with boot1) part and efirt.ko part. > Working OK on my ThinkPad420

Re: Extremely low disk throughput under high compute load

Am 01.04.18 um 18:33 schrieb Warner Losh: > > > On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser > wrote: > > My i7-2600K based system with 24 GB RAM was in the midst of a buildworld > -j8 > (starting from a clean state) which caused a load

"Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected?

For: # uname -apKU FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 I get: . . . pci0: at device 7.3 (no driver attached) . . . intsmb0: at device 7.3 on pci0 intsmb0: Could not allocate I/O space device_attach: intsmb0 attach returned 6 on a Ryzen

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

Andriy Gapon avg at FreeBSD.org wrote on Tue Mar 27 14:00:20 UTC 2018 : > First, it looks like maybe several different issues are being discussed and > possibly conflated in this thread. It looks like one of the issues that contributes to non-ZFS contexts seeing process-kills for out-of-swap

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

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 if

Re: freebsd-update: to a specific patch level - help please? [PATCH]

On 18-03-24 10:26 AM, Derek wrote: On 18-03-23 06:44 AM, Kurt Jaeger wrote: To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.*  It works for me already, and

Re: Extremely low disk throughput under high compute load

On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser wrote: > My i7-2600K based system with 24 GB RAM was in the midst of a buildworld > -j8 > (starting from a clean state) which caused a load average of 12 for more > than > 1 hour, when I decided to move a directory structure holding

Extremely low disk throughput under high compute load

My i7-2600K based system with 24 GB RAM was in the midst of a buildworld -j8 (starting from a clean state) which caused a load average of 12 for more than 1 hour, when I decided to move a directory structure holding some 10 GB to its own ZFS file system. File sizes varied, but were mostly in the

Re: Call for Testing: UEFI Changes

Confirmed both loader (with boot1) part and efirt.ko part. Working OK on my ThinkPad420 (with nvidia GPU) at r331864. No benefit (VGA resolution) but no new harm (no panic nor silent reboot). *Maybe gracefully falling back to mode 0. As I'm on x11/nvidia-driver, completely no test is done with

Re: i386 4/4 change

On Sun, 1 Apr 2018, Dimitry Andric wrote: On 31 Mar 2018, at 17:57, Bruce Evans wrote: On Sat, 31 Mar 2018, Konstantin Belousov wrote: the change to provide full 4G of address space for both kernel and user on i386 is ready to land. The motivation for the work was