[SOLVED] Re: Kernel Panic On Boot after r327979

[Pete Wright]

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    prison_allow+0x4    movq    0x30(%rdi),%rax


Is this a known issue?  This is my primary workstation - so I'm going 
to revert back to an older kernel, but if more info is needed I can 
put some cycles into debugging today.


closing the loop on this.  it looks like the panic was due to debugfs 
being mounted on my system.  debugfs is part of the drm-next-kmod port 
which enables i915 gfx on recent intel GPU's, and debugfs doesn't *need* 
to be mounted but is quite useful and fun to play with.


anywho - the fix on my end is to:
- remove the drm-next-kmod port/pkg
- build and install latest kernel+world
- reboot and build/install the drm-next-kmod port/pkg
- reboot and enjoy i915 graphics

i'm kinda interested in what prison_allow does now as i haven't run 
across it before.  is this part of the jails infrastrucutre?


cheers,
-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Copying to a new computer

[Miroslav Lachman]

@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 users and 
groups from the old machine are on the new machine and without having to reset 
all the passwords?

(Most the users are in sql databases, so that's not an issue, but there are a 
few with shell accounts, those are the ones I'm concerned with.

I was intending to stick with v11.1 at this point.


You can copy these files:

/etc/group
/etc/login.conf
/etc/master.passwd
/etc/passwd

And DB files

/etc/login.conf.db
/etc/pwd.db
/etc/spwd.db

Or you can recreate them with pwd_mkdb and cap_mkdb (see their man pages)

If you installed some shells like bash or zsh for users, then you must 
installed them too and verify /etc/shells settings.


Additionally you may need a copy of /etc/profile and /etc/csh.cshrc if 
you modified them.


Miroslav Lachman
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Copying to a new computer

[@lbutlr]

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 are on the new machine and without having to reset 
all the passwords?

(Most the users are in sql databases, so that's not an issue, but there are a 
few with shell accounts, those are the ones I'm concerned with.

I was intending to stick with v11.1 at this point.

-- 
We are born naked, wet and hungry; then it's all downhill.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building kernel with no sound

[Ian Lepore]

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 GENERIC-NODEBUG
> 
> ident   MYKERNEL
> 
> nodevice  sound   # Generic sound driver (required)
> nodevice  snd_es137x  # Ensoniq AUdioPCI ES137x
> nodevice  snd_hda # Intel High Definition Audio
> nodevice  snd_ich # Intel, Nvidia and other ICH AC'97 audio
> nodevice  snd_uaudio  # USB Audio
> nodevice  snd_via8233 # VIA VT823x Audio
> 
> 
> The problem is when i try to compile it with "make buildkernel" the
> build process starts, but it stop with the error that it can´t find the
> header file "channel_if.h".
> 
> /usr/src/sys/dev/sound/pcm/channel.h:256:10: fatal error: 'channel_if.h' file 
> not found
> #include "channel_if.h"
>  ^~
> 
> The intention behind the custom kernel is to try 'oss' form the
> ports tree.

I think your nodevice list isn't quite complete.  Grepping for snd_ in
i386 and amd64 GENERIC, I come up with this list:

 snd_cmi  # CMedia CMI8338/CMI8738
 snd_csa  # Crystal Semiconductor CS461x/428x
 snd_emu10kx  # Creative SoundBlaster Live! and Audigy
 snd_es137x   # Ensoniq AudioPCI ES137x
 snd_hda  # Intel High Definition Audio
 snd_ich  # Intel, NVidia and other ICH AC'97 Audio
 snd_via8233  # VIA VT8233x Audio

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Karl Denninger]

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 there was a permission
problem with posix_spawn (!)

Now, having tried to roll my -HEAD repo forward it's failing *much*
earlier, starting with warnings about ATOMIC_ASM:

--- getarg.o ---
cc  -O2 -pipe -I/pics/CrossBuild-Head/src/crypto/heimdal/lib/roken -I. 
-DHAVE_C
ONFIG_H -I/pics/CrossBuild-Head/src/kerberos5/include -MD 
-MF.depend.getarg.o -
MTgetarg.o -std=gnu99  -Qunused-arguments 
-I/pics/Crochet-work-HEAD/obj/pics/Cr
ossBuild-Head/src/arm64.aarch64/tmp/legacy/usr/include -c
/pics/CrossBuild-Head/
src/crypto/heimdal/lib/roken/getarg.c -o getarg.o
--- _bootstrap-tools-usr.bin/localedef ---
In file included from
/pics/CrossBuild-Head/src/usr.bin/localedef/collate.c:50:
In file included from
/pics/CrossBuild-Head/src/lib/libc/locale/collate.h:44:
/pics/CrossBuild-Head/src/lib/libc/locale/xlocale_private.h:170:18:
warning: pas
sing 'long *' to parameter of type 'volatile u_long *' (aka 'volatile
unsigned l
ong *') converts between pointers to integer types with different sign
[-Wpointe
r-sign]
    atomic_add_long(&(obj->retain_count), 1);
    ^~~~
/usr/include/machine/atomic.h:467:1: note: passing argument to parameter
'p' her
e
ATOMIC_ASM(add,  long,  "addq %1,%0",  "ir",  v);
^
/usr/include/machine/atomic.h:141:43: note: expanded from macro 'ATOMIC_ASM'
atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\

And then failing to build llvm entirely starting here:

===> lib/clang/libllvm (all)
llvm-tblgen -gen-dag-isel  -I
/pics/CrossBuild-Head/src/contrib/llvm/include -I
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64  -d
AArch64GenDAGISel.inc.d -o AArch64GenDAGISel.inc 
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td
FCVTZSv8f16:    (set V128:v16i16:$Rd, (fp_to_sint: V128:v1f32:$Rn))
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:2951:1:
error: In FCVTZSv8f16: Type inference contradiction found, forcing
'{v16i8:v32i8:v8i16:v16i16:v4i32:v8i32:v2i64:v4i64:nxv4i1:nxv8i1:nxv16i1:nxv32i1:nxv32i8:nxv16i16:nxv8i32:nxv4i64}'
to have same number elements as 'v1f32'
defm FCVTZS : SIMDTwoVectorFPToInt<0, 1, 0b11011, "fcvtzs", fp_to_sint>;
^
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:337:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrFormats.td:5092:3:
note: instantiated from multiclass
  def v8f16 : BaseSIMDTwoSameVector<1, U, {S,1}, opc, 0b11, V128,
  ^
FCVTZUv8f16:    (set V128:v16i16:$Rd, (fp_to_uint: V128:v1f32:$Rn))
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:2952:1:
error: In FCVTZUv8f16: Type inference contradiction found, forcing
'{v16i8:v32i8:v8i16:v16i16:v4i32:v8i32:v2i64:v4i64:nxv4i1:nxv8i1:nxv16i1:nxv32i1:nxv32i8:nxv16i16:nxv8i32:nxv4i64}'
to have same number elements as 'v1f32'
defm FCVTZU : SIMDTwoVectorFPToInt<1, 1, 0b11011, "fcvtzu", fp_to_uint>;

Off -HEAD revision 328011

attempting to build with:

FreeBSD 11.1-STABLE #21 r327332M: Thu Dec 28 20:54:24 CST 2017
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

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

[Yuri Pankov]

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
, 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)
                 printf("%g\n", i);

would produce:

         1
         ...
         1.9

but:

         double i;

         for (i = 1; i <= 2; i += 0.2)
                 printf("%g\n", i);

would correctly end with 2:

         1
         ...
         2

$ cc -v
FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on
LLVM 6.0.0)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

