Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[Mark Millard]

On 2018-Jul-26, at 9:06 PM, Mark Millard  wrote:

> On 2018-Jul-26, at 6:14 PM, Mark Millard  wrote:
> 
>> On 2018-Jul-26, at 11:21 AM, John Baldwin  wrote:
>> 
>>> On 7/26/18 10:55 AM, Mark Millard wrote:
 . . .
>>> 
>>> Yes, but the -E from above was when compiled with external GCC and it 
>>> didn't change
>>> _Atomic(int).  Here's part of the source of bar.c:
>>> 
>>> #include 
>>> #include 
>>> 
>>> struct foo {
>>>  _Atomic(int) one;
>>>  _Atomic int two;
>>>  atomic_int three;
>>> };
>>> 
>>> And here is what that became after -E:
>>> 
>>> # 4 "bar.c"
>>> struct foo {
>>> _Atomic(int) one;
>>> _Atomic int two;
>>> atomic_int three;
>>> };
>>> 
>>> So cdefs.h did not define _Atomic.
>>> 
>>> Ah, if I add '-std=c99' then it does break.  Code that wants to use
>>> C11 atomics via  should not be using -std=c99.  Try this:
>>> 
>>> Index: lib/ofed/librdmacm/Makefile
>>> ===
>>> --- lib/ofed/librdmacm/Makefile (revision 335896)
>>> +++ lib/ofed/librdmacm/Makefile (working copy)
>>> @@ -8,6 +8,7 @@
>>> SHLIB_MAJOR=   1
>>> MK_PROFILE=no
>>> CFLAGS+=   -I${_spath}
>>> +CSTD=  gnu11
>>> 
>>> SRCS= \
>>> acm.c \
>>> 
>>> If this works then we should probably mark OFED as a BROKEN_OPTION when
>>> building with ancient GCC for now as well.
>> 
>> I've "unreverted" to set up a context for testing this.
>> 
>> So far I'll I've done is to test that I can still reproduce the failure
>> in my environment, same sort of error reports as ci.freebsd.org's
>> FreeBSD-head-amd64-gcc . This is without your patch.
>> 
>> But I've done this with gcc being given -v so that I've the exact commands
>> and search order and the like. It  does show: -std=gnu99 . I list the
>> filemon data from the .meta as well, showing the exact mix of
>> FreeBSD and gcc headers used. (I could also provide such for with
>> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
>> care.)
>> 
>> 
>> For now I just report the failure *without your patch*:
>> (I'll build again with your patch next.)
>> 
>> . . .
>> --- all_subdir_lib/ofed ---
>> Building 
>> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
>> --- acm.o ---
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
>> Target: x86_64-unknown-freebsd12.0
>> Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure 
>> --target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++ 
>> --enable-gnu-indirect-function --without-headers --with-gmp=/usr/local 
>> --with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib 
>> --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ 
>> --with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as 
>> --with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld 
>> --enable-initfini-array --prefix=/usr/local --localstatedir=/var 
>> --mandir=/usr/local/man --infodir=/usr/local/info/ 
>> --build=x86_64-unknown-freebsd12.0
>> Thread model: posix
>> gcc version 6.4.0 (FreeBSD Ports Collection for amd64) 
>> COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' 
>> '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99' 
>> '-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds' 
>> '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align' 
>> '-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra' 
>> '-Wno-error=inline' '-Wno-error=logical-not-parentheses' 
>> '-Wno-error=strict-aliasing' '-Wno-error=uninitialized' 
>> '-Wno-error=unused-but-set-variable' '-Wno-error=unused-function' 
>> '-Wno-error=unused-value' '-Wno-error=misleading-indentation' 
>> '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value' 
>> '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v' 
>> '-c' '-o' 'acm.o' '-mtune=generic' '-march=x86-64'
>> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I 
>> /usr/src/contrib/ofed/librdmacm -isysroot 
>> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp 
>> /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=generic 
>> -march=x86-64 -auxbase-strip acm.o -g -O2 -Wno-error=address 
>> -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare 
>> -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare 
>> -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses 
>> -Wno-error=strict-aliasing -Wno-error=uninitialized 
>> -Wno-error=unused-but-set-variable -Wno-error=unused-function 
>> -Wno-error=unused-value -Wno-error=misleading-indentation 
>> -Wno-error=nonnull-compare -Wno-error=shift-negative-value 
>> -Wno-error=tautological-compare -Wno-error=unused-const-variable -std=gnu99 
>> -version -fstack-protector-strong -o - |
>> /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I 
>> /usr/src/contrib/ofed/librdmacm -o acm.o
>> GNU C99 

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> 
> On Thu, 26 Jul 2018 19:23:43 +0300
> Toomas Soome  wrote:
> 
> (reply inline/at the end)
> 
> 
>>> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
>>> 
>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
>>> "Rodney W. Grimes" >> > wrote: 
>> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
>> 
>> On Wed, 25 Jul 2018 11:46:07 +0300
>> Toomas Soome  wrote:
>> 
 On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
 
 On Tue, 24 Jul 2018 08:53:36 +0300
 Toomas Soome  wrote:
 
 
 Hello  Toomas Soome,
 
 I CC Allan Jude since I discovered something  weird today regarding the
 UEFI boot capabilities of USB flash devices and SSDs. See below.
 
>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
>> 
>> On Mon, 23 Jul 2018 10:56:04 +0300
>> Toomas Soome  wrote:
>> 
 On 23 Jul 2018, at 10:27, O. Hartmann 
 wrote:
 
 On Fri, 13 Jul 2018 18:44:23 +0300
 Toomas Soome mailto:tso...@me.com>> wrote:
 
>> On 13 Jul 2018, at 17:44, O. Hartmann > > wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> Am Fri, 13 Jul 2018 14:26:51 +0300
>> Toomas Soome mailto:tso...@me.com>
>> >> schrieb: 
 On 13 Jul 2018, at 14:00, O. Hartmann 
 wrote:
 
 The problem is some kind of weird. I face UEFI boot problems on
 GPT drives where the first partition begins at block 40 of the
 hdd/ssd.
 
 I have two host in private use based on an
 outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
 Socket LGA1155). Both boards are equipted with the lates
 official available AMI firmware revision, dating to 2013. This
 is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
 Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
 for the Spectre/Meltdown mitigation is available, but I didn't
 test that. But please read.
 
 The third box I realised this problem is a brand new Fujitsu
 Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
 3413-A1x, date 05/25/2018 (or 20180525).
 
 Installing on any kind of HDD or SSD manually or via bsdinstall
 the OS using UEFI-only boot method on a GPT partitioned device
 fails. The ASRock boards jump immediately into the firmware,
 the Fujitsu offers some kind of CPU/Memory/HDD test facility.
 
 If on both type of vendor/boards CSM is disabled and UEFI boot
 only is implied, the MBR partitioned FreeBSD installation USB
 flash device does boot in UEFI! I guess I can assume this when
 the well known clumsy 80x25 char console suddenly gets bright
 and shiny with a much higher resoltion as long the GPU supports
 EFI GOP. Looking with gpart at the USB flash drives reveals
 that the EFI partition starts at block 1 of the device and the
 device has a MBR layout. I haven't found a way to force the GPT
 scheme, when initialised via gpart, to let the partitions start
 at block 1. This might be a naiv thinking, so please be patient
 with me.
 
 I do not know whether this is a well-known issue. On the ASRock
 boards, I tried years ago some LinuxRed Hat and Suse with UEFI
 and that worked - FreeBSD not. I gave up on that that time.
 Now, having the very same issues with a new Fujitsu system,
 leaves me with the impression that FreeBSD's UEFI
 implementation might have problems I'm not aware of.
 
 Can someone shed some light onto this? 
 
