[SOLVED] Re: Kernel Panic On Boot after r327979

On 01/15/2018 09:26, Pete Wright wrote: Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at   

Re: Copying to a new computer

@lbutlr wrote on 2018/01/16 00:12: I am replacing an old machine with a newer machine and I want to be sure I can move the shell users to the new machine, especially since I am mostly going too be setting up the machine as new. What are the minimal files that I need to copy over so that the

Copying to a new computer

I am replacing an old machine with a newer machine and I want to be sure I can move the shell users to the new machine, especially since I am mostly going too be setting up the machine as new. What are the minimal files that I need to copy over so that the users and groups from the old machine

Re: Building kernel with no sound

On Mon, 2018-01-15 at 19:14 +0100, Alexander Sieg wrote: > Hey, > i´m trying to build a custom kernel with no sound support build in. > > This is my make.conf: > MALLOC_PRODUCTION=true > KERNCONF=MYKERNEL #GENERIC-NODEBUG > DEVELOPER=yes > > and this is my kernel configuration: > include

Recent commits to -HEAD blow up cross-compile for PI3 (and possibly others)

There has been trouble cross-compiling for the RPI3 for a while now, which I have filed a report on with the Crochet people here: https://github.com/freebsd/crochet/issues/222 This stemmed from an older LLVM version on my 11.1 box, which I rolled forward -- and resulted in blowups claiming that

Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk: On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov > wrote: Hi, Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149

Re: Building kernel with no sound

On Mon, Jan 15, 2018 at 10:14 AM, Alexander Sieg wrote: > Hey, > i´m trying to build a custom kernel with no sound support build in. > > This is my make.conf: > MALLOC_PRODUCTION=true > KERNCONF=MYKERNEL #GENERIC-NODEBUG > DEVELOPER=yes > > and this is my kernel configuration:

Re: atomic in i386 Current after CLANG 6 upgrade

On Mon, 15 Jan 2018 18:37:47 +0100 Dimitry Andric wrote: > On 15 Jan 2018, at 11:43, Luca Pizzamiglio wrote: >> I've already received a couple of messages from pkg-fallout about build >> failure on head-i386-default [1] [2] both pointing to the same

Building kernel with no sound

Hey, i´m trying to build a custom kernel with no sound support build in. This is my make.conf: MALLOC_PRODUCTION=true KERNCONF=MYKERNEL #GENERIC-NODEBUG DEVELOPER=yes and this is my kernel configuration: include GENERIC-NODEBUG ident MYKERNEL nodevicesound # Generic sound

[CFT] sysutils/devcpu-data Intel microcode migration

https://reviews.freebsd.org/D13921 In order to better absorb updates as they appear, I'm proposing that we switch from the current model of processing the "microcode.dat" legacy file to consuming the pre-digested update files. This update should not change the microcode version that you

Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk wrote: > > When you perform floating point computations , it may be useful > to ... read David Goldberg's paper, "What Every Computer Scientist Should Know about Floating-Point Arithmetic." http://www.validlab.com/ -- Steve

Re: atomic in i386 Current after CLANG 6 upgrade

On Mon, 15 Jan 2018 17:08:58 + David Chisnall wrote: > On 15 Jan 2018, at 17:00, Jan Beich wrote: >> It wouldn't help (see below). Clang 6 accidentally made __atomic* work >> enough to satisfy configure check but not for the port to build. I guess,

Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov wrote: > Hi, > > Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149, I > noticed that it isn't a seq(1) problem per se, rather for() and while() > loops behaving inconsistently while using floating point, i.e.: > >

Re: atomic in i386 Current after CLANG 6 upgrade

On 15 Jan 2018, at 11:43, Luca Pizzamiglio wrote: > > I've already received a couple of messages from pkg-fallout about build > failure on head-i386-default [1] [2] both pointing to the same errors, > about missing intrinsic symbols related to __atomic_* > > The clang

Kernel Panic On Boot after r327979

Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at    prison_allow+0x4    movq    0x30(%rdi),%rax Is this a

Re: atomic in i386 Current after CLANG 6 upgrade

On Mon, Jan 15, 2018 at 10:08 AM, David Chisnall wrote: > On 15 Jan 2018, at 17:00, Jan Beich wrote: > > > > It wouldn't help (see below). Clang 6 accidentally made __atomic* work > > enough to satisfy configure check but not for the port to build. I

Re: atomic in i386 Current after CLANG 6 upgrade

On 15 Jan 2018, at 17:00, Jan Beich wrote: > > It wouldn't help (see below). Clang 6 accidentally made __atomic* work > enough to satisfy configure check but not for the port to build. I guess, > it also confuses configure in net/librdkafka and net-mgmt/netdata. > Can we

Re: atomic in i386 Current after CLANG 6 upgrade

Tijl Coosemans writes: > On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio > wrote: > >> I've already received a couple of messages from pkg-fallout about build >> failure on head-i386-default [1] [2] both pointing to the same errors, >> about missing

Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 02:54:59PM +, David Chisnall: On 15 Jan 2018, at 14:49, Hans Petter Selasky wrote: The "seq" utility should use two 64-bit integers to represent the 10-base decimal number instead of float/double. And then you need to step this pair of integers.

Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 7:38 AM, Yuri Pankov wrote: > Is this a known problem with loops and floating point numbers? > Yes. Many exact fractions in base-10 aren't exact in base-2, so you get accumulation of errors based on the tiny difference and see behavior like this. This

Re: Hooking RPi PWM driver into tree

On Mon, Jan 15, 2018 at 4:26 AM, Poul-Henning Kamp wrote: > I wrote a device driver for PWM on the RPi's, but I have not yet > hooked it into the tree, because I'm unsure how we would want that. > > I personally think by default it should be a module which is > only compiled

Re: inconsistent for() and while() behavior when using floating point

On 15 Jan 2018, at 14:49, Hans Petter Selasky wrote: > > The "seq" utility should use two 64-bit integers to represent the 10-base > decimal number instead of float/double. And then you need to step this pair > of integers. As the saying goes: > Sometimes, people think 'I

Re: inconsistent for() and while() behavior when using floating point

Hi, The "seq" utility should use two 64-bit integers to represent the 10-base decimal number instead of float/double. And then you need to step this pair of integers. --HPS ___ freebsd-current@freebsd.org mailing list

Re: inconsistent for() and while() behavior when using floating point

On 01/15/18 15:38, Yuri Pankov wrote: Hi, Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149, I noticed that it isn't a seq(1) problem per se, rather for() and while() loops behaving inconsistently while using floating point, i.e.:     double i;     for (i = 1; i

inconsistent for() and while() behavior when using floating point

Hi, Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149, I noticed that it isn't a seq(1) problem per se, rather for() and while() loops behaving inconsistently while using floating point, i.e.: double i; for (i = 1; i <= 2.00; i += 0.1)

Re: CURRENT: can't buildworld; /usr/bin/ld: error: cannot open crt1.o:

On Mon, 15 Jan 2018 13:21:22 +0100 "O. Hartmann" wrote: > On Mon, 15 Jan 2018 08:45:56 +0100 > Dimitry Andric wrote: > > > On 15 Jan 2018, at 07:42, O. Hartmann wrote: > > > > > > One of our CURRENT boxes is repeateadly

Re: CURRENT: can't buildworld; /usr/bin/ld: error: cannot open crt1.o:

On Mon, 15 Jan 2018 08:45:56 +0100 Dimitry Andric wrote: > On 15 Jan 2018, at 07:42, O. Hartmann wrote: > > > > One of our CURRENT boxes is repeateadly disobeying to build > > "buildworld" (make buildkernel seems to work as I did several kernels right

Re: atomic in i386 Current after CLANG 6 upgrade

On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio wrote: > I've already received a couple of messages from pkg-fallout about build > failure on head-i386-default [1] [2] both pointing to the same errors, > about missing intrinsic symbols related to __atomic_* > > The

Hooking RPi PWM driver into tree

I wrote a device driver for PWM on the RPi's, but I have not yet hooked it into the tree, because I'm unsure how we would want that. I personally think by default it should be a module which is only compiled for RPi kernels, but how does one do that ? (Needless to say, it should also be possible

atomic in i386 Current after CLANG 6 upgrade

Hy all, I've already received a couple of messages from pkg-fallout about build failure on head-i386-default [1] [2] both pointing to the same errors, about missing intrinsic symbols related to __atomic_* The clang documentation about C11 atomic builtins [3] stats that __atomic_* are GCC