Hi,
I have tested the fix. lcr4(rcr4() | CR4_OSFXSR); helps indeed and
system boots but if statement seems to be not correct, at least on
VT-310DP board it ended up in the same error.
On Wed, Feb 15, 2017 at 6:35 PM, Thor Lancelot Simon wrote:
> On Wed, Feb 15, 2017 at 10:25:36AM +0200, Andrius
On Thu, Feb 16, 2017 at 01:04:33PM +0200, Andrius V wrote:
> Hi,
>
> I have tested the fix. lcr4(rcr4() | CR4_OSFXSR); helps indeed and
> system boots but if statement seems to be not correct, at least on
> VT-310DP board it ended up in the same error.
I checked in an unconditional version of th
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2017.02.16.19.11.13.
An extract from the build.sh output follows:
Live child 0x7f7ff7b2a480 (init.o) PID 25591
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2017.02.16.22.10.50 christos src/usr.sbin/makefs/ffs/buf.h,v 1.12
2017.02.16.22.40.19 christos src/sbin/gpt/gpt.h,v 1.35
2017.02.16.22.40.19 christos
Updating src tree:
P src/BUILDING
P src/UPDATING
P src/crypto/external/bsd/openssh/dist/auth2-pubkey.c
P src/distrib/amd64/uefi-installimage/Makefile.bootimage
P src/distrib/sets/lists/base/shl.mi
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/comp/shl.mi
P src/distrib/sets/lists/debug/
Yes, I've read that padlock design is not elegant at all and true, I
don't think so that we will see it redesigned anymore... Though I
didn't expect that it might be any difference between i386 and amd64
kernels but after your explanation it makes sense. I have a bit more
limited access to nano dev