>>> 
>>> The first thing to check is if the secure boot is disabled. We
>>> do not support secure boot at all at this time.
>> 
>> Secure boot is in every scenario disabled!
>> 
>>> 
>>> If you have efi or bios version running - you can check from
>>> either console variable value (it can have efi or vidconsole or
>>> comconsole) or better yet, see if efi-version is set (show
>>> efi-version) - if efi-vers

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Thu, 26 Jul 2018 19:23:43 +0300
Toomas Soome  wrote:

(reply inline/at the end)


> > On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> > "Rodney W. Grimes"  > > wrote: 
>  On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
>  
>  On Wed, 25 Jul 2018 11:46:07 +0300
>  Toomas Soome  wrote:
>    
> >> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >> 
> >> On Tue, 24 Jul 2018 08:53:36 +0300
> >> Toomas Soome  wrote:
> >> 
> >> 
> >> Hello  Toomas Soome,
> >> 
> >> I CC Allan Jude since I discovered something  weird today regarding the
> >> UEFI boot capabilities of USB flash devices and SSDs. See below.
> >>   
>  On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
>  
>  On Mon, 23 Jul 2018 10:56:04 +0300
>  Toomas Soome  wrote:
>    
> >> On 23 Jul 2018, at 10:27, O. Hartmann 
> >> wrote:
> >> 
> >> On Fri, 13 Jul 2018 18:44:23 +0300
> >> Toomas Soome mailto:tso...@me.com>> wrote:
> >>   
>  On 13 Jul 2018, at 17:44, O. Hartmann   > wrote:
>  
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA512
>  
>  Am Fri, 13 Jul 2018 14:26:51 +0300
>  Toomas Soome mailto:tso...@me.com>
>  >> schrieb: 
> >> On 13 Jul 2018, at 14:00, O. Hartmann 
> >> wrote:
> >> 
> >> The problem is some kind of weird. I face UEFI boot problems on
> >> GPT drives where the first partition begins at block 40 of the
> >> hdd/ssd.
> >> 
> >> I have two host in private use based on an
> >> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
> >> Socket LGA1155). Both boards are equipted with the lates
> >> official available AMI firmware revision, dating to 2013. This
> >> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
> >> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
> >> for the Spectre/Meltdown mitigation is available, but I didn't
> >> test that. But please read.
> >> 
> >> The third box I realised this problem is a brand new Fujitsu
> >> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
> >> 3413-A1x, date 05/25/2018 (or 20180525).
> >> 
> >> Installing on any kind of HDD or SSD manually or via bsdinstall
> >> the OS using UEFI-only boot method on a GPT partitioned device
> >> fails. The ASRock boards jump immediately into the firmware,
> >> the Fujitsu offers some kind of CPU/Memory/HDD test facility.
> >> 
> >> If on both type of vendor/boards CSM is disabled and UEFI boot
> >> only is implied, the MBR partitioned FreeBSD installation USB
> >> flash device does boot in UEFI! I guess I can assume this when
> >> the well known clumsy 80x25 char console suddenly gets bright
> >> and shiny with a much higher resoltion as long the GPU supports
> >> EFI GOP. Looking with gpart at the USB flash drives reveals
> >> that the EFI partition starts at block 1 of the device and the
> >> device has a MBR layout. I haven't found a way to force the GPT
> >> scheme, when initialised via gpart, to let the partitions start
> >> at block 1. This might be a naiv thinking, so please be patient
> >> with me.
> >> 
> >> I do not know whether this is a well-known issue. On the ASRock
> >> boards, I tried years ago some LinuxRed Hat and Suse with UEFI
> >> and that worked - FreeBSD not. I gave up on that that time.
> >> Now, having the very same issues with a new Fujitsu system,
> >> leaves me with the impression that FreeBSD's UEFI
> >> implementation might have problems I'm not aware of.
> >> 
> >> Can someone shed some light onto this? 
> >>   
> > 
> > The first thing to check is if the secure boot is disabled. We
> > do not support secure boot at all at this time.
>  
>  Secure boot is in every scenario disabled!
>    
> > 
> > If you have efi or bios version running - you can check from
> > either console variable value (it can have efi or vidconsole or
> > comconsole) or better yet, see if efi-version is set (show
> > efi-version) - if efi-version is not set, it is BIOS loader
> > run

