Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

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
> > 
> > This makes me quite sure that the system has booted via BIOS - as I'm
> > sure since I've checked that many times. UEFI doesn't work on those
> > systems with FreeBSD. I'm not sure antmore, but I tried also Windows 7
> > on those mainboards booting via UEFI - and I might recall that they
> > failed also. I also recall that there were issues with earlier UEFI
> > versions regarding booting only Windows 8/8.1 - and nothing else, but
> > the fact that Linux worked confuses me a bit.
> > 
> > If this ASRock crap (never ever again this brand!) doesn't work at all -
> > who cares, I intend to purchase new server grade hardware. But the more
> > puzzling issue is with the Fujitsu, which I consider serious and from
> > the behaviour the Fujitsu failure looks exactly like the ASRock -
> > Windows 7 works, RedHat 7.5 works (I assume I can tru

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> 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
>>> 
>>> This makes me quite sure that the system has booted via BIOS - as I'm
>>> sure since I've checked that many times. UEFI doesn't work on those
>>> systems with FreeBSD. I'm not sure antmore, but I tried also Windows 7
>>> on those mainboards booting via UEFI - and I might recall that they
>>> failed also. I also recall that there were issues with earlier UEFI
>>> versions regarding booting only Windows 8/8.1 - and nothing else, but
>>> the fact that Linux worked confuses me a bit.
>>> 
>>> If this ASRock crap (never ever again this brand!) doesn't work at all -
>>> who cares, I intend to purchase new server grade hardware. But the more
>>> puzzling issue is with the Fujitsu, which I consider serious and from
>>> the behaviour the Fujitsu failure looks exactly like the ASRock -

Re: [UEFI] Boot issues on some UEFI implementations

[Toomas Soome]

> 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
> 
> This makes me quite sure that the system has booted via BIOS - as I'm
> sure since I've checked that many times. UEFI doesn't work on those
> systems with FreeBSD. I'm not sure antmore, but I tried also Windows 7
> on those mainboards booting via UEFI - and I might recall that they
> failed also. I also recall that there were issues with earlier UEFI
> versions regarding booting only Windows 8/8.1 - and nothing else, but
> the fact that Linu

Re: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

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
> >>> 
> >>> This makes me quite sure that the system has booted via BIOS - as I'm
> >>> sure since I've checked that many times. UEFI doesn't work on those
> >>> systems with FreeBSD. I'm not sure antmore, but I tried also Windows 7
> >>> on those mainboards booting via UEFI - and I might recall that they
> >>> failed also. I also recall that there were issues with earlier UEFI
> >>> versions regarding booting only Windows 8/8.1 - and nothing else, but
> >>> the fact that Linux worked confuses me a bit.
> >>> 
> >>> 

Spam in console after r336593 (NFS mounted)

[Andrey Fesenko]

Hello.
After https://svnweb.freebsd.org/base?view=revision&revision=336593
any make action starting spam errors (svn not work on NFS mounted
partitions)

svn: E155016: The working copy database at '/usr/src' is corrupt.
svn: E155016: The working copy database at '/usr/src' is corrupt.
make[2]: "/usr/src/release/Makefile.ec2" line 24: warning:
"/usr/local/bin/svn info --show-item last-changed-revision /usr/sr
c/release/.." returned non-zero status
svn: E155016: The working copy database at '/usr/src' is corrupt.
svn: E155016: The working copy database at '/usr/src' is corrupt.
make[2]: "/usr/src/release/Makefile.ec2" line 24: warning:
"/usr/local/bin/svn info --show-item last-changed-revision /usr/sr
c/release/.." returned non-zero status
___
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"

error building r336696: cp: asn1_OCSPResponseStatus.c: Bad address

[Eitan Adler]

I'm currently on r335788 and trying to build r336696.

When running make -s buildworld buildkernel -j33 I get the following.
Any help is appreciated to fix.

CMD cp -f asn1_OCSPResponseStatus.x asn1_OCSPResponseStatus.c
CWD /srv/obj/fbsd/usr/src/amd64.amd64/kerberos5/lib/libhx509
TARGET asn1_OCSPResponseStatus.c
-- command output --
cp: asn1_OCSPResponseStatus.c: Bad address


src.conf
===
MALLOC_PRODUCTION=true
WITHOUT_SVNLITE=true
WITHOUT_LIB32=true
WITH_CLANG_EXTRAS=true
WITH_BSD_GREP=true
WITH_GNU_GREP_COMPAT=true
WITH_EXTRA_TCP_STACKS=true
WITH_LOADER_LUA=true
WITHOUT_FORTH=true
WITH_SORT_THREADS=true

src-env.conf
===
MAKEOBJDIRPREFIX?=/srv/obj/fbsd
WITH_META_MODE=yes

make.conf
===
WRKDIRPREFIX=/srv/obj/fbsd/ports
DISTDIR=/srv/obj/distfiles
FORMATS=html
DEVELOPER=yes
WITH_PKGNG=devel
CPUTYPE?=znver1

# Set here for ports development only
DEFAULT_VERSIONS+=ssl=openssl


-- 
Eitan Adler
___
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: [UEFI] Boot issues on some UEFI implementations

[Rodney W. Grimes]

> > 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
> > 
> > This makes me quite sure that the system has booted via BIOS - as 
> > I'm
> > sure since I've c

Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.

[Julian Elischer]

On 22/7/18 3:11 am, Yuri Pankov wrote:

Yuri Pankov wrote:

Julian Elischer wrote:

I would really like ot get some pointers as to who are our tools
committers at the moment, in particular who might know about these 
issues.

The main issue for me at the moment is the ability to compile the
aesni code in Samba from clang..

Julian


On 20/7/18 7:32 pm, Julian Elischer wrote:

compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour
when lld became the linker I think..

1/ linking needed some directories added to some of the build
scripts because previously apparently it looked in $SYSROOT/usr/lib
by default and now it doesn't.

2/ compiling our samba produces a libtdb.so that has various symbols
in it, (according to nm(1) ), but when we try link against it we get
complaints about those symbols not being defined.

3/ an attempt to switch to using clang to compile everything 
leads to:



"--aes-accel=intelaesni selected and compiler rejects 
-Wp,-E,-lang-asm.


One wonders whether there is a clang equivalent of 
"-Wp,-E,-lang-asm"


The AES acceleration is a configure option for the samba package.

Apparently turning it on requires -Wp,-E,-lang-asm.

which apparently gcc 4.2.1 has, but clang doesn't have.

     FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) 
