Re: [UEFI] Boot issues on some UEFI implementations
> On 24 Jul 2018, at 09:20, Allan Jude wrote: > > On 2018-07-13 07: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? >> >> Thanks in advance, >> >> Oliver >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > > If you are up for experimenting, see if either of these results in your > system booting: > gpart set -a active ada0 > gpart set -a lenovofix ada0 > > Although both of these should only impact BIOS boot, not UEFI, you never > know. > > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) > > oops, indeed, and not just FAT32, but rather large one; first, the minimum size for FAT32 is ~32MB - it can not be smaller, and with 4kn you can not get below 256MB:) but, I recall there were some reports about systems refusing to boot if ESP was not FAT32. I can not remember if there was some size limit involved too or not (the UEFI specification does not set requirements for ESP size). my 2cents, toomas ___ 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
On 2018-07-13 07: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? > > Thanks in advance, > > Oliver > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > If you are up for experimenting, see if either of these results in your system booting: gpart set -a active ada0 gpart set -a lenovofix ada0 Although both of these should only impact BIOS boot, not UEFI, you never know. The other option is to try an ESP (EFI System Partition) that is formatted FAT32 instead of FAT12/FAT16) -- Allan Jude signature.asc Description: OpenPGP digital signature
i386 top reporting nan% or inf% WCPU
I recently merged my work in progress tree up to r336665 and built a i386 VM image. Running the image in QEMU (qemu-system-x86_64) and executing 'top' I see the WCPU column reported as either nan% or inf% for all processes. Prior to today I hadn't built or tested i386 in a while, so I am not sure off hand if this is a recent issue. amd64 is fine. Is anyone else seeing this? ___ 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: i386 top reporting nan% or inf% WCPU
On Tue, Jul 24, 2018 at 01:43:55PM -0400, Ed Maste wrote: > I recently merged my work in progress tree up to r336665 and built a > i386 VM image. Running the image in QEMU (qemu-system-x86_64) and > executing 'top' I see the WCPU column reported as either nan% or inf% > for all processes. > > Prior to today I hadn't built or tested i386 in a while, so I am not > sure off hand if this is a recent issue. amd64 is fine. Is anyone else > seeing this? I believe this is a qemu bug. Their FPU emulation is very basic, at least it was so several years ago, when not using accelerated emulation. ___ 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: i386 top reporting nan% or inf% WCPU
In message <20180724181703.gk65...@kib.kiev.ua>, Konstantin Belousov writes: > On Tue, Jul 24, 2018 at 01:43:55PM -0400, Ed Maste wrote: > > I recently merged my work in progress tree up to r336665 and built a > > i386 VM image. Running the image in QEMU (qemu-system-x86_64) and > > executing 'top' I see the WCPU column reported as either nan% or inf% > > for all processes. > > > > Prior to today I hadn't built or tested i386 in a while, so I am not > > sure off hand if this is a recent issue. amd64 is fine. Is anyone else > > seeing this? > > I believe this is a qemu bug. Their FPU emulation is very basic, at least > it was so several years ago, when not using accelerated emulation. Just tested on the i386 slice on my laptop. No problems there. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: ntpd as ntpd user question
On Mon, Jul 23, 2018 at 09:28:41PM -0700, Kevin Oberman wrote: > On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: > > > On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > > > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > > > > > > > Yes, first you press m. Then you will see differences of installed > > > > file (left) and new file (right). Then you press either l or > > > > r: > > > > > > > > l | 1: choose left diff > > > > r | 2: choose right diff > > > > > > > > If the diff tries to remove/add to many lines you can: > > > > > > > > el: edit left diff > > > > er: edit right diff > > > > > > > > And if done you can view the merged file (v) before installing (i) > > > > it. > > > > > > > > I am sure, someone can explain it better! :) > > > > > > > Perhaps, but you've made the essential point. Your reply let me > > > understand that > > > mergemaster does not really "master" the merge, it rather identifies > > > files needing > > > to be merged and then starts sdiff to let me modify files. Never > > > having even looked > > > at sdiff, the learning curve proved very steep. Too steep, in fact. > > > > > > I'm going to try a more incremental approach. > > > > > > Thank you _very_ much! > > > > > > bob prohaska > > > > Your reaction to mergemaster is about the same as mine was when I first > > encountered it very long ago, and re-discovered when I tried it a > > couple years ago. It just seems like more trouble than it's worth, I > > can usually figure out what's broken and fix it by hand faster than > > messing with all the merge stuff. > > > > But, someone told me that if you give mergemaster the right flags it > > can potentially be intervention-free. Those apparently aren't the flag > > or two that're suggested at the bottom of UPDATING. So I didn't really > > dig into that any deeper, but I toss it out there in case someone can > > expand on it. > > > > It certainly makes some sense that it could be done intervention-free. > > When doing other diff-based merges (like 'svn update') you only have to > > intervene when there's an actual conflict between some local change > > you've made and the incoming changes. > > > > > It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you > have modified will show up. In most cases, it just zips right by. In most > that it does not, the use of 'r' or 'l' in merge is all you need and always > 'r' eccepton lines you have modified, yourself, so you should know about > them. > I realize your comments are directed to Ian and not me, so please take these $.02 for no more than they're worth. My problems with mergemaster are _not_ with mergemaster. They're with sdiff. The window presented, along with the prompts, are simply bewildering. I suspect that someboey truly fluent with vi would recognize what's going on at once and have no trouble. I've used vi for a long time, but only in the most naive way, and sdiff's man page is little help for a newcomer. Even a Web search for tutorials found nothing very useful, at least not quickly. A plain language discription of what sdif does and how might make the minutia of the man page comprehensible to non-experts. Apologies if I'm belaboring the obvious, and thanks for reading! bob prohaska ___ 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: ntpd as ntpd user question
On Tue, 24 Jul 2018 06:28:41 +0200, Kevin Oberman wrote: On Mon, Jul 23, 2018 at 7:25 PM, Ian Lepore wrote: On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > Yes, first you press m. Then you will see differences of installed > > file (left) and new file (right). Then you press either l or > > r: > > > > l | 1: choose left diff > > r | 2: choose right diff > > > > If the diff tries to remove/add to many lines you can: > > > > el: edit left diff > > er: edit right diff > > > > And if done you can view the merged file (v) before installing (i) > > it. > > > > I am sure, someone can explain it better! :) > > > Perhaps, but you've made the essential point. Your reply let me > understand that > mergemaster does not really "master" the merge, it rather identifies > files needing > to be merged and then starts sdiff to let me modify files. Never > having even looked > at sdiff, the learning curve proved very steep. Too steep, in fact. > > I'm going to try a more incremental approach. > > Thank you _very_ much! > > bob prohaska Your reaction to mergemaster is about the same as mine was when I first encountered it very long ago, and re-discovered when I tried it a couple years ago. It just seems like more trouble than it's worth, I can usually figure out what's broken and fix it by hand faster than messing with all the merge stuff. But, someone told me that if you give mergemaster the right flags it can potentially be intervention-free. Those apparently aren't the flag or two that're suggested at the bottom of UPDATING. So I didn't really dig into that any deeper, but I toss it out there in case someone can expand on it. It certainly makes some sense that it could be done intervention-free. When doing other diff-based merges (like 'svn update') you only have to intervene when there's an actual conflict between some local change you've made and the incoming changes. It gets a LOT simpler if you use "mergemaster -iPUF" Only those files you have modified will show up. In most cases, it just zips right by. In most that it does not, the use of 'r' or 'l' in merge is all you need and always 'r' eccepton lines you have modified, yourself, so you should know about them. I should note that 'U' does have a small "race" in it, so it i possible to get biten by it, but it is very unlikely. Has to do with multiple commits that touch the same lines in the file in a timing that is out of sync with your running it. I use '-iPF' because I m paranoid. $ cat /etc/mergemaster.rc AUTO_INSTALL=yes AUTO_UPGRADE=yes COMP_CONFS=yes FREEBSD_ID=yes IGNORE_FILES='/etc/motd /etc/printcap' This helps me a lot. Cheers, Ronald. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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"
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 '__a
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(>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(>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(>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. === 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: [UEFI] Boot issues on some UEFI implementations
On Tue, 24 Jul 2018 02:20:00 -0400 Allan Jude wrote: > On 2018-07-13 07: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? > > > > Thanks in advance, > > > > Oliver > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > If you are up for experimenting, see if either of these results in your > system booting: > gpart set -a active ada0 > gpart set -a lenovofix ada0 > > Although both of these should only impact BIOS boot, not UEFI, you never > know. > > The other option is to try an ESP (EFI System Partition) that is > formatted FAT32 instead of FAT12/FAT16) How can I detect the format of the EFI partition? Suppose I create the EFI partition via gpart, 12-CURRENT installer or 11.2-RELENG installer, what format would that EFI partition be (the partition scheme I use is always GPT so far and as far as I know)? What format is the result, if I would dd /boot/boot1.efifat to the EFI partition? >From a first glimpse I guess its FAT12/16, since creating an EFI partition via gpart myself of 500m and try to newfs_msdos -F 32, I receive an error about insufficient clusters with no further parameters. I tried to create a 512m partition fiddling around with the blocksize option -b of newfs_msdos When created manually /dev/gpt/efiboot0, formatted FAT32 (with -b 512 or -b 1024, I forgot) and preparing/copying the content of /boot/boot1.efifat (mdconfig mounted ...) with proper folder structure to efi/boot/ on the newly created FAT32 formatted EFI partition, I struggle then with a quick installation of FreeBSD using "bsdinstall". Having created according to a pure ZFS disk swap, gptboot (to be on the secure side if UEFI fails again) and a zroot ZFS pool, the dumb installer doesn't let me create a filesystem structure on ZFS for the installation without destroying the initial layout :-( So I stopped at that point and tried booting the box with only the FAT32 EFI/ESP partition with the loader copied from boot1.efifat as described. The result is annoying, the ESPRIMO Q956 firmware shows up with some kind of testing tool/shell as reported in the initial posting of mine. I'd have expected some signs from the FreeBSD UEFI bootloader so far at this point, but I might be mislead here. I also have applied the "gpart set -a" commands, without any effect. > ___ 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.
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? 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. -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"