Re: Changes to sysctl values

[Conrad Meyer]

On Thu, Jul 26, 2018 at 8:52 PM, Shane Ambler  wrote:
> I use devel/py-sysctl in some scripts to get values, using a recent
> 12-current (r336728) I see at least two values that get a different
> value type than on 11-stable. Same version of python and port.
> ...

Hi Shane,

At some point, new sysctl types were added to the kernel, including
CTLTYPE_U32.  As part of the conversion to the counter(9) API, it
seems the v_wire_count (and other vm.stats sysctls) changed to U32
type.  py-sysctl lacks support for CTLTYPE_U32 and defaults to giving
you a bytearray for unrecognized types.

Best,
Conrad
___
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: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[Mark Millard]

On 2018-Jul-26, at 6:14 PM, Mark Millard  wrote:

> On 2018-Jul-26, at 11:21 AM, John Baldwin  wrote:
> 
>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>> . . .
>> 
>> Yes, but the -E from above was when compiled with external GCC and it didn't 
>> change
>> _Atomic(int).  Here's part of the source of bar.c:
>> 
>> #include 
>> #include 
>> 
>> struct foo {
>>   _Atomic(int) one;
>>   _Atomic int two;
>>   atomic_int three;
>> };
>> 
>> And here is what that became after -E:
>> 
>> # 4 "bar.c"
>> struct foo {
>> _Atomic(int) one;
>> _Atomic int two;
>> atomic_int three;
>> };
>> 
>> So cdefs.h did not define _Atomic.
>> 
>> Ah, if I add '-std=c99' then it does break.  Code that wants to use
>> C11 atomics via  should not be using -std=c99.  Try this:
>> 
>> Index: lib/ofed/librdmacm/Makefile
>> ===
>> --- lib/ofed/librdmacm/Makefile (revision 335896)
>> +++ lib/ofed/librdmacm/Makefile (working copy)
>> @@ -8,6 +8,7 @@
>> SHLIB_MAJOR=   1
>> MK_PROFILE=no
>> CFLAGS+=   -I${_spath}
>> +CSTD=  gnu11
>> 
>> SRCS= \
>> acm.c \
>> 
>> If this works then we should probably mark OFED as a BROKEN_OPTION when
>> building with ancient GCC for now as well.
> 
> I've "unreverted" to set up a context for testing this.
> 
> So far I'll I've done is to test that I can still reproduce the failure
> in my environment, same sort of error reports as ci.freebsd.org's
> FreeBSD-head-amd64-gcc . This is without your patch.
> 
> But I've done this with gcc being given -v so that I've the exact commands
> and search order and the like. It  does show: -std=gnu99 . I list the
> filemon data from the .meta as well, showing the exact mix of
> FreeBSD and gcc headers used. (I could also provide such for with
> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
> care.)
> 
> 
> For now I just report the failure *without your patch*:
> (I'll build again with your patch next.)
> 
> . . .
> --- all_subdir_lib/ofed ---
> Building 
> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
> --- acm.o ---
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
> Target: x86_64-unknown-freebsd12.0
> Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure 
> --target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++ 
> --enable-gnu-indirect-function --without-headers --with-gmp=/usr/local 
> --with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib 
> --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ 
> --with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as 
> --with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld 
> --enable-initfini-array --prefix=/usr/local --localstatedir=/var 
> --mandir=/usr/local/man --infodir=/usr/local/info/ 
> --build=x86_64-unknown-freebsd12.0
> Thread model: posix
> gcc version 6.4.0 (FreeBSD Ports Collection for amd64) 
> COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' 
> '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99' 
> '-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds' 
> '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align' 
> '-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra' 
> '-Wno-error=inline' '-Wno-error=logical-not-parentheses' 
> '-Wno-error=strict-aliasing' '-Wno-error=uninitialized' 
> '-Wno-error=unused-but-set-variable' '-Wno-error=unused-function' 
> '-Wno-error=unused-value' '-Wno-error=misleading-indentation' 
> '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value' 
> '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v' 
> '-c' '-o' 'acm.o' '-mtune=generic' '-march=x86-64'
> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I 
> /usr/src/contrib/ofed/librdmacm -isysroot 
> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp 
> /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=generic 
> -march=x86-64 -auxbase-strip acm.o -g -O2 -Wno-error=address 
> -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare 
> -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare 
> -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses 
> -Wno-error=strict-aliasing -Wno-error=uninitialized 
> -Wno-error=unused-but-set-variable -Wno-error=unused-function 
> -Wno-error=unused-value -Wno-error=misleading-indentation 
> -Wno-error=nonnull-compare -Wno-error=shift-negative-value 
> -Wno-error=tautological-compare -Wno-error=unused-const-variable -std=gnu99 
> -version -fstack-protector-strong -o - |
> /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I 
> /usr/src/contrib/ofed/librdmacm -o acm.o
> GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 
> (x86_64-unknown-freebsd12.0)
>   compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 
> (tags

Changes to sysctl values

[Shane Ambler]

I use devel/py-sysctl in some scripts to get values, using a recent
12-current (r336728) I see at least two values that get a different
value type than on 11-stable. Same version of python and port.

I have 12-current running in a bhyve on an 11-stable host.

Is there a recent change to sysctl calls that would cause this?
or is this bhyve related?

On 11-stable I get long int values that I expect

Python 2.7.15 (default, Jun  8 2018, 08:54:38)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final
326565)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value
1061486L
>>> sysctl.filter('vm.stats.vm.v_free_count')[0].value
77217L

On 12-current I get the same sysctls as a bytearray

Python 2.7.15 (default, Jul 26 2018, 10:32:28)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final
335540)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> sysctl.filter('vm.stats.vm.v_wire_count')[0].value
bytearray(b"\'R\x12\x00")
>>> sysctl.filter('vm.stats.vm.v_free_count')[0].value
bytearray(b'\x06\\\x08\x00')