though gcc 4.4.4 on illumos behaves the same.

Is this a known problem with loops and floating point numbers?
___




When you perform floating point computations , it may be useful to 
remember that , the last bits of floating point numbers may be 
considered to be "noise" .
For that reason , the same "for" or "while" loops may behave differently 
in different times and places .


To make floating point related loops more deterministic , the useful 
steps may be to compute "step size" and "number of steps" , and use 
integer variables for counting loop steps with multiplication of "loop 
counter"  and "step size" during loop steps :  For floating point loop 
counter T = "integer loop counter" * "step size" .


Indeed, exactly as I did in a patch for that PR.

A statement  like  T = T + "step size" will/may produce wrong results if 
number of steps is sufficiently large .



Computer arithmetic and theoretical arithmetic are not the same .
For example , addition is not associative in computer arithmetic : a + ( 
b + c ) is not always equal to ( a + b ) + c .


Thanks to all replies, I now clearly see the problem.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building kernel with no sound

[Freddie Cash]

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:
> include GENERIC-NODEBUG
>
> ident   MYKERNEL
>
> nodevicesound   # Generic sound driver (required)
> nodevicesnd_es137x  # Ensoniq AUdioPCI ES137x
> nodevicesnd_hda # Intel High Definition Audio
> nodevicesnd_ich # Intel, Nvidia and other ICH AC'97 audio
> nodevicesnd_uaudio  # USB Audio
> nodevicesnd_via8233 # VIA VT823x Audio
>
>
> The problem is when i try to compile it with "make buildkernel" the
> build process starts, but it stop with the error that it can´t find the
> header file "channel_if.h".
>
> /usr/src/sys/dev/sound/pcm/channel.h:256:10: fatal error: 'channel_if.h'
> file not found
> #include "channel_if.h"
>  ^~
>
> The intention behind the custom kernel is to try 'oss' form the
> ports tree.
>