(based

     on LLVM 6.0.1)
     Target: x86_64-unknown-freebsd12.0
     Thread model: posix
     InstalledDir: /usr/bin

anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?


In later GCC versions the cpp's -lang-asm seems to be deprecated in
favor of -x assembler-with-cpp as it conflicts with -l option.

Could you try changing the -Wp,-E,-lang-asm to 
-Wp,-E,-xassembler-with-cpp?


Just tried it myself, and if you indeed mean the 
third_party/aesni-intel/aesni-intel_asm.c, the following seems to 
work for me:


clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c


when I try it I get lots of errors due to hte fact that there are 
assembled comments that start with #

and they are all cited as errors by clang.
I had to put '//' before about 80 lines line that.





possible work arrounds include:

1/ Get gcc/lld to produce a library from which lld can find the 
symbols


2/ find a way to compile this with clang but everything else with 
gcc?


3/ find a way to allow clang to use
-Wp,-E,-lang-asm

whatever that means


Thoughts from any tools people?





___
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/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.

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

[Mark Millard]

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


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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/25/18 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

This looks wrong for modern GCC supporting C11 atomics.  What is happening is
that this is probably overriding the compiler's builtin _Atomic and then the
compiler's stdatomic.h which doesn't look for __val but expects 'object' to
be a plain int is then failing to compile.  Just including sys/cdefs.h in
my test program doesn't trigger the failure though.

-- 
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: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

[...]