-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[Mark Millard]

On 2018-Jul-26, at 11:21 AM, John Baldwin  wrote:

> On 7/26/18 10:55 AM, Mark Millard wrote:
>> . . .
> 
> Yes, but the -E from above was when compiled with external GCC and it didn't 
> change
> _Atomic(int).  Here's part of the source of bar.c:
> 
> #include 
> #include 
> 
> struct foo {
>_Atomic(int) one;
>_Atomic int two;
>atomic_int three;
> };
> 
> And here is what that became after -E:
> 
> # 4 "bar.c"
> struct foo {
> _Atomic(int) one;
> _Atomic int two;
> atomic_int three;
> };
> 
> So cdefs.h did not define _Atomic.
> 
> Ah, if I add '-std=c99' then it does break.  Code that wants to use
> C11 atomics via  should not be using -std=c99.  Try this:
> 
> Index: lib/ofed/librdmacm/Makefile
> ===
> --- lib/ofed/librdmacm/Makefile (revision 335896)
> +++ lib/ofed/librdmacm/Makefile (working copy)
> @@ -8,6 +8,7 @@
> SHLIB_MAJOR=   1
> MK_PROFILE=no
> CFLAGS+=   -I${_spath}
> +CSTD=  gnu11
> 
> SRCS= \
> acm.c \
> 
> If this works then we should probably mark OFED as a BROKEN_OPTION when
> building with ancient GCC for now as well.

I've "unreverted" to set up a context for testing this.

So far I'll I've done is to test that I can still reproduce the failure
in my environment, same sort of error reports as ci.freebsd.org's
FreeBSD-head-amd64-gcc . This is without your patch.

But I've done this with gcc being given -v so that I've the exact commands
and search order and the like. It  does show: -std=gnu99 . I list the
filemon data from the .meta as well, showing the exact mix of
FreeBSD and gcc headers used. (I could also provide such for with
the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
care.)


