Re: automake-wrapper conflicts

2018-07-27 Thread blubee blubeeme 
On Sat, Jul 28, 2018 at 10:41 AM blubee blubeeme 
wrote:

> I am getting some build errors around automake-wrapper.
>
> I tried deinstalling automake-wrapper and then installing automake but
> then during the installation of automake I get this error:
>
> install-info: warning: no info dir entry in
> `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info
> '
>  /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
>  install  -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1
> doc/automake-1.16.1
> '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
>  /bin/mkdir -p
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
>  install  -m 0644 lib/Automake/Config.pm
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
> /usr/bin/make  install-data-hook
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
>  chmod +x
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
> find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl:
> No such file or directory
> > Compressing man pages (compress-man)
> ===>  Installing for automake-1.16.1
> ===>  Checking if automake already installed
> ===>   Registering installation for automake-1.16.1
> Installing automake-1.16.1...
> pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203
> (installs files into the same place).  Problematic file:
> /usr/local/bin/aclocal
> *** Error code 70
>
>
> Is this just me or a bug?
>
> Best,
> Owen
>

Okay, seems that UPDATING addresses this issue!

Best,
Owen
___
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"

automake-wrapper conflicts

2018-07-27 Thread blubee blubeeme 
I am getting some build errors around automake-wrapper.

I tried deinstalling automake-wrapper and then installing automake but then
during the installation of automake I get this error:

install-info: warning: no info dir entry in
`/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info'
 /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1'
 install  -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1
doc/automake-1.16.1
'/usr/ports/devel/automake/work/stage/usr/local/man/man1'
 /bin/mkdir -p
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
 install  -m 0644 lib/Automake/Config.pm
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake'
/usr/bin/make  install-data-hook
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
 chmod +x
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl:
No such file or directory
> Compressing man pages (compress-man)
===>  Installing for automake-1.16.1
===>  Checking if automake already installed
===>   Registering installation for automake-1.16.1
Installing automake-1.16.1...
pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203
(installs files into the same place).  Problematic file:
/usr/local/bin/aclocal
*** Error code 70


Is this just me or a bug?

Best,
Owen
___
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: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Brad Davis 
On Fri, Jul 27, 2018, at 4:08 PM, Brad Davis wrote:
> On Fri, Jul 27, 2018, at 1:52 PM, Brad Davis wrote:
> > On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote:
> > > r336743 CONFSGRP should be CONFSGROUP ?
> > > 
> > > > On 28 Jul 2018, at 1:30 AM, Charlie Li  wrote:
> > > > 
> > > > On 27/07/2018 13:21, Martin Wilke wrote:
> > > >> I just upgraded a jail in poudriere with latest head, 
> > > >> https://dpaste.de/bfTT/raw .
> > > >> 
> > > > I was about to inquire about this myself. Can additionally confirm this
> > > > has been happening since at least r336735.
> > 
> > I'll update my poudriere jail shortly and see if I can reproduce it.
> > 
> > But CONFSGRP is correct, see share/mk/bsd.confs.mk.
> 
> FYI, I have opened this review if you want to try the patch:
> 
> https://reviews.freebsd.org/D16476

Committed in r336794.


Regards,
Brad Davis
___
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: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Brad Davis 
On Fri, Jul 27, 2018, at 1:52 PM, Brad Davis wrote:
> On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote:
> > r336743 CONFSGRP should be CONFSGROUP ?
> > 
> > > On 28 Jul 2018, at 1:30 AM, Charlie Li  wrote:
> > > 
> > > On 27/07/2018 13:21, Martin Wilke wrote:
> > >> I just upgraded a jail in poudriere with latest head, 
> > >> https://dpaste.de/bfTT/raw .
> > >> 
> > > I was about to inquire about this myself. Can additionally confirm this
> > > has been happening since at least r336735.
> 
> I'll update my poudriere jail shortly and see if I can reproduce it.
> 
> But CONFSGRP is correct, see share/mk/bsd.confs.mk.

FYI, I have opened this review if you want to try the patch:

https://reviews.freebsd.org/D16476


Regards,
Brad Davis
___
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: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Antoine Brodin 
On Fri, Jul 27, 2018 at 7:21 PM, Martin Wilke  wrote:
> Hi,
>
> I just upgraded a jail in poudriere with latest head, 
> https://dpaste.de/bfTT/raw .

portmgr@ reproduces this issue too.

Antoine
___
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: svn commit: r336751 - head/usr.sbin/pw

2018-07-27 Thread Li-Wen Hsu 
On Fri, Jul 27, 2018 at 4:22 PM Ian Lepore  wrote:
> This was just an error on my part, the code was wrong and I fixed it in
> r336762. This time I made sure the kyua tests pass first.
>
> I had intended to run the kyua tests before and after re-applying my
> changes to pw(8). Now that I look in my scrollback, it seems I ran the
> "before" tests, then got distracted and forgot to run them again after
> and just committed the changes. Sorry about the breakage.

