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
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
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
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
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
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
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
> > >
> 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
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
>
> 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
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
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
12 matches
Mail list logo