Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]

Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on Mon Apr 9 03:54:50 UTC 2018 : > Something for some reason included arm_neon.h? # grep -r arm_neon.h /usr/src/sys/ | more /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:#include arm_neon.h is something that the kernel source itself

Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]

On Sun, Apr 08, 2018 at 09:51:19PM -0700, Mark Millard wrote: > Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on > Mon Apr 9 03:54:50 UTC 2018 : > > > Something for some reason included arm_neon.h? > > > # grep -r arm_neon.h /usr/src/sys/ | more >

Re: Module compiles looking in /usr/src when alternate src tree is in use

> On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote: > > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > > > I am having a compile time issue for a patched that compiled fine on my > > > > r329294 system, but now failes to compile with what looks like a wrong

Re: Module compiles looking in /usr/src when alternate src tree is in use

On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote: > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > > I am having a compile time issue for a patched that compiled fine on my > > > r329294 system, but now failes to compile with what looks like a wrong > > >

Re: Module compiles looking in /usr/src when alternate src tree is in use

> On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > I am having a compile time issue for a patched that compiled fine on my > > r329294 system, but now failes to compile with what looks like a wrong > > header being included. > > > Might this be a cousin to the problem

Re: Module compiles looking in /usr/src when alternate src tree is in use

On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > I am having a compile time issue for a patched that compiled fine on my > r329294 system, but now failes to compile with what looks like a wrong > header being included. > Might this be a cousin to the problem reported at

Module compiles looking in /usr/src when alternate src tree is in use

I am having a compile time issue for a patched that compiled fine on my r329294 system, but now failes to compile with what looks like a wrong header being included. I have wrapped the long line so I can point to a difference between r329294 and r332262 make log of this file. r329294 make

Ryzen Threadripper, Hyper-V, and NUMA vs. DIMMs: 3 DIMMs on each side seems to always be in "Local" mode, not "Distributed"

Context: Ryzen Threadripper 1950X under Windows 10 Pro with Hyper-V (used to run FreeBSD). In experimenting with switching a Threadripper 1950X to have ECC RAM I discovered: A) The maximum ECC memory it would put to use was 96 GiBytes (3 DIMMs on each side, a 4th on each side was recognized

Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

On Sun, Apr 8, 2018 at 5:53 AM, Peter Holm wrote: > On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote: >> On 3/24/18 2:35 AM, O. Hartmann wrote: >> > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, >> > created via >> > the classical manual

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

Hi Mark, On Sat, Apr 7, 2018 at 2:49 PM, Mark Johnston wrote: > On Sat, Apr 07, 2018 at 02:34:54PM -0500, Justin Hibbits wrote: >> >> I reverted back to r329881, and successfully built world. Updated to >> r329882 and it got stuck with processes in btalloc. >> >> I've seen

Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote: > On 3/24/18 2:35 AM, O. Hartmann wrote: > > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, > > created via > > the classical manual way, no makefs), my recent CURRENT system dumps the > > console full of

Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

On 3/24/18 2:35 AM, O. Hartmann wrote: Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, created via the classical manual way, no makefs), my recent CURRENT system dumps the console full of these error messages: g_handleattr: md0 bio_length 24 len 31 -> EFAULT I do