No worries, now the test job is back to normal:

https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8377/

Thanks for your help!

Li-Wen

-- 
Li-Wen Hsu 
https://lwhsu.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"

Re: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Brad Davis 
On Fri, Jul 27, 2018, at 12:08 PM, Martin Wilke wrote:
> r336743 CONFSGRP should be CONFSGROUP ?
> 
> > On 28 Jul 2018, at 1:30 AM, Charlie Li  wrote:
> > 
> > On 27/07/2018 13:21, Martin Wilke wrote:
> >> I just upgraded a jail in poudriere with latest head, 
> >> https://dpaste.de/bfTT/raw .
> >> 
> > I was about to inquire about this myself. Can additionally confirm this
> > has been happening since at least r336735.

I'll update my poudriere jail shortly and see if I can reproduce it.

But CONFSGRP is correct, see share/mk/bsd.confs.mk.


Regards,
Brad Davis
___
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: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Charlie Li 
On 27/07/2018 14:08, Martin Wilke wrote:
> r336743 CONFSGRP should be CONFSGROUP ?
> 
That line doesn't seem to make any difference.

Probably a jemalloc interaction? Emitted when attempting to update a
-CURRENT arm64.aarch64 cross-build jail:

===> sbin/dump (installconfig)
--- _CONFSINS_null ---
install  -C -o root  -g operator -m 664  /dev/null
/usr/local/poudriere/jails/aarch64-current/etc/dumpdates
: jemalloc_rtree.c:205: Failed assertion: "!dependent || leaf
!= NULL"
Abort trap (core dumped)
*** [_CONFSINS_null] Error code 134

make[4]: stopped in
/usr/local/poudriere/jails/aarch64-current/usr/src/sbin/dump
1 error

Looking at my amd64.amd64 logs again, the failed assertion message does
indeed appear there as well.

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-27 Thread Warner Losh 
[[ context trimmed ]]

On Fri, Jul 27, 2018 at 12:03 PM, Warner Losh  wrote:

>
>
> On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann 
> wrote:
>
>>
>> Just to add another success on ASRock Z77-Pro4 (800k ESP, FAT12) and
>> ASRock Z77-Pro4M
>> (300mb ESP, FAT32).
>>
>> On this firmware, I did not have to define/copy the bootloader
>> within /efi/freebd/BOOTx64.efi. It was sufficient to add an EFI variable
>> as described in
>> the manpage efibootmgr(8).
>>
>> The only pitfall on this firmware (very old, last functional update 2013,
>> Spectre/Meltodown mitigation only May 2018) was that I wasn't able to
>> activate variable
>> ""! Creating
>>
>> efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L FreeBSD-12
>>
>> which results in "Boot"
>>
>> and followed by
>>
>> efibootmgr -a 
>>
>> or
>>
>> efibootmgr -n 
>>
>> resulted in "No such variable" or similar.
>>
>
> Yes. that's a bogus sanity check in the code. I've removed it and will
> commit in a moment.
>

that should be fixed as of r336768.


> I had to perform the very same task again to gain variable 0001 and then I
>> was able to
>> "activate" variable . This might be due to the fact the only variable
>> defined at all
>> was Boot0005 pointing to the most recent USB flash device with 12-CURRENT
>> from 2018-07-26
>> I just prepared.
>>
>
That part is weird


> Now, also those boxes boot via UEFI (one, 800k ESP with the /efi/boot
>> folder, the other,
>> 300mb ESP, with a copy /efi/freebsd as I had to do on the Fujitsu ESPRIMO
>> Q956 firmware).
>
>
> OK.
>

Cool!...

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

Re: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Martin Wilke 
r336743 CONFSGRP should be CONFSGROUP ?

> On 28 Jul 2018, at 1:30 AM, Charlie Li  wrote:
> 
> On 27/07/2018 13:21, Martin Wilke wrote:
>> I just upgraded a jail in poudriere with latest head, 
>> https://dpaste.de/bfTT/raw .
>> 
> I was about to inquire about this myself. Can additionally confirm this
> has been happening since at least r336735.
> 
> -- 
> Charlie Li
> Can't think of a witty .sigline today…
> 
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
> 

___
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