For now I just report the failure *without your patch*:
(I'll build again with your patch next.)

. . .
--- all_subdir_lib/ofed ---
Building 
/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
--- acm.o ---
Using built-in specs.
COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
Target: x86_64-unknown-freebsd12.0
Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure 
--target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++ 
--enable-gnu-indirect-function --without-headers --with-gmp=/usr/local 
--with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib 
--with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ 
--with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as 
--with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld --enable-initfini-array 
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man 
--infodir=/usr/local/info/ --build=x86_64-unknown-freebsd12.0
Thread model: posix
gcc version 6.4.0 (FreeBSD Ports Collection for amd64) 
COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2' 
'-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99' 
'-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds' 
'-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align' 
'-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra' 
'-Wno-error=inline' '-Wno-error=logical-not-parentheses' 
'-Wno-error=strict-aliasing' '-Wno-error=uninitialized' 
'-Wno-error=unused-but-set-variable' '-Wno-error=unused-function' 
'-Wno-error=unused-value' '-Wno-error=misleading-indentation' 
'-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value' 
'-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v' '-c' 
'-o' 'acm.o' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I 
/usr/src/contrib/ofed/librdmacm -isysroot 
/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp 
/usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=generic 
-march=x86-64 -auxbase-strip acm.o -g -O2 -Wno-error=address 
-Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare 
-Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare 
-Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses 
-Wno-error=strict-aliasing -Wno-error=uninitialized 
-Wno-error=unused-but-set-variable -Wno-error=unused-function 
-Wno-error=unused-value -Wno-error=misleading-indentation 
-Wno-error=nonnull-compare -Wno-error=shift-negative-value 
-Wno-error=tautological-compare -Wno-error=unused-const-variable -std=gnu99 
-version -fstack-protector-strong -o - |
 /usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I 
/usr/src/contrib/ofed/librdmacm -o acm.o
GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0 
(x86_64-unknown-freebsd12.0)
compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0 
(tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, MPC 
version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory 
"/usr/local/lib/gcc/x86_6

panic in btsocks_l2cap_sockets_mtx @ ng_btsocket_2cap.c:2438

[Yuri]

Got this panic while trying to register the bluetooth mouse.

See the screenshot: https://imgur.com/a/RXZRIn9


r336271


Yuri

___
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: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

[John Baldwin]

On 7/16/18 11:27 PM, Mark Millard wrote:
> On 2018-Jul-1, at 6:34 AM, Mark Millard  wrote:
> 
>> My brain finally engaged for showing exactly what files are included
>> for the gcc builds: the .meta files include that information explicitly
>> (along with other files that are opened during the operation).
>>
>> amd64 is as I reported, just one header file from gcc: float.h .
>>
>> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
>> is not including  . Building without __ALTIVEC__ might
>> be an error itself but would be a workaround for the altivec.h
>> file name aliasing vs. search-path problem.
>>
>> . . .
> 
> Going in a different direction, what of the unchanged Makefile.inc1
> code block:
> 
> .if ${WANT_COMPILER_TYPE} == gcc || \
> (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
> # GCC requires -isystem and -L when using a cross-compiler.  --sysroot
> # won't set header path and -L is used to ensure the base library path
> # is added before the port PREFIX library path.
> CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
> # GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
> # combined with --sysroot.
> CD2CFLAGS+= -B${XDDESTDIR}/usr/lib
> # Force using libc++ for external GCC.
> .if defined(X_COMPILER_TYPE) && \
> ${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
> CD2CXXFLAGS+=   -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
> -nostdinc++
> .endif
> .endif
> 
> Why is that pair of -isystem uses that gives the old search order
> okay? Or was the block just missed? (Similarly for other options
> listed above.)

Just missed.  They should probably also be removed.

> Note: Locally I've reverted the -r335782 changes in order for my use
> of devel/*-gcc as cross compilers to work where they used to (hopefully:
> still building), restoring the historical search order for the
> directories for now.

I finally got the approval 2 days ago to remove float.h from amd64-gcc so
you shouldn't need this reverted anymore once the OFED thing is
straightened out.

-- 
John Baldwin
___
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: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[John Baldwin]

On 7/26/18 10:55 AM, Mark Millard wrote:
> 
> 
> On 2018-Jul-26, at 10:21 AM, John Baldwin  wrote:
> 
>> On 7/25/18 6:52 PM, Mark Millard wrote:
>>>
>>>
>>> On 2018-Jul-25, at 2:10 PM, Mark Millard  wrote:
>>>
>>>
>>>
 On 2018-Jul-25, at 10:09 AM, Mark Millard  wrote:

> On 2018-Jul-25, at 8:39 AM, John Baldwin  wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard  wrote:
>>>
 https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
 (head -r336573 after the prior 6596's -r336565 ):

 --- all_subdir_lib/ofed ---
 In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
 from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
 /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
 'fastlock_init':
 /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid 
 initializer
 atomic_store(&lock->cnt, 0);
 ^
 In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
 /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
 'fastlock_acquire':
 /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 
 'struct  *' is incompatible with argument 1 of 
 '__atomic_fetch_add'
 if (atomic_fetch_add(&lock->cnt, 1) > 0)
 ^~
 /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
 'fastlock_release':
 /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 
 'struct  *' is incompatible with argument 1 of 
 '__atomic_fetch_sub'
 if (atomic_fetch_sub(&lock->cnt, 1) > 1)
 ^~
 . . .
 --- all_subdir_lib/ofed ---
 *** [acm.o] Error code 1


 https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( 
 for
 -r336700 ) still shows this type of error.
>>>
>>>
>>> [I should have a subject with "head -r336568 through -r336570 . . .".]
>>>
>>> From what I can tell looking around having something like:
>>>
>>> if (atomic_fetch_add(&lock->cnt, 1) > 0)
>>>
>>> involve a __atomic_fetch_add indicates that:
>>>
>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>>>
>>> was in use instead of FreeBSD's stdatomic.h file.
>>>
>>> If this is right, then the issue may be tied to head -r335782
>>> implicitly changing the order of the include file directory
>>> searching for builds via the devel/*-gcc .
>>>
>>> (I reverted -r335782 in my environment some time ago and have
>>> not run into this problem in my context so far.)
>>
>> C11 atomics should work fine with compiler-provided headers since they
>> are a part of the language (and the system stdatomic.h simply attempts
>> to mimic the compiler-provided header in case it is missing).
>>
>> Simple standalone tests of _Atomic(int) with GCC don't trigger those
>> failures when using its stdatomic.h, so there is probably something else
>> going on with kernel includes being used while building the library,
>> etc.  The last time we had this issue with stdarg.h it was because a
>> header shared between the kernel and userland always used 
>> ''
>> which is correct for the kernel but not for userland.
>
> I did misread the headers. FreeBSD has the likes of:
>
> #if defined(__CLANG_ATOMICS)
> . . .
> #define   atomic_fetch_add_explicit(object, operand, order)   
> \
>   __c11_atomic_fetch_add(object, operand, order)
> . . .
> #elif defined(__GNUC_ATOMICS)
> . . .
> #define   atomic_fetch_add_explicit(object, operand, order)   
> \
>   __atomic_fetch_add(&(object)->__val, operand, order)
> . . .
> #endif
> . . .
> #define   atomic_fetch_add(object, operand)   
> \
>   atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
>
> so __atomic_fetch_add would occur.
>
> But so far I do not see the problem with -r335782 reverted. I last built
> -r336693 last night via devel/amd64-gcc (via xtoolchain).
>
> From what I can tell FreeBSD defines:
>
> #if !defined(__CLANG_ATOMICS)
> #define   _Atomic(T)  struct { volatile T __val; }
> #endif
>
> and that struct is being used in &(object)->__val is what the
> error reports are about. So that would be, for example,
>
> &(&lock->cnt)->__val
>
> This would appear to suggest that __val itself had a type meeting:
>
> operand type struct 
>
> for T in _Atomic(T) .
>
> (This is independent of just what the issue traces back to: just
> the net result on ci.freebsd.org . No claim that you are right
> or wrong here. I'll

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[Mark Millard]

On 2018-Jul-26, at 10:21 AM, John Baldwin  wrote:

> On 7/25/18 6:52 PM, Mark Millard wrote:
>> 
>> 
>> On 2018-Jul-25, at 2:10 PM, Mark Millard  wrote:
>> 
>> 
>> 
>>> On 2018-Jul-25, at 10:09 AM, Mark Millard  wrote:
>>> 
 On 2018-Jul-25, at 8:39 AM, John Baldwin  wrote:
 
> On 7/24/18 11:39 PM, Mark Millard wrote:
>> On 2018-Jul-24, at 10:32 PM, Mark Millard  wrote:
>> 
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>> (head -r336573 after the prior 6596's -r336565 ):
>>> 
>>> --- all_subdir_lib/ofed ---
>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
>>> 'fastlock_init':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid 
>>> initializer
>>> atomic_store(&lock->cnt, 0);
>>> ^
>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
>>> 'fastlock_acquire':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 
>>> 'struct  *' is incompatible with argument 1 of 
>>> '__atomic_fetch_add'
>>> if (atomic_fetch_add(&lock->cnt, 1) > 0)
>>> ^~
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
>>> 'fastlock_release':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 
>>> 'struct  *' is incompatible with argument 1 of 
>>> '__atomic_fetch_sub'
>>> if (atomic_fetch_sub(&lock->cnt, 1) > 1)
>>> ^~
>>> . . .
>>> --- all_subdir_lib/ofed ---
>>> *** [acm.o] Error code 1
>>> 
>>> 
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>>> -r336700 ) still shows this type of error.
>> 
>> 
>> [I should have a subject with "head -r336568 through -r336570 . . .".]
>> 
>> From what I can tell looking around having something like:
>> 
>> if (atomic_fetch_add(&lock->cnt, 1) > 0)
>> 
>> involve a __atomic_fetch_add indicates that:
>> 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>> 
>> was in use instead of FreeBSD's stdatomic.h file.
>> 
>> If this is right, then the issue may be tied to head -r335782
>> implicitly changing the order of the include file directory
>> searching for builds via the devel/*-gcc .
>> 
>> (I reverted -r335782 in my environment some time ago and have
>> not run into this problem in my context so far.)
> 
> C11 atomics should work fine with compiler-provided headers since they
> are a part of the language (and the system stdatomic.h simply attempts
> to mimic the compiler-provided header in case it is missing).
> 
> Simple standalone tests of _Atomic(int) with GCC don't trigger those
> failures when using its stdatomic.h, so there is probably something else
> going on with kernel includes being used while building the library,
> etc.  The last time we had this issue with stdarg.h it was because a
> header shared between the kernel and userland always used 
> ''
> which is correct for the kernel but not for userland.
 
 I did misread the headers. FreeBSD has the likes of:
 
 #if defined(__CLANG_ATOMICS)
 . . .
 #defineatomic_fetch_add_explicit(object, operand, order)   
 \
__c11_atomic_fetch_add(object, operand, order)
 . . .
 #elif defined(__GNUC_ATOMICS)
 . . .
 #defineatomic_fetch_add_explicit(object, operand, order)   
 \
__atomic_fetch_add(&(object)->__val, operand, order)
 . . .
 #endif
 . . .
 #defineatomic_fetch_add(object, operand)   
 \
atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
 
 so __atomic_fetch_add would occur.
 
 But so far I do not see the problem with -r335782 reverted. I last built
 -r336693 last night via devel/amd64-gcc (via xtoolchain).
 
 From what I can tell FreeBSD defines:
 
 #if !defined(__CLANG_ATOMICS)
 #define_Atomic(T)  struct { volatile T __val; }
 #endif
 
 and that struct is being used in &(object)->__val is what the
 error reports are about. So that would be, for example,
 
 &(&lock->cnt)->__val
 
 This would appear to suggest that __val itself had a type meeting:
 
 operand type struct 
 
 for T in _Atomic(T) .
 
 (This is independent of just what the issue traces back to: just
 the net result on ci.freebsd.org . No claim that you are right
 or wrong here. I'll not be looking any more until this afternoon
 or night.)
>>> 
>>> Going in a somewhat different direction . . .
>>> 
>>> Looking around I f

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

[John Baldwin]

On 7/25/18 6:52 PM, Mark Millard wrote:
> 
> 
> On 2018-Jul-25, at 2:10 PM, Mark Millard  wrote:
> 
> 
> 
>> On 2018-Jul-25, at 10:09 AM, Mark Millard  wrote:
>>
>>> On 2018-Jul-25, at 8:39 AM, John Baldwin  wrote:
>>>
 On 7/24/18 11:39 PM, Mark Millard wrote:
> On 2018-Jul-24, at 10:32 PM, Mark Millard  wrote:
>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>> (head -r336573 after the prior 6596's -r336565 ):
>>
>> --- all_subdir_lib/ofed ---
>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>  from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid 
>> initializer
>> atomic_store(&lock->cnt, 0);
>> ^
>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
>> 'fastlock_acquire':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 
>> 'struct  *' is incompatible with argument 1 of 
>> '__atomic_fetch_add'
>> if (atomic_fetch_add(&lock->cnt, 1) > 0)
>> ^~
>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 
>> 'fastlock_release':
>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 
>> 'struct  *' is incompatible with argument 1 of 
>> '__atomic_fetch_sub'
>> if (atomic_fetch_sub(&lock->cnt, 1) > 1)
>> ^~
>> . . .
>> --- all_subdir_lib/ofed ---
>> *** [acm.o] Error code 1
>>
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>> -r336700 ) still shows this type of error.
>
>
> [I should have a subject with "head -r336568 through -r336570 . . .".]
>
> From what I can tell looking around having something like:
>
> if (atomic_fetch_add(&lock->cnt, 1) > 0)
>
> involve a __atomic_fetch_add indicates that:
>
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>
> was in use instead of FreeBSD's stdatomic.h file.
>
> If this is right, then the issue may be tied to head -r335782
> implicitly changing the order of the include file directory
> searching for builds via the devel/*-gcc .
>
> (I reverted -r335782 in my environment some time ago and have
> not run into this problem in my context so far.)

 C11 atomics should work fine with compiler-provided headers since they
 are a part of the language (and the system stdatomic.h simply attempts
 to mimic the compiler-provided header in case it is missing).

 Simple standalone tests of _Atomic(int) with GCC don't trigger those
 failures when using its stdatomic.h, so there is probably something else
 going on with kernel includes being used while building the library,
 etc.  The last time we had this issue with stdarg.h it was because a
 header shared between the kernel and userland always used 
 ''
 which is correct for the kernel but not for userland.
>>>
>>> I did misread the headers. FreeBSD has the likes of:
>>>
>>> #if defined(__CLANG_ATOMICS)
>>> . . .
>>> #define atomic_fetch_add_explicit(object, operand, order)   
>>> \
>>> __c11_atomic_fetch_add(object, operand, order)
>>> . . .
>>> #elif defined(__GNUC_ATOMICS)
>>> . . .
>>> #define atomic_fetch_add_explicit(object, operand, order)   
>>> \
>>> __atomic_fetch_add(&(object)->__val, operand, order)
>>> . . .
>>> #endif
>>> . . .
>>> #define atomic_fetch_add(object, operand)   
>>> \
>>> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
>>>
>>> so __atomic_fetch_add would occur.
>>>
>>> But so far I do not see the problem with -r335782 reverted. I last built
>>> -r336693 last night via devel/amd64-gcc (via xtoolchain).
>>>
>>> From what I can tell FreeBSD defines:
>>>
>>> #if !defined(__CLANG_ATOMICS)
>>> #define _Atomic(T)  struct { volatile T __val; }
>>> #endif
>>>
>>> and that struct is being used in &(object)->__val is what the
>>> error reports are about. So that would be, for example,
>>>
>>> &(&lock->cnt)->__val
>>>
>>> This would appear to suggest that __val itself had a type meeting:
>>>
>>> operand type struct 
>>>
>>> for T in _Atomic(T) .
>>>
>>> (This is independent of just what the issue traces back to: just
>>> the net result on ci.freebsd.org . No claim that you are right
>>> or wrong here. I'll not be looking any more until this afternoon
>>> or night.)
>>
>> Going in a somewhat different direction . . .
>>
>> Looking around I found https://bugs.llvm.org/show_bug.cgi?id=26462
>> which is titled:
>>
>> 26462 – GCC/clang C11 _Atomic incompatibility
>>
>> It appears that the normal source of platform ABI definitions are
>> not explicit/detaile

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> 
> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> "Rodney W. Grimes"  > wrote:
> 
 On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
 
 On Wed, 25 Jul 2018 11:46:07 +0300
 Toomas Soome  wrote:
 
>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
>> 
>> On Tue, 24 Jul 2018 08:53:36 +0300
>> Toomas Soome  wrote:
>> 
>> 
>> Hello  Toomas Soome,
>> 
>> I CC Allan Jude since I discovered something  weird today regarding the
>> UEFI boot capabilities of USB flash devices and SSDs. See below.
>> 
 On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
 
 On Mon, 23 Jul 2018 10:56:04 +0300
 Toomas Soome  wrote:
 
>> On 23 Jul 2018, at 10:27, O. Hartmann 
>> wrote:
>> 
>> On Fri, 13 Jul 2018 18:44:23 +0300
>> Toomas Soome mailto:tso...@me.com>> wrote:
>> 
 On 13 Jul 2018, at 17:44, O. Hartmann >>> > wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Am Fri, 13 Jul 2018 14:26:51 +0300
 Toomas Soome mailto:tso...@me.com>
 >> schrieb:   
>> On 13 Jul 2018, at 14:00, O. Hartmann 
>> wrote:
>> 
>> The problem is some kind of weird. I face UEFI boot problems on
>> GPT drives where the first partition begins at block 40 of the
>> hdd/ssd.
>> 
>> I have two host in private use based on an
>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
>> Socket LGA1155). Both boards are equipted with the lates
>> official available AMI firmware revision, dating to 2013. This
>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
>> for the Spectre/Meltdown mitigation is available, but I didn't
>> test that. But please read.
>> 
>> The third box I realised this problem is a brand new Fujitsu
>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
>> 3413-A1x, date 05/25/2018 (or 20180525).
>> 
>> Installing on any kind of HDD or SSD manually or via bsdinstall
>> the OS using UEFI-only boot method on a GPT partitioned device
>> fails. The ASRock boards jump immediately into the firmware,
>> the Fujitsu offers some kind of CPU/Memory/HDD test facility.
>> 
>> If on both type of vendor/boards CSM is disabled and UEFI boot
>> only is implied, the MBR partitioned FreeBSD installation USB
>> flash device does boot in UEFI! I guess I can assume this when
>> the well known clumsy 80x25 char console suddenly gets bright
>> and shiny with a much higher resoltion as long the GPU supports
>> EFI GOP. Looking with gpart at the USB flash drives reveals
>> that the EFI partition starts at block 1 of the device and the
>> device has a MBR layout. I haven't found a way to force the GPT
>> scheme, when initialised via gpart, to let the partitions start
>> at block 1. This might be a naiv thinking, so please be patient
>> with me.
>> 
>> I do not know whether this is a well-known issue. On the ASRock
>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI
>> and that worked - FreeBSD not. I gave up on that that time.
>> Now, having the very same issues with a new Fujitsu system,
>> leaves me with the impression that FreeBSD's UEFI
>> implementation might have problems I'm not aware of.
>> 
>> Can someone shed some light onto this? 
>> 
> 
> The first thing to check is if the secure boot is disabled. We
> do not support secure boot at all at this time.  
 
 Secure boot is in every scenario disabled!
 
> 
> If you have efi or bios version running - you can check from
> either console variable value (it can have efi or vidconsole or
> comconsole) or better yet, see if efi-version is set (show
> efi-version) - if efi-version is not set, it is BIOS loader
> running. Another indirect way is to see lsdev -v, with device
> paths present, it is uefi:)  
 
 What are you talking about?
 What is the point of entry - running system, loader?
 
 sysct machdep.bootmethod: BIOS
>

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> > > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > > 
> > > On Wed, 25 Jul 2018 11:46:07 +0300
> > > Toomas Soome  wrote:
> > >   
> > >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> > >>> 
> > >>> On Tue, 24 Jul 2018 08:53:36 +0300
> > >>> Toomas Soome  wrote:
> > >>> 
> > >>> 
> > >>> Hello  Toomas Soome,
> > >>> 
> > >>> I CC Allan Jude since I discovered something  weird today regarding the
> > >>> UEFI boot capabilities of USB flash devices and SSDs. See below.
> > >>>   
> > > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > > 
> > > On Mon, 23 Jul 2018 10:56:04 +0300
> > > Toomas Soome  wrote:
> > >   
> > >>> On 23 Jul 2018, at 10:27, O. Hartmann 
> > >>> wrote:
> > >>> 
> > >>> On Fri, 13 Jul 2018 18:44:23 +0300
> > >>> Toomas Soome mailto:tso...@me.com>> wrote:
> > >>>   
> > > On 13 Jul 2018, at 17:44, O. Hartmann  > > > wrote:
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > Am Fri, 13 Jul 2018 14:26:51 +0300
> > > Toomas Soome mailto:tso...@me.com>
> > > >> schrieb:   
> > >>> On 13 Jul 2018, at 14:00, O. Hartmann 
> > >>> wrote:
> > >>> 
> > >>> The problem is some kind of weird. I face UEFI boot problems on
> > >>> GPT drives where the first partition begins at block 40 of the
> > >>> hdd/ssd.
> > >>> 
> > >>> I have two host in private use based on an
> > >>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
> > >>> Socket LGA1155). Both boards are equipted with the lates
> > >>> official available AMI firmware revision, dating to 2013. This
> > >>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
> > >>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
> > >>> for the Spectre/Meltdown mitigation is available, but I didn't
> > >>> test that. But please read.
> > >>> 
> > >>> The third box I realised this problem is a brand new Fujitsu
> > >>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
> > >>> 3413-A1x, date 05/25/2018 (or 20180525).
> > >>> 
> > >>> Installing on any kind of HDD or SSD manually or via bsdinstall
> > >>> the OS using UEFI-only boot method on a GPT partitioned device
> > >>> fails. The ASRock boards jump immediately into the firmware,
> > >>> the Fujitsu offers some kind of CPU/Memory/HDD test facility.
> > >>> 
> > >>> If on both type of vendor/boards CSM is disabled and UEFI boot
> > >>> only is implied, the MBR partitioned FreeBSD installation USB
> > >>> flash device does boot in UEFI! I guess I can assume this when
> > >>> the well known clumsy 80x25 char console suddenly gets bright
> > >>> and shiny with a much higher resoltion as long the GPU supports
> > >>> EFI GOP. Looking with gpart at the USB flash drives reveals
> > >>> that the EFI partition starts at block 1 of the device and the
> > >>> device has a MBR layout. I haven't found a way to force the GPT
> > >>> scheme, when initialised via gpart, to let the partitions start
> > >>> at block 1. This might be a naiv thinking, so please be patient
> > >>> with me.
> > >>> 
> > >>> I do not know whether this is a well-known issue. On the ASRock
> > >>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI
> > >>> and that worked - FreeBSD not. I gave up on that that time.
> > >>> Now, having the very same issues with a new Fujitsu system,
> > >>> leaves me with the impression that FreeBSD's UEFI
> > >>> implementation might have problems I'm not aware of.
> > >>> 
> > >>> Can someone shed some light onto this? 
> > >>>   
> > >> 
> > >> The first thing to check is if the secure boot is disabled. We
> > >> do not support secure boot at all at this time.  
> > > 
> > > Secure boot is in every scenario disabled!
> > >   
> > >> 
> > >> If you have efi or bios version running - you can check from
> > >> either console variable value (it can have efi or vidconsole or
> > >> comconsole) or better yet, see if efi-version is set (show
> > >> efi-version) - if efi-version is not set, it is BIOS loader
> > >> running. Another indirect way is to see lsdev -v, with device
> > >> paths present, it is uefi:)  
> > > 
> > > What are you talking about?
> > > What is the point of entry - running system, loader?
> > > 
> > > sysct machdep.bootmethod: BI