​You're missing a few of the sound drivers.  Here's the section from
GENERIC on 11.1 for sound (it's the same for 10.4 and 12-CURRENT):

​# Sound support
device  sound   # Generic sound driver (required)
device  snd_cmi # CMedia CMI8338/CMI8738
device  snd_csa # Crystal Semiconductor CS461x/428x
device  snd_emu10kx # Creative SoundBlaster Live! and
Audigy
device  snd_es137x  # Ensoniq AudioPCI ES137x
device  snd_hda # Intel High Definition Audio
device  snd_ich # Intel, NVidia and other ICH AC'97
Audio
device  snd_via8233 # VIA VT8233x Audio

​So you need to add nodevice entries for all the ones that you are missing
(snd_cmi, snd_cma, snd_emu10kx).​

Always check the kernel config file you are including to see what you need
to exclude via nodevice.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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 errors,
>> about missing intrinsic symbols related to __atomic_*
>> 
>> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
>> are GCC extension and Clang provides them.
>> 
>> It seems to me that this specific GCC-compatible builtin are enabled on
>> amd64, but not on i386.
>> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
>> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
>> for every ports that need it ?
> 
> There is some strangeness going on with an upstream bug fix [1], which
> has the unintended side effect of sometimes emitting libcalls to
> __atomic functions that we do not have on i386.  I've commented on the
> upstream bug report, but I do not know an easy workaround at this
> point.
> 
> [1] https://bugs.llvm.org/show_bug.cgi?id=34347

It looks to me clang is doing fewer libcalls now and more inlining,
which is why the configure tests succeed now.  That clang generates
cmpxchg8b on i486 has always been the case.  The fix for 34347 exposes
this more now.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Building kernel with no sound

[Alexander Sieg]

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 driver (required)
nodevicesnd_es137x  # Ensoniq AUdioPCI ES137x
nodevicesnd_hda # Intel High Definition Audio
nodevicesnd_ich # Intel, Nvidia and other ICH AC'97 audio
nodevicesnd_uaudio  # USB Audio
nodevicesnd_via8233 # VIA VT823x Audio


The problem is when i try to compile it with "make buildkernel" the
build process starts, but it stop with the error that it can´t find the
header file "channel_if.h".

/usr/src/sys/dev/sound/pcm/channel.h:256:10: fatal error: 'channel_if.h' file 
not found
#include "channel_if.h"
 ^~

The intention behind the custom kernel is to try 'oss' form the
ports tree.


signature.asc
Description: PGP signature

[CFT] sysutils/devcpu-data Intel microcode migration

[Sean Bruno]

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 previously
received, but I'd like for folks to give it a spin before we commit yet
another update to this port.

sean



signature.asc
Description: OpenPGP digital signature

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

[Steve Kargl]

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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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,
>> it also confuses configure in net/librdkafka and net-mgmt/netdata.
> 
> Can we (by which I probably mean emaste@) push out an EN that adds the
> atomic.c from compiler-rt to our libgcc_s?  That should provide all of
> these helper functions.  Clang assumes that they exist because both
> compiler-rt and vaguely recent libgcc_s provide them.  Recent GCC will
> also assume that they exist and so the correct fix is probably for us
> to make them to exist.
> 
> If this is difficult, then we can perhaps provide a port that compiles
> atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so
> that’s a linker script that forces linking to libatomic_fudge.so and
> libgcc_s.so.

I can understand emitting function calls on i486 but according to Jan,
clang is emitting function calls on i586 as well.  It used to inline
this which is why we never needed these functions in libgcc.  Is it
normal that clang emits function calls now?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[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, 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)
> printf("%g\n", i);
>
> would produce:
>
> 1
> ...
> 1.9
>
> but:
>
> double i;
>
> for (i = 1; i <= 2; i += 0.2)
> printf("%g\n", i);
>
> would correctly end with 2:
>
> 1
> ...
> 2
>
> $ cc -v
> FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM
> 6.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
>
> though gcc 4.4.4 on illumos behaves the same.
>
> Is this a known problem with loops and floating point numbers?
> ___
>



When you perform floating point computations , it may be useful to remember
that , the last bits of floating point numbers may be considered to be
"noise" .
For that reason , the same "for" or "while" loops may behave differently in
different times and places .

To make floating point related loops more deterministic , the useful steps
may be to compute "step size" and "number of steps" , and use integer
variables for counting loop steps with multiplication of "loop counter"
and "step size" during loop steps :  For floating point loop counter T =
"integer loop counter" * "step size" .
A statement  like  T = T + "step size" will/may produce wrong results if
number of steps is sufficiently large .


Computer arithmetic and theoretical arithmetic are not the same .
For example , addition is not associative in computer arithmetic : a + ( b
+ c ) is not always equal to ( a + b ) + c .



Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Dimitry Andric]

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 documentation about C11 atomic builtins [3] stats that __atomic_*
> are GCC extension and Clang provides them.
> 
> It seems to me that this specific GCC-compatible builtin are enabled on
> amd64, but not on i386.
> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
> for every ports that need it ?