2018-07-27 Thread Warner Losh 
On Fri, Jul 27, 2018 at 11:05 AM, O. Hartmann 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Fri, 27 Jul 2018 13:59:44 +0300
> Toomas Soome  schrieb:
>
> > > On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> > >
> > > On Fri, 27 Jul 2018 08:54:48 +0300
> > > Toomas Soome  wrote:
> > >
> > >>> 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 <
> ohartm...@walstatt.org>
> >  wrote:
> > 
> >  On Mon, 23 Jul 2018 10:56:04 +0300
> >  Toomas Soome  wrote:
> > 
> > >> On 23 Jul 2018, at 10:27, O. Hartmann <
> ohartm...@walstatt.org>
> > >> 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 <
> o.hartm...@walstatt.org
> >  > 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
> >

Re: make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Charlie Li 
On 27/07/2018 13:21, Martin Wilke wrote:
> I just upgraded a jail in poudriere with latest head, 
> https://dpaste.de/bfTT/raw .
> 
I was about to inquire about this myself. Can additionally confirm this
has been happening since at least r336735.

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

make distribution fails, A failure has been detected in another branch of the parallel make

2018-07-27 Thread Martin Wilke 
Hi,

I just upgraded a jail in poudriere with latest head, 
https://dpaste.de/bfTT/raw .

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

2018-07-27 Thread O. Hartmann 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 27 Jul 2018 13:59:44 +0300
Toomas Soome  schrieb:

> > On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> > 
> > On Fri, 27 Jul 2018 08:54:48 +0300
> > Toomas Soome  wrote:
> >   
> >>> 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
> >

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

2018-07-27 Thread Mark Millard 
On 2018-Jul-27, at 8:52 AM, Mark Millard  wrote:

> On 2018-Jul-27, at 12:12 AM, Mark Millard  wrote:
> 
> On 2018-Jul-26, at 11:29 PM, Mark Millard  wrote:
> 
>> . . .
>> I was looking too locally: the overall context has an outer #if
>> as well that skips the section:
>> 
>> /*
>> * Keywords added in C11.
>> */
>> 
>> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
>> . . .
>> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
>>   !__has_extension(cxx_atomic)
>> /*
>> * No native support for _Atomic(). Place object in structure to prevent
>> * most forms of direct non-atomic access.
>> */
>> #define _Atomic(T)  struct { T volatile __val; }
>> #endif
>> . . .
>> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
>> 
>> 
>> 
>> 
>> The build with gcc's float.h also removed did complete instead of
>> stopping early.
>> 
>> 
>> 
>> As for what x86_64-unknown-freebsd12.0 .h files were used:
>> (some may do include_next back into FreeBSD headers)
>> 
>> 
>> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R 
>> .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | more
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h
>> R 56022 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h
>> R 1222 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h
>> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h
>> R 1222 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h
>> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h
>> R 1336 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h
>> R 1485 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h
>> R 1595 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rtmintrin.h
>> R 1520 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/shaintrin.h
>> R 1485 
>> /usr/local/lib/gcc/x86_64-unknown-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

2018-07-27 Thread Mark Millard 



On 2018-Jul-27, at 12:12 AM, Mark Millard  wrote:

On 2018-Jul-26, at 11:29 PM, Mark Millard  wrote:

> . . .
> I was looking too locally: the overall context has an outer #if
> as well that skips the section:
> 
> /*
> * Keywords added in C11.
> */
> 
> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> . . .
> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
>!__has_extension(cxx_atomic)
> /*
> * No native support for _Atomic(). Place object in structure to prevent
> * most forms of direct non-atomic access.
> */
> #define _Atomic(T)  struct { T volatile __val; }
> #endif
> . . .
> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
> 
> 
> 
> 
> The build with gcc's float.h also removed did complete instead of
> stopping early.
> 
> 
> 
> As for what x86_64-unknown-freebsd12.0 .h files were used:
> (some may do include_next back into FreeBSD headers)
> 
> 
> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R 
> .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | more
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h
> R 56022 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h
> R 1520 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h
> R 1336 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h
> R 1485 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h
> R 1595 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rtmintrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/shaintrin.h
> R 1485 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/smmintrin.h
> R 1 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdarg.h
> R 27622 
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
> R 1 /usr/

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

2018-07-27 Thread John Baldwin 
On 7/27/18 12:12 AM, Mark Millard wrote:
> I was looking too locally: the overall context has an outer #if
> as well that skips the section:
> 
> /*
>  * Keywords added in C11.
>  */
>  
> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> . . .
> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
> !__has_extension(cxx_atomic)
> /*
>  * No native support for _Atomic(). Place object in structure to prevent
>  * most forms of direct non-atomic access.
>  */
> #define _Atomic(T)  struct { T volatile __val; }
> #endif
> . . .
> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */

Yes.  It also means that if we didn't ship the compiler's stdatomic.h and
tried to build with -std=gnu11 or -std=c11 the compile would break.

Rather than requiring c11, another approach might be to fix sys/cdefs.h
and sys/stdatomic.h to actually work with modern GCC by having them not
use the struct for the _GCC_ATOMICS case, only for the _SYNC case.

