Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 12/07/2018 19:32, Dimitry Andric wrote: No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes , an intrinsics header, which in turn requires . This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, and at the time resulted in similar build failures, specifically when one attempted to build a new kernel, without building world or a new toolchain first. Hi, Ok, it's finished building and installing. The command I used was this: # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 and it all built, (so I'll close the PR I opened). Then I did make installkernel KERNCONF=RPI3 and because I thought might as well install everything now it's built, mergemaster -p and make installworld && mergemaster -Ui. So I take it then, that every time I want to build a kernel, I either have to do the above or use make kernel-toolchain. Is this correct? thanks, -- J. ___ 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"
Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND
Hello. The target host is a Fujitsu Esprimo Q956 Firmware V5.0.0.11 R1.26.0 for A3413-A1x Date 05/25/2018 BIOS Revision 1.26 FreeBSD 11.2-RELEASE and 12-CURRENT (ISO Image from 9th July 2018, r336134) are spamming the console with an annoying error: Jul 13 10:00:32 kernel: Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) Jul 13 10:00:32 kernel: ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND (20171214/psparse-677) Jul 13 10:00:32 kernel: Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) The error is repeated endless. Can this be fixed? Thanks in advance and kind regards, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
Yuri wrote: On 07/03/18 12:45, Yuri wrote: I updated the laptop to r335884 last night, and 'service wpa_supplicant start wlan0' doesn't succeed any more. kernel is supposed to create the network interface 'run0', but it doesn't. This is the immediate reason why wpa_supplicant fails. The non-creation of 'run0' is a regression. I don't know of any workaround. The steps 'mergemaster -p' and 'mergemaster' were done during the upgrade, so /etc is updated. Bug report for this problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 This is a very serious regression breaking WiFi. It's likely the switch from using usb.conf to devmatch.conf (see r329148). I can confirm the problem, inserting the ralink usb wifi dongle doesn't do anything (I'm not using it anymore so I didn't notice the problem), though the action in devmatch.conf is executed, so it might be the problem somewhere below in devmatch(8). ___ 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"
[UEFI] Boot issues on some UEFI implementations
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"
Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
Yuri Pankov wrote: Yuri wrote: On 07/03/18 12:45, Yuri wrote: I updated the laptop to r335884 last night, and 'service wpa_supplicant start wlan0' doesn't succeed any more. kernel is supposed to create the network interface 'run0', but it doesn't. This is the immediate reason why wpa_supplicant fails. The non-creation of 'run0' is a regression. I don't know of any workaround. The steps 'mergemaster -p' and 'mergemaster' were done during the upgrade, so /etc is updated. Bug report for this problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 This is a very serious regression breaking WiFi. It's likely the switch from using usb.conf to devmatch.conf (see r329148). I can confirm the problem, inserting the ralink usb wifi dongle doesn't do anything (I'm not using it anymore so I didn't notice the problem), though the action in devmatch.conf is executed, so it might be the problem somewhere below in devmatch(8). And looks like it's fixed in r335763 (for me, at least). ___ 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"
[REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT)
I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs
CURRENT for very long time (from 11-CURRENT times), and recently it
start to consume much more CPU on same traffic — to the point when it
becomes unresponsive in shell (via ssh, not local console).
I have rather complex ipfw ruleset, but this ruleset is the same for
many years.
Revisions before r333989 worked normally, I never seen any problem with
shell, no matter how much traffic is processed
Revision r334649 with same configuration, same firewall ruleset, etc.,
becomes completely unresponsive under network load (pure transit traffic).
when system is unresponsive I see this in `top -SH`
100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
And it is new to me.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Re: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT)
On 13.07.2018 14:10, Lev Serebryakov wrote:
> when system is unresponsive I see this in `top -SH`
>
> 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
> 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
>
> And it is new to me.
Oh, this MoBo has (and uses) two em0 adapters:
em0@pci0:2:0:0: class=0x02 card=0x202c8086 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
em1@pci0:1:0:0: class=0x02 card=0x202c8086 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
HD Audio Emulation For Bhyve
Hi! First post to the mailing list. I was trying out the https://reviews.freebsd.org/D12419 on a recent FreeBSD current (>= 336229) but didn’t get it to work using debian 9 as a guest. Mpg123 just hangs when trying to play a mp3. Also tried Ubuntu 18 but that just hangs at boot time at “Detecting sound card”. I’ve compiled bhyve WITHOUT_CAPSICUM but that doesn’t seem to solve anything. Also built with DEBUG_HDA and that doesn’t output any errors. Sound works just fine on the host system. Any hints? Thanks! ___ 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: Deadlocks / hangs in ZFS
Quoting Andriy Gapon (from Fri, 13 Jul 2018 14:50:48 +0300): On 12/07/2018 15:42, Alexander Leidinger wrote: #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 Do you have any local modifications to ZFS code? Yes, this is with https://reviews.freebsd.org/D7538 Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpbCuLJFJ0ex.pgp Description: Digitale PGP-Signatur
Re: [UEFI] Boot issues on some UEFI implementations
> 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. 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:) GPT partitions can never start from disk absolute sector 1; this is because at sector 0 there is MBR (for compatibility), sector 1 is GPT table and then sectors 2-33 have GPT partition table entries, so the first possible data sector is 34 (absolute 34). Thats assuming 512B sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. rgds, 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: Deadlocks / hangs in ZFS
On 12/07/2018 15:42, Alexander Leidinger wrote: > #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532 Do you have any local modifications to ZFS code? I cannot find that function. -- Andriy Gapon ___ 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: Deadlocks / hangs in ZFS
On Thu, Jul 12, 2018 at 02:42:29PM +0200, Alexander Leidinger wrote:
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0 __curthread () at ./machine/pcpu.h:230
> #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
> #2 0x80485e11 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:446
> #3 0x804863f3 in vpanic (fmt=, ap=0xfe457870)
> at /usr/src/sys/kern/kern_shutdown.c:863
> #4 0x80486443 in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:790
> #5 0x8075279f in trap_fatal (frame=0xfe457a50,
> eva=32) at /usr/src/sys/amd64/amd64/trap.c:892
> #6 0x80752812 in trap_pfault (frame=0xfe457a50,
> usermode=)
> at /usr/src/sys/amd64/amd64/trap.c:728
> #7 0x80751e1a in trap (frame=0xfe457a50) at
> /usr/src/sys/amd64/amd64/trap.c:427
> #8
> #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
> #10 arc_reclaim_thread (unused=)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4657
> #11 0x8044ca74 in fork_exit (callout=0x81391b90
> , arg=0x0,
> frame=0xfe457c00) at /usr/src/sys/kern/kern_fork.c:1057
> #12
> (kgdb) up 9
> #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
> 4532lowest +=
> uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone);
> (kgdb) list
> 4527int iter = 4;
> 4528int step = 1 << (SPA_MAXBLOCKSHIFT
> - SPA_MINBLOCKSHIFT - 3);
> 4529int n = (SPA_MAXBLOCKSIZE >>
> SPA_MINBLOCKSHIFT) - 1;
> 4530
> 4531while (n >= 0) {
> 4532lowest +=
> uma_zone_get_free_size(zio_data_buf_cache[n]->kc_zone);
> 4533if (lowest >= 0)
> 4534return lowest;
> 4535n -= step;
> 4536if(--iter == 0) {
> (kgdb) print n
> $1 = 32767
> (kgdb) print zio_data_buf_cache[n]
> $2 = (kmem_cache_t *) 0x0
> (kgdb)
Very strange, zio_data_buf_cache[] can't be NULL, as asserted in
zio_init.
___
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 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. This sounds like a tool showing you the protective MBR which is part of GPT. > > 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. > > 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:) > > GPT partitions can never start from disk absolute sector 1; this is because > at sector 0 there is MBR (for compatibility), sector 1 is GPT table and then > sectors 2-33 have GPT partition table entries, so the first possible data > sector is 34 (absolute 34). Thats assuming 512B sectors. For details see > UEFI 2.7 Chapter 5.3.1 page 131. > One must be carefull when looking at a GPT scheme device, as it still has a "protective MBR" at sector 0 which covers sectors 1 to N of the device. Legacy (mbr only) tools well see this and show it as type 0xEE covering the whole device. Some modern tools still show this as an MBR, but then also show the GPT's inside it. Some tools never show you the protective MBR. -- Rod Grimes rgri...@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"
options COMPAT_AOUT to file UPDATING to know
=== Reason: In compiling the kernel again after a long time after 'pkg upgrade' the following errors. The Intel graphics card is in use and something had changed, the 'startx' did not start the XFCE session. This was the reason to compile the kernel again with the new sources of today. After two retries taking some time to complite, it would be helpful to ... === Symptom: --- kernel.full --- linking kernel.full ld.lld: error: undefined symbol: aout_sysvec >>> referenced by imgact_gzip.c:240 (/usr/src/sys/kern/imgact_gzip.c:240) >>> imgact_gzip.o:(Flush) === Resolution: Adding options COMPAT_AOUT to the kernel configuration file. This added the necessary 'imgact_aout.o' to the linking and the 'aout_sysvec' was found. __ It would be nice if a message was written in the /usr/src/UPDATING about this to prevent the unnecessary retries. Probably COMPAT_LINUXKPI needs this setting with 'device gzip' since COMPAT_AOUT was defined in a kernel module object, not in a kernel object file. Somewhere in time the COMPAT_AOUT did not exist after the 11-stable and this time it was necessary (today 13:th of July 2018) with the Intel driver. It has been necessary somewhere between 16:th of May to today (from these kernel timestamps). Who knows I don't know. It would be a good idea to add a note to the UPDATING as information for all of the Intel graphics users about the aout to be necessary to use less time in testing the error. br, jla ___ 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: aarch64-arm64 fails to build kernel 12-current raspberry pi 3
On 2018-Jul-13, at 3:15 AM, tech-lists wrote: > On 12/07/2018 19:32, Dimitry Andric wrote: >> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes >> , an intrinsics header, which in turn requires . >> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921, >> and at the time resulted in similar build failures, specifically when >> one attempted to build a new kernel, without building world or a new >> toolchain first. > > Hi, > > Ok, it's finished building and installing. The command I used was this: > > # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3 make -j10 buildworld buildkernel KERNCONF=RPI3 would have worked. > and it all built, (so I'll close the PR I opened). Then I did make > installkernel KERNCONF=RPI3 and because I thought might as well install > everything now it's built, mergemaster -p and make installworld && > mergemaster -Ui. > > So I take it then, that every time I want to build a kernel, I either have to > do the above or use make kernel-toolchain. Is this correct? If you first clear out the old build, then such would be true. (Where, for targeting aarch64, kernel-toolchain needs to be avoided.) But you can buildkernel using the results of the existing buildworld (or kernel-toolchain if it applies) when it is okay to not clear out the old build first. (kernel developers doing kernel development likely do this a lot.) Another way to make tradeoffs is to use META_MODE so that partial rebuilds are done, avoiding some of the strictly unnecessary rebuild activity. This would involve buildworld or kernel-toolchain (as appropriate for the target architecture). === 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Fri, 13 Jul 2018 14:26:51 +0300 Toomas Soome 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 trust the Firmware settings when I disable CSM support, that the Firmware will only EFI/UEFI capable loader? Or is there a ghosty override somwhere to be expected?). Also on ASRock disabling CSM should ensure not booting a dual-bootstrap-capable system. This said, on the recent Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware interaction problem, while the ASRock is still under suspicion to be broken by design. > > GPT partitions can never start from disk absolute sector 1; this is because > at sector 0 > there is MBR (for compatibility), sector 1 is GPT table and then sectors 2-33 > have GPT > partition table entries, so the first possible data sector is 34 (absolute > 34). Thats > assuming 512B sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. Thanks for the explanation. That implies the installer did right, gpart did also right and therefore there must be an issue with the stuff located within the EFI partition? > > rgds, > toomas Thank you very much and kind regards, Oliver > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.free
Re: [UEFI] Boot issues on some UEFI implementations
> 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 > trust the > Firmware settings when I disable CSM support, that the Firmware will only > EFI/UEFI > capable loader? Or is there a ghosty override somwhere to be expected?). Also > on ASRock > disabling CSM should ensure not booting a dual-bootstrap-capable system. This > said, on > the recent Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware > interaction > problem, while the ASRock is still under suspicion to be broken by design. > >> >> GPT partitions can never start from disk absolute sector 1; this is because >> at sector 0 >> there is MBR (for compatibility), sector 1 is GPT table and then sectors >> 2-33 have GPT >> partition table entries, so the first possible data sector is 34 (absolute >> 34). Thats >> assuming 512B sectors. For details see UEFI 2.7 Chapter 5.3.1 page 131. > > Thanks for the explanation. That implies the installer did right, gpart did > also right > and therefore there must be an issue with the stuff located within the EFI > partiti
HEAD i386 r336217 : wireless connection fails ( ath(4) )
I'm experiencing wireless connection failure after HEAD/i386 update performed today. Below is relevant portion of dmesg buffer: Jul 12 18:43:39 desktop kernel: wlan0: Ethernet address: 18:a6:f7:8a:b1:52 Jul 12 18:43:39 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:39 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='' freq=2412 MHz) Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:41 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:41 desktop dhclient[641]: New IP Address (wlan0): 192.168.0.50 Jul 12 18:43:41 desktop dhclient[642]: New Subnet Mask (wlan0): 255.255.255.0 Jul 12 18:43:41 desktop dhclient[643]: New Broadcast Address (wlan0): 192.168.0.255 Jul 12 18:43:41 desktop dhclient[644]: New Routers (wlan0): 192.168.0.1 Jul 12 18:43:42 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:42 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:42 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='' freq=2412 MHz) Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:45 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:45 desktop dhclient[269]: send_packet: No buffer space available Jul 12 18:43:46 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:46 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:46 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Trying to associate with f8:1a:67:56:16:16 (SSID='' freq=2412 MHz) Jul 12 18:43:49 desktop kernel: wlan0: link state changed to UP Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a: 67:56:16:16 Jul 12 18:43:49 desktop dhclient[269]: send_packet: No buffer space available Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1 Jul 12 18:43:50 desktop kernel: wlan0: link state changed to DOWN Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-SSID-TEMP- DISABLED id=22 ssid="" auth_failures=1 duration=10 reason=CONN_FAILED Jul 12 18:43:50 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Trying to associate with SSID 'test adhoc' Jul 12 18:43:53 desktop wpa_supplicant[257]: bsd_set_if_media: SIOCSIFMEDIA Device not configured Jul 12 18:43:53 desktop wpa_supplicant[257]: wpa_driver_bsd_associate: failed to set operation mode Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Association request to the driver failed Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=-1 id_str=] Jul 12 18:43:56 desktop dhclient[269]: send_packet: Network is down Jul 12 18:44:04 desktop dhclient[269]: send_packet: Network is down Jul 12 18:45:01 desktop dhclient[269]: send_packet: Network is down Jul 12 18:45:05 desktop dhclient[1739]: New IP Address (wlan0): 192.168.0.50 Jul 12 18:45:05 desktop dhclient[1740]: New Subnet Mask (wlan0): 255.255.255.0 Jul 12 18:45:05 desktop dhclient[1741]: New Broadcast Address (wlan0): 192.168.0.255 Jul 12 18:45:05 desktop dhclient[1742]: New Routers (wlan0): 192.168.0.1 Jul 12 18:45:06 desktop dhclient[1744]: New Routers (wlan0): 192.168.0.1 ___ 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: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On 07/12/2018 21:15, Yuri wrote: On 07/12/18 13:38, Pete Wright wrote: sorry if i missed something (don't see details in the bug report) - is the issue that the run(4) kernel module is not being loaded? is there an error when the system attempts to load the kernel module in the dmesg buffer? if it is not being loaded automagically what happens when you manually load the module via "kldload" or by updating rc.conf? No errors while the kernel module is loaded. The problem is that when the card is inserted wlan0 isn't automatically created. It also isn't created during boot with the card in. I think that there were some changes in devd that caused this regression. interesting, i ran into an issue with a kernel/world i updated to on thursday where my USB mouse was non-functional and i suspect something funky happened with devd as well. one suggestion i heard was to enable devmatch which i haven't had a chance to test yet. throwing it out there as it may help you. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r336252 - in head: [ broke the ci.freebsd.org's FreeBSD-head-{mips,mips64,powerpc,powerpc64,sparc64,???}-build ]
[Note: mips64 built for -r336251 but failed for -r336252 and -r336253 .] An example (mips64): --- all_subdir_stand --- cc1: warnings being treated as errors /usr/src/stand/libsa/geli/geliboot_crypto.c: In function 'geliboot_crypt': /usr/src/stand/libsa/geli/geliboot_crypto.c:45: warning: 'blks' may be used uninitialized in this function *** [geliboot_crypto.o] Error code 1 (A bunch of architectures are still building their first build after -r336251 .) === 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"