There is some strangeness going on with an upstream bug fix [1], which
has the unintended side effect of sometimes emitting libcalls to
__atomic functions that we do not have on i386.  I've commented on the
upstream bug report, but I do not know an easy workaround at this
point.

-Dimitry

[1] https://bugs.llvm.org/show_bug.cgi?id=34347



signature.asc
Description: Message signed with OpenPGP

Kernel Panic On Boot after r327979

[Pete Wright]

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 known issue?  This is my primary workstation - so I'm going to 
revert back to an older kernel, but if more info is needed I can put 
some cycles into debugging today.


Cheers!
-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Warner Losh]

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 guess,
> > it also confuses configure in net/librdkafka and net-mgmt/netdata.
> >
>
> Can we (by which I probably mean emaste@) push out an EN that adds the
> atomic.c from compiler-rt to our libgcc_s?  That should provide all of
> these helper functions.  Clang assumes that they exist because both
> compiler-rt and vaguely recent libgcc_s provide them.  Recent GCC will also
> assume that they exist and so the correct fix is probably for us to make
> them to exist.
>
> If this is difficult, then we can perhaps provide a port that compiles
> atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so
> that’s a linker script that forces linking to libatomic_fudge.so and
> libgcc_s.so.
>

So far clang 6 is just in -current. Let's at least get them there first
before we talk about ENs :)

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[David Chisnall]

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 (by which I probably mean emaste@) push out an EN that adds the atomic.c 
from compiler-rt to our libgcc_s?  That should provide all of these helper 
functions.  Clang assumes that they exist because both compiler-rt and vaguely 
recent libgcc_s provide them.  Recent GCC will also assume that they exist and 
so the correct fix is probably for us to make them to exist.