I think that would fix all of the cases.

-- 
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: svn commit: r336751 - head/usr.sbin/pw

2018-07-27 Thread Ian Lepore 
On Fri, 2018-07-27 at 14:43 +, Li-Wen Hsu wrote:
> On Thu, Jul 26, 2018 at 20:03:11 +, Ian Lepore wrote:
> > 
> > Author: ian
> > Date: Thu Jul 26 20:03:11 2018
> > New Revision: 336751
> > URL: https://svnweb.freebsd.org/changeset/base/336751
> > 
> > Log:
> >   Re-apply r336625 which was reverted with r336638, now that the underlying
> >   pw_scan(3) has been fixed in a way that doesn't perturb other callers of
> >   it or the getpwnam(3) family.
> >   
> >   Make pw(8) showuser work the same with or without -R  for non-root
> >   users.  Without -R, pw(8) uses getpwnam(3), which will open master.passwd
> >   for the root user or passwd for non-root users.  With -R  pw(8) was
> >   always opening /master.passwd, which would fail for a non-root user,
> >   then falsely claim the userid you're trying to show doesn't exist.
> >   
> >   Now for a non-root user it opens /passwd, and populates the fields in
> >   the returned struct passwd which aren't present in that file with 
> > well-known
> >   canonical values, which duplicates the behavior of getpwnam(3).  The net
> >   effect is that the showuser output is identical whether using -R or not.
> > 
> > Modified:
> >   head/usr.sbin/pw/pw_vpw.c
> Hi Ian,
> 
> It seems usr.sbin.pw.* tests are failing after this commit:
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/
> 
> Can you help me check this is realted to the new pw code or there is
> anything we need to modify in the test VM setup or running environment.
> 
> The related artifacts are available here:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/
> 
> You can use disk-test.img.xz which is a VM with setup testing
> environment.  The build script will start automatically but you can
> ctrl-c to interrupt anytime and run tests by hand:
> 
> cd /usr/tests/usr.sbin/pw
> kyua test

This was just an error on my part, the code was wrong and I fixed it in
r336762. This time I made sure the kyua tests pass first.

I had intended to run the kyua tests before and after re-applying my
changes to pw(8). Now that I look in my scrollback, it seems I ran the
"before" tests, then got distracted and forgot to run them again after
and just committed the changes. Sorry about the breakage.

-- Ian

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

Re: svn commit: r336751 - head/usr.sbin/pw

2018-07-27 Thread Li-Wen Hsu 
On Thu, Jul 26, 2018 at 20:03:11 +, Ian Lepore wrote:
> Author: ian
> Date: Thu Jul 26 20:03:11 2018
> New Revision: 336751
> URL: https://svnweb.freebsd.org/changeset/base/336751
> 
> Log:
>   Re-apply r336625 which was reverted with r336638, now that the underlying
>   pw_scan(3) has been fixed in a way that doesn't perturb other callers of
>   it or the getpwnam(3) family.
>   
>   Make pw(8) showuser work the same with or without -R  for non-root
>   users.  Without -R, pw(8) uses getpwnam(3), which will open master.passwd
>   for the root user or passwd for non-root users.  With -R  pw(8) was
>   always opening /master.passwd, which would fail for a non-root user,
>   then falsely claim the userid you're trying to show doesn't exist.
>   
>   Now for a non-root user it opens /passwd, and populates the fields in
>   the returned struct passwd which aren't present in that file with well-known
>   canonical values, which duplicates the behavior of getpwnam(3).  The net
>   effect is that the showuser output is identical whether using -R or not.
> 
> Modified:
>   head/usr.sbin/pw/pw_vpw.c

Hi Ian,

It seems usr.sbin.pw.* tests are failing after this commit:

https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/

Can you help me check this is realted to the new pw code or there is
anything we need to modify in the test VM setup or running environment.

The related artifacts are available here:

https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/

You can use disk-test.img.xz which is a VM with setup testing
environment.  The build script will start automatically but you can
ctrl-c to interrupt anytime and run tests by hand:

cd /usr/tests/usr.sbin/pw
kyua test


Thanks,
Li-Wen


-- 
Li-Wen Hsu 
https://lwhsu.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"

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-27 Thread Toomas Soome 


> On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> 
> On Fri, 27 Jul 2018 08:54:48 +0300
> Toomas Soome  wrote:
> 
>>> 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.

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-27 Thread O. Hartmann 
On Fri, 27 Jul 2018 08:54:48 +0300
Toomas Soome  wrote:

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

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

2018-07-27 Thread Mark Millard 
On 2018-Jul-26, at 11:29 PM, Mark Millard  wrote:

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