> > Yea, i was hoping fstyp command would report the FAT type, but it does not 
> > (request
> > for feature?:)  
> 
> FYI, the file(1) command is very good at disecting a disk image to tell
> you what the MBR looks like, and at looking at partitions if pointed at
> them with the -s option.  It should be able to detect FAT12/16/32.
> 
> root@x230a:/home/ISO/x # file -s /dev/md2s1
> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", root 
> entries
> 512, sectors 1600 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 
> 1, serial
> number 0xbd4111ee, label: "EFISYS ", FAT (12 bit), followed by FAT

Thanks for this very helpful hint!

> 
> > 
> > However, the more annoying idea would be to install some OS which will boot 
> > with UEFI
> > on this machine, then copy boot1.efi from freebsd to it (the default 
> > program the UEFI
> > will load is ESP:EFI/boot/bootx64.efi  in case of UEFI64 and
> > ESP:EFI/boot/bootia32.efi for EFI32. However, we do not support EFI32.
> > 
> > note that boot1.efi alone will not do much but printing on screen how it 
> > will search
> > for freebsd, but for the purpose of the test it would suffice - that would 
> > give us
> > confirmed working ESP file system (since the other os would be able to 
> > boot) and then
> > we can confirm if boot1.efi itself is OK.  
> 



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW1i2PwAKCRDS528fyFhY
lFz5Af9MY41hoAND4OoKCOwExAM7oQYVCpHSz+mo94OBVqSCqcnprdvdE2C1+PiN
Uza7lMvB8KVSqcyxuYbIFD0E5A4bAgCk/lzKwE9hTPBt4gdBx4t7N/XPafOEBEGM
8irGozKbAvikSkhAQTMPtwyE+861AvKy2Dw1o+mQo4AfikJI0dgq
=9cKL
-END PGP SIGNATURE-
___
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: [UEFI] Boot issues on some UEFI implementations

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 25 Jul 2018 12:26:13 +0300
Toomas Soome  schrieb:

> > 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: 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-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/detailed in the area and allow for incompatibilities
in this area. clang and gcc made differing choices absent being
constrained to match.

An example (a powerpc64 context was indicated):

struct A16 { char val[16]; }; 
_Atomic struct A16 a16; 
// GCC:
_Static_assert(_Alignof(a16) == 16, ""); 
// Clang:
_Static_assert(_Alignof(a16)

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-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/detailed in the area and allow for incompatibilities
> in this area. clang and gcc made differing choices absent being
> constrained to match.
> 
> 

Re: em0 link fail

[R. Tyler Croy]

(replies inline)

On Sun, 15 Jul 2018, Michael Butler wrote:

> On 07/05/18 09:54, I wrote:
> > On 07/05/18 09:27, tech-lists wrote:
> >> On 03/07/2018 19:47, Michael Butler wrote:
> >>> That would've been ..
> >>>
> >>> Jun  1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun
> >>> 1 08:25:58 EDT 2018
> >>>
> >>> I'm going to build one with SVN r334862 reverted to see if that works,
> >>
> >> Hi,
> >>
> >> Is it working now? Am asking because a system I'd like to take from
> >> 11-stable to 12 uses the em driver.
> > 
> > No :-( I haven't had the chance yet to revisit it,
> 
> As it turns out, SVN r336313 (committed today) solves the issue I was
> having with the hardware stalling,



Just to add a bit more metadata to this thread, I've seen this exact same 
behavior for a few months now! I've recently rebuilt to r336294 which still 
exhibited the problem, with periodic logs such as these:

Jul 26 04:09:53 strawberry kernel: em1: Watchdog timeout Queue[0]-- 
resetting
Jul 26 04:09:53 strawberry kernel: Interface is RUNNING and ACTIVE
Jul 26 04:09:53 strawberry kernel: em1: TX Queue 0 --
Jul 26 04:09:53 strawberry kernel: em1: hw tdh = 524, hw tdt = 544
Jul 26 04:09:53 strawberry kernel: em1: Tx Queue Status = -2147483648
Jul 26 04:09:53 strawberry kernel: em1: TX descriptors avail = 1004
Jul 26 04:09:53 strawberry kernel: em1: Tx Descriptors avail failure = 0
Jul 26 04:09:53 strawberry kernel: em1: RX Queue 0 --
Jul 26 04:09:53 strawberry kernel: em1: hw rdh = 172, hw rdt = 170
Jul 26 04:09:53 strawberry kernel: em1: RX discarded packets = 0
Jul 26 04:09:53 strawberry kernel: em1: RX Next to Check = 171
Jul 26 04:09:53 strawberry kernel: em1: RX Next to Refresh = 170
Jul 26 04:09:53 strawberry kernel: em1: link state changed to DOWN
Jul 26 04:09:54 strawberry kernel: em1: link state changed to UP
Jul 26 04:10:20 strawberry kernel: em1: Watchdog timeout Queue[0]-- 
resetting
Jul 26 04:10:20 strawberry kernel: Interface is RUNNING and ACTIVE
Jul 26 04:10:20 strawberry kernel: em1: TX Queue 0 --
Jul 26 04:10:20 strawberry kernel: em1: hw tdh = 0, hw tdt = 358
Jul 26 04:10:20 strawberry kernel: em1: Tx Queue Status = -2147483648
Jul 26 04:10:20 strawberry kernel: em1: TX descriptors avail = 666
Jul 26 04:10:20 strawberry kernel: em1: Tx Descriptors avail failure = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Queue 0 --
Jul 26 04:10:20 strawberry kernel: em1: hw rdh = 0, hw rdt = 1023
Jul 26 04:10:20 strawberry kernel: em1: RX discarded packets = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Next to Check = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Next to Refresh = 1023
Jul 26 04:10:20 strawberry kernel: em1: link state changed to DOWN


I'll give r336313 a try as soon as possible and corroborate the fixes!


Cheers,
R Tyler Croy


signature.asc
Description: PGP signature

Re: error building r336696: cp: asn1_OCSPResponseStatus.c: Bad address

[Eitan Adler]

On Wed, 25 Jul 2018 at 06:31, Eitan Adler  wrote:
>
> I'm currently on r335788 and trying to build r336696.

Going to r336238 and then r336732 seems to have succeeded.


-- 
Eitan Adler
___
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: gcc/clang interoperability problem with a custom "samba" build in recent -current.

[Julian Elischer]

On 25/7/18 12:40 am, Julian Elischer wrote:

On 22/7/18 4:32 am, Dimitry Andric wrote:

On 21 Jul 2018, at 21:11, Yuri Pankov  wrote:

Yuri Pankov wrote:

Julian Elischer wrote:

...

anyone know if there is a clang equivalent of -Wp, -E,-lang-asm?

In later GCC versions the cpp's -lang-asm seems to be deprecated in
favor of -x assembler-with-cpp as it conflicts with -l option.
Could you try changing the -Wp,-E,-lang-asm to 
-Wp,-E,-xassembler-with-cpp?
I did this but if failed.. I had to reread this email  a few times to 
think of replacing the whole

-Wp,-E,-lang-asm  with just  -xassembler-with-cpp!


Just tried it myself, and if you indeed mean the 
third_party/aesni-intel/aesni-intel_asm.c, the following seems to 
work for me:


clang -xassembler-with-cpp -c 
third_party/aesni-intel/aesni-intel_asm.c

Yes, that is exactly what I suggested to Julian on IRC.  The point is
that the ".c" extension is misleading, it should more likely be a ".S"
extension.  But maybe this source file is used for multiple purposes.

Note that -x assembler-with-cpp should also work fine for gcc.

Ah..  the trick is to remove the -Wp,-E as well...


-Dimitry


thanks

I tried that but the version of the file we have has several lines 
that caused problems...


a lot of the assembler has assembler comments (starting with '#') 
which clang complained about and died..


it also had #.align 4

which I HOPE is just a commented out line..
___
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"




___
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"