If this is difficult, then we can perhaps provide a port that compiles atomic.c 
into libatomic_fudge.so or similar and provides a libgcc_s.so that’s a linker 
script that forces linking to libatomic_fudge.so and libgcc_s.so.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Jan Beich]

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 intrinsic symbols related to __atomic_*
>> 
>> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
>> are GCC extension and Clang provides them.
>> 
>> It seems to me that this specific GCC-compatible builtin are enabled on
>> amd64, but not on i386.
>> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
>> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
>> for every ports that need it ?
>> 
>> [1]
>> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
>> [2]
>> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
>> [3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic
>
> 8 byte atomics requires at least i586.  So either find a way to disable
> the use of these atomics in these ports or add something like this to
> the port Makefile.
>
> .if ${ARCH} == i386 && ! ${MACHINE_CPU:Mi586}
> CFLAGS+=  -march=i586
> .endif

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.

$ cat a.c
#include 

typedef struct {
  uint64_t val64;
} atomic_t;

int main()
{
  uint64_t foo;
  atomic_t bar;
#ifdef ATOMIC_STRUCT
  __atomic_fetch_add(, 1, __ATOMIC_RELAXED);
#else
  __atomic_fetch_add(, 1, __ATOMIC_RELAXED);
#endif
  return 0;
}

$ cc -m32 -march=i586 a.c
$ clang50 -m32 -march=i586 a.c
/tmp/a-560ad1.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)

$ cc -m32 -DATOMIC_STRUCT -march=i586 a.c
/usr/bin/ld: error: undefined symbol: __atomic_fetch_add_8
>>> referenced by a.c
>>>   /tmp/a-ad8c36.o:(main)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang50 -m32 -DATOMIC_STRUCT -march=i586 a.c
/tmp/a-0fbfd0.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Yuri Pankov]

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.


Thanks for the hint!


As the saying goes:


Sometimes, people think 'I have a problem and I will solve it with floating 
point values' and then they have 1. problems.


Well, seq(1) is about floating numbers, so at least initially using them 
internally would seem correct, though reading your replies I now 
understand it's not :-)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

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 is totally expected. You have to work around the problem using a
computation method that doesn't accumulate errors.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Hooking RPi PWM driver into tree

[Warner Losh]

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 for RPi kernels, but how does one do that ?
>

We don't. We have no idea we're building for a particular kernel, so we
don't subset the modules based on the kernel UNLESS the kernel config gives
a list (MODULES_OVERRIDE). Compile it for armv[67] arm64 and we're fine
(since those are the archs we have it for). Even this level of subsetting
has grown painful, but there's not been a good fix for that yet either (and
arguably, no bad fixes, just bad hacks that have grown up and proliferated
to the point Something Must Be Done, but that turns out to be non-trivial
to do in a way that doesn't replace one thicket of kludge with another :()

In fact, on ARM, we've been moving to not building for specific boards, but
having a GENERIC kernel that can be used everywhere. I'll be augmenting
that with automatic driver loading based on the "plug and play" table data
that's marked in the driver.

(Needless to say, it should also be possible to compile it into the
> kernel for an RPi, but I know how to do that :-)
>

Your best bet if you are creating a tiny distribution for this is to use
MODULES_OVERRIDE in the kernel config so it's a module still, but not built
into the kernel so you can load / unload as need arises.


> And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ?
>

Neither. rpi is just a board. It's really a pwm driver for the bcm family
of SoC, so it should be called bcm_pwm. Any connections / configuration for
rpi is handled via FDT, right?

There's work underway to enumerate the modules you need on a system so one
could automate the subsetting of the drivers (as well as the loading), but
I'm not quite ready to turn that on end-to-end yet. The base infrastructure
is there, we can find modules for unattached devices, but the have to have
their ID tables (plug and play data) decorated appropriately. And that's
taking a lot of doing. My goal is to be completely deployed by BSDcan.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[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.

As the saying goes:

> Sometimes, people think 'I have a problem and I will solve it with floating 
> point values' and then they have 1. problems.


David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Hans Petter Selasky]

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
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Hans Petter Selasky]

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 <= 2.00; i += 0.1)
     printf("%g\n", i);

would produce:

     1
     ...
     1.9

but:

     double i;

     for (i = 1; i <= 2; i += 0.2)
     printf("%g\n", i);

would correctly end with 2:

     1
     ...
     2



Hi,

The decimal value "0.2" is the same like the fraction "1/5", which 
cannot be represented by a float nor double without rounding error. The 
more times you iterate the bigger the error becomes.


When you compare an integer with a float rounding happens. Check this out:

if ((int)(float)0.9 >= (int)1)
printf("OK\n");

Sequences using floating point should technically only use steps which 
can be written like this: "remainder * pow(2, -shift)".


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Yuri Pankov]

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)
printf("%g\n", i);

would produce:

1
...
1.9

but:

double i;

for (i = 1; i <= 2; i += 0.2)
printf("%g\n", i);

would correctly end with 2:

1
...
2

$ cc -v
FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM 
6.0.0)

Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

though gcc 4.4.4 on illumos behaves the same.

Is this a known problem with loops and floating point numbers?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[O. Hartmann]

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 disobeying to build
> > > "buildworld" (make buildkernel seems to work as I did several kernels
> > > right now).
> > > 
> > > The hosts's world is as of Wednesday, 10th January, the kernel's revison
> > > is
> > > 
> > > FreeBSD 12.0-CURRENT #0 r327871: Fri Jan 12 12:18:19 CET 2018 amd64.
> > > 
> > > I did, as a test, Friday, 12th Jan, as you can see, the last kernel build.
> > > 
> > > The host in question also carries a variety of release, package an jail
> > > builds in separate source trees (CURRENT in most cases, to keep them away
> > > from the host's source tree). Those separate source trees also reject to
> > > build.
> > > 
> > > After performing a "make cleanworld" to startover (even this morning,
> > > when I watched LLVM/CLANG 6.0.0 has slipped in), I face still the same
> > > error:
> > ...  
> > > --
> >  stage 1.2: bootstrap tools
> > > --
> > ...  
> > > Building 
> > > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen
> > > /usr/bin/ld: error: cannot open crt1.o: No such file or directory
> > > c++: error: linker command failed with exit code 1 (use -v to see
> > > invocation)
> > 
> > If this happens during bootstrap-tools, the toolchain on your host
> > system is busted.  Do you have the following .o files in /usr/lib?
> > 
> > Scrt1.o
> > crt1.o
> > crtbegin.o
> > crtbeginS.o
> > crtbeginT.o
> > crtend.o
> > crtendS.o
> > crti.o
> > crtn.o
> > gcrt1.o
> > 
> > If these are missing, restore them from a backup, or extract them from
> > an installation image.
> > 
> > -Dimitry
> >   
> 
> 
> # ll /usr/lib/Scrt1* /usr/lib/crt* /usr/lib/gcrt1.*
> 
> 160561 -r--r--r--  1 root  wheel  -  3.2K 10 Jan. 16:14 /usr/lib/Scrt1.o
> 161693 -r--r--r--  1 root  wheel  -  2.2K 10 Jan. 16:14 /usr/lib/crtbegin.o
> 161696 -r--r--r--  1 root  wheel  -  2.3K 10 Jan. 16:14 /usr/lib/crtbeginS.o
> 161695 -r--r--r--  1 root  wheel  -  2.7K 10 Jan. 16:14 /usr/lib/crtbeginT.o
> 161694 -r--r--r--  1 root  wheel  -  1.5K 10 Jan. 16:14 /usr/lib/crtend.o
> 161697 -r--r--r--  1 root  wheel  -  1.5K 10 Jan. 16:14 /usr/lib/crtendS.o
> 160518 -r--r--r--  1 root  wheel  -  800B 10 Jan. 16:14 /usr/lib/crti.o
> 160526 -r--r--r--  1 root  wheel  -  896B 10 Jan. 16:14 /usr/lib/crtn.o
> 160565 -r--r--r--  1 root  wheel  -  3.7K 10 Jan. 16:14 /usr/lib/gcrt1.o
> 
> Something went wrong :-(
> 
> Thank you for the hint,
> I try to recover from backup/image.
> 
> Oliver
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Sorry for the hurry (I was in a hurry).

As my listing indicates, crt1.o was missing. CURRENT does strange things
lately. The same day I've updated the base system, luckily the jail for
poudriere, based on the base system, has been updated and so I was able to
restore /usr/lib/crt1.o.

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[O. Hartmann]

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
> > now).
> > 
> > The hosts's world is as of Wednesday, 10th January, the kernel's revison is
> > 
> > FreeBSD 12.0-CURRENT #0 r327871: Fri Jan 12 12:18:19 CET 2018 amd64.
> > 
> > I did, as a test, Friday, 12th Jan, as you can see, the last kernel build.
> > 
> > The host in question also carries a variety of release, package an jail
> > builds in separate source trees (CURRENT in most cases, to keep them away
> > from the host's source tree). Those separate source trees also reject to
> > build.
> > 
> > After performing a "make cleanworld" to startover (even this morning, when I
> > watched LLVM/CLANG 6.0.0 has slipped in), I face still the same error:  
> ...
> > --  
>  stage 1.2: bootstrap tools  
> > --  
> ...
> > Building 
> > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen
> > /usr/bin/ld: error: cannot open crt1.o: No such file or directory
> > c++: error: linker command failed with exit code 1 (use -v to see
> > invocation)  
> 
> If this happens during bootstrap-tools, the toolchain on your host
> system is busted.  Do you have the following .o files in /usr/lib?
> 
> Scrt1.o
> crt1.o
> crtbegin.o
> crtbeginS.o
> crtbeginT.o
> crtend.o
> crtendS.o
> crti.o
> crtn.o
> gcrt1.o
> 
> If these are missing, restore them from a backup, or extract them from
> an installation image.
> 
> -Dimitry
> 


# ll /usr/lib/Scrt1* /usr/lib/crt* /usr/lib/gcrt1.*

160561 -r--r--r--  1 root  wheel  -  3.2K 10 Jan. 16:14 /usr/lib/Scrt1.o
161693 -r--r--r--  1 root  wheel  -  2.2K 10 Jan. 16:14 /usr/lib/crtbegin.o
161696 -r--r--r--  1 root  wheel  -  2.3K 10 Jan. 16:14 /usr/lib/crtbeginS.o
161695 -r--r--r--  1 root  wheel  -  2.7K 10 Jan. 16:14 /usr/lib/crtbeginT.o
161694 -r--r--r--  1 root  wheel  -  1.5K 10 Jan. 16:14 /usr/lib/crtend.o
161697 -r--r--r--  1 root  wheel  -  1.5K 10 Jan. 16:14 /usr/lib/crtendS.o
160518 -r--r--r--  1 root  wheel  -  800B 10 Jan. 16:14 /usr/lib/crti.o
160526 -r--r--r--  1 root  wheel  -  896B 10 Jan. 16:14 /usr/lib/crtn.o
160565 -r--r--r--  1 root  wheel  -  3.7K 10 Jan. 16:14 /usr/lib/gcrt1.o

Something went wrong :-(

Thank you for the hint,
I try to recover from backup/image.

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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 clang documentation about C11 atomic builtins [3] stats that __atomic_*
> are GCC extension and Clang provides them.
> 
> It seems to me that this specific GCC-compatible builtin are enabled on
> amd64, but not on i386.
> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
> for every ports that need it ?
> 
> [1]
> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
> [2]
> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
> [3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic

8 byte atomics requires at least i586.  So either find a way to disable
the use of these atomics in these ports or add something like this to
the port Makefile.

.if ${ARCH} == i386 && ! ${MACHINE_CPU:Mi586}
CFLAGS+=-march=i586
.endif
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hooking RPi PWM driver into tree

[Poul-Henning Kamp]

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 to compile it into the
kernel for an RPi, but I know how to do that :-)

And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

atomic in i386 Current after CLANG 6 upgrade

[Luca Pizzamiglio]

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 extension and Clang provides them.

It seems to me that this specific GCC-compatible builtin are enabled on
amd64, but not on i386.
Is there a way to enable GCC compatible __atomic_ builtin also on i386?
Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
for every ports that need it ?

Thanks in advance!
Best regards,
pizzamg

[1]
http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
[2]
http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
[3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"