FreeBSD EFI projects
On 9/16/18 9:32 PM, Warner Losh wrote: > > What did you have in mind working on? I have a few things that are in > various stages of completeness around this issue that I've not had > time to polish off for the tree. Some I'd like to, but some may > benefit from a fresh perspective. Also, there's a fair number of > hidden bugs in the stuff committed around finding the whole path > sometimes and the like. One thing I've started working on is switching the ESP to use FAT32 everywhere except the ISO images (due to the limitation in the El Torito format not supporting sufficiently large regions). The specifications from EFI 1.10 onward have been clear that only FAT32 is supported for the ESP (but that FAT12 and FAT16 must be supported for removable devices), and I've read that some systems do enforce that. Unfortunately that does mean the ESP must be a minimum of 33MB, but I think it's worthwhile for increased compatibility. Related to that, I've also been working on removing the FAT filesystem templates that are currently checked into svn, instead generating them during the release stage. I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old Apple systems that use 32-bit EFI: it sounds like it should be possible, and is something I'd like to try and get working. I'd also really like to help move the changes to mount an existing ESP during installation instead of clobbering it towards being committed, if possible. Another thing I'd like to work on is trying to catch corner cases like in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210244 where calling GetMemoryMap causes the memory map to become fragmented. I'd also like to try and improve diagnostics, for example at the moment if the system doesn't have enough memory to run the loader it silently exits instead of displaying an error message. And I would also be interested in taking a look at any projects you've not completed yet, to see if I can help in any way. -- Rebecca ___ 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: Bad DHCP Checksums over VLANs
Hi! > >> ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag > >> -vlanhwcsum -vlanhwtso > >> > >> Try to disable everything that can be disabled, e.g. LRO etc. > > > > Disabling vlanhwtag works around the problem. > > > > Also note that only DHCP traffic has this problem. If I assign an > > address manually, all traffic flows normally. Maybe the problem is in > > the BPF send path. > > > I had a similar issue, where -vlanhwtag also fixed it. > That was on a I210 (gib) card (in a FreeNAS mini XL). I've created a PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231416 -- p...@freebsd.org +49 171 3101372 2 years to go ! ___ 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: FreeBSD EFI projects
On Sun, Sep 16, 2018 at 4:31 PM Rebecca Cran wrote: > I'm just getting back into FreeBSD development, and I'm trying to focus > on (U)EFI work. > > It seems there are various things that people would like to have done, > some of which are listed on > https://wiki.freebsd.org/DevSummit/201806/HaveNeedWant12 - and some of > which I know are already being worked on. > > Would a wiki page be useful for coordinating efforts and seeing who's > working on what, or should tasks be tracked through bugzilla? > Bugzilla is OK at individual tasks, but falls down when it comes to creating master bugs. You can do it, but only if you want a master list. It gets harder when you want to add metadata, imho. I much prefer a wiki page to track bigger picture things (though there's nothing wrong with creating a master bugzila bug if you want). That can also give the bigger context and have a richer set of design discussions + howtos than bugzilla would afford, ihmo. What did you have in mind working on? I have a few things that are in various stages of completeness around this issue that I've not had time to polish off for the tree. Some I'd like to, but some may benefit from a fresh perspective. Also, there's a fair number of hidden bugs in the stuff committed around finding the whole path sometimes and the like. 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"
FreeBSD-12-ALPHA6: Network not starting at boot & can't start Plasma 5
I was running a fresh installation of 11.2-stable for the past couple of weeks, and I decided to update from source to 12-current over the weekend. After upgrading and rebooting, my network was no longer starting at boot. It wouldn't work until I ran "service netif restart". Also, after updating I made sure to run "pkg update && pkg upgrade" to reinstall all my packages with ones compiled for FreeBSD 12. I restarted again and tried to log into Plasma 5 from sddm. The screen went black for a moment and immediately returned to the sddm login screen. I removed and reinstalled all packages on my system to see if maybe there was a stale config file left over or something. The login problem persisted. It worked fine under 11.2-stable Thinking perhaps I might have made a mistake in upgrading from source, I downloaded the 12-ALPHA6 snapshot, loaded it onto a USB stick, and did a fresh installaton. The problem with network not starting at boot persists. I haven't done a full install of Plasma 5 yet to test it again. ___ 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 EFI projects
I'm just getting back into FreeBSD development, and I'm trying to focus on (U)EFI work. It seems there are various things that people would like to have done, some of which are listed on https://wiki.freebsd.org/DevSummit/201806/HaveNeedWant12 - and some of which I know are already being worked on. Would a wiki page be useful for coordinating efforts and seeing who's working on what, or should tasks be tracked through bugzilla? -- Rebecca ___ 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: Current-Alpha6 panic with new support.S AMD64
On Sun, Sep 16, 2018 at 01:43:51PM -0700, Manfred Antar wrote: > With r338700 support.S i get panic after rebooting: > > avail memory = 16529514496 (15763 MB) > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 2: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 3: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 3 ACPI ID 4: enabled > SMP: Added CPU 3 (AP) > Event timer "LAPIC" quality 100 > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0x80747d86 > stack pointer = 0x28:0x82451820 > frame pointer = 0x28:0x82451820 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [ thread pid 0 tid 0 ] > Stopped at strcmp+0x6: movb(%rsi),%dl > db> bt > Tracing pid 0 tid 0 td 0x81015180 > strcmp() at strcmp+0x6/frame 0x82451820 > sysctl_register_oid() at sysctl_register_oid+0x4c/frame 0x82451b40 > sysctl_add_oid() at sysctl_add_oid+0x20d/frame 0x82451b90 > et_register() at et_register+0x14d/frame 0x82451bf0 > native_lapic_init() at native_lapic_init+0x4e3/frame 0x82451c10 > madt_setup_local() at madt_setup_local+0x26e/frame 0x82451c40 > apic_setup_local() at apic_setup_local+0x44/frame 0x82451c50 > mi_startup() at mi_startup+0x118/frame 0x82451c70 > btext() at btext+0x2c > db> > > With support.S r338683 no problem What is your cpu ? Show first 50 lines from the verbose dmesg. Also please try this patch. diff --git a/sys/amd64/amd64/support.S b/sys/amd64/amd64/support.S index f86d3d11506..5a4e62faba1 100644 --- a/sys/amd64/amd64/support.S +++ b/sys/amd64/amd64/support.S @@ -122,7 +122,6 @@ ENTRY(memmove_std) movq%rdx,%rcx andq$7,%rcx /* any bytes left? */ jne 2f - movq%r9,%rax POP_FRAME_POINTER ret 2: ___ 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: Bad DHCP Checksums over VLANs
On 16 Sep 2018, at 23:05, Eric van Gyzen wrote: On 9/15/18 1:06 AM, Kurt Jaeger wrote: Can you disable all the options of the NIC ? ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum -vlanhwtso Try to disable everything that can be disabled, e.g. LRO etc. Disabling vlanhwtag works around the problem. Also note that only DHCP traffic has this problem. If I assign an address manually, all traffic flows normally. Maybe the problem is in the BPF send path. I had a similar issue, where -vlanhwtag also fixed it. That was on a I210 (gib) card (in a FreeNAS mini XL). Regards, Kristof ___ 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On 2018-Sep-16, at 1:50 PM, Jilles Tjoelker wrote: > On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote: >> On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > >>> On another note, the comment just below that, > >>> /* But we need to zero-extend (char is unsigned) the value and then >>> perform a signed 32-bit subtraction. */ > >>> shows a wrong reason for doing the right thing since memcmp (as well as >>> strcmp and strncmp) are defined to compare based on unsigned chars, >>> regardless of the signedness of char. > >> Ahh, standard are so much fun: there are so many to choose from. > >> I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function". >> It makes no such explicit claim about using using unsigned chars for >> the comparison standard: > >> QUOTE of the Description part: >> The memcmp function compares the first n characters of the object pointed >> by s1 to the first n characters of the object pointed by s2. >> END QUOTE > >> QUOTE of the Returns part: >> The memcmp function returns an integer greater than, equal to, or less >> than zero, accordingly as the object pointed to by s1 is greater than, >> equal to, or less than the object pointed to by s2. >> END QUOTE > >> If I had to guess the intent of "characters" would be based on the >> char type for C11. I did not find anything about the issue in the C99 >> rationale that I also happen to have available to look at. > > In C99, C11 and C17, the text about using unsigned chars is under > "Comparison functions" and it applies to memcmp, strcmp and strncmp > (which are documented together in the section). > >> For all I know, POSIX or other standards may be more explicit and not >> agree. > > POSIX does not document memcmp, strcmp and strncmp close together and > copies the text about using unsigned chars to each of them. This means > that it agrees with the C standards. > Thanks for noting the factored-out material in the C11 standard. Sorry for the noise of missing that factorization when I looked up memcmp. === 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: Bad DHCP Checksums over VLANs
On 9/15/18 1:06 AM, Kurt Jaeger wrote: Can you disable all the options of the NIC ? ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum -vlanhwtso Try to disable everything that can be disabled, e.g. LRO etc. Disabling vlanhwtag works around the problem. Also note that only DHCP traffic has this problem. If I assign an address manually, all traffic flows normally. Maybe the problem is in the BPF send path. Eric ___ 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote: > On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > > On another note, the comment just below that, > >/* But we need to zero-extend (char is unsigned) the value and then > > perform a signed 32-bit subtraction. */ > > shows a wrong reason for doing the right thing since memcmp (as well as > > strcmp and strncmp) are defined to compare based on unsigned chars, > > regardless of the signedness of char. > Ahh, standard are so much fun: there are so many to choose from. > I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function". > It makes no such explicit claim about using using unsigned chars for > the comparison standard: > QUOTE of the Description part: > The memcmp function compares the first n characters of the object pointed > by s1 to the first n characters of the object pointed by s2. > END QUOTE > QUOTE of the Returns part: > The memcmp function returns an integer greater than, equal to, or less > than zero, accordingly as the object pointed to by s1 is greater than, > equal to, or less than the object pointed to by s2. > END QUOTE > If I had to guess the intent of "characters" would be based on the > char type for C11. I did not find anything about the issue in the C99 > rationale that I also happen to have available to look at. In C99, C11 and C17, the text about using unsigned chars is under "Comparison functions" and it applies to memcmp, strcmp and strncmp (which are documented together in the section). > For all I know, POSIX or other standards may be more explicit and not > agree. POSIX does not document memcmp, strcmp and strncmp close together and copies the text about using unsigned chars to each of them. This means that it agrees with the C standards. -- Jilles Tjoelker ___ 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"
Current-Alpha6 panic with new support.S AMD64
With r338700 support.S i get panic after rebooting: avail memory = 16529514496 (15763 MB) MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) Event timer "LAPIC" quality 100 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x80747d86 stack pointer = 0x28:0x82451820 frame pointer = 0x28:0x82451820 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 0 () [ thread pid 0 tid 0 ] Stopped at strcmp+0x6: movb(%rsi),%dl db> bt Tracing pid 0 tid 0 td 0x81015180 strcmp() at strcmp+0x6/frame 0x82451820 sysctl_register_oid() at sysctl_register_oid+0x4c/frame 0x82451b40 sysctl_add_oid() at sysctl_add_oid+0x20d/frame 0x82451b90 et_register() at et_register+0x14d/frame 0x82451bf0 native_lapic_init() at native_lapic_init+0x4e3/frame 0x82451c10 madt_setup_local() at madt_setup_local+0x26e/frame 0x82451c40 apic_setup_local() at apic_setup_local+0x44/frame 0x82451c50 mi_startup() at mi_startup+0x118/frame 0x82451c70 btext() at btext+0x2c db> With support.S r338683 no problem Manfred ___ 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote: >> [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. >> lib/libc/string/memcmp_test:diff is one of them.] > >> ===> Broken tests >> lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case >> received signal 6 (core dumped) [3.962s] > > The problem here is that our definition of memcmp() is tighter than the > one in the standards and glibc. We define the return value to be the > difference between the first differing bytes, while the standards and > glibc only define the sign (negative, zero or positive). > > Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a > bic pos, pos, #7 after the clz may help. > > On another note, the comment just below that, > >/* But we need to zero-extend (char is unsigned) the value and then > perform a signed 32-bit subtraction. */ > > shows a wrong reason for doing the right thing since memcmp (as well as > strcmp and strncmp) are defined to compare based on unsigned chars, > regardless of the signedness of char. Ahh, standard are so much fun: there are so many to choose from. I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function". It makes no such explicit claim about using using unsigned chars for the comparison standard: QUOTE of the Description part: The memcmp function compares the first n characters of the object pointed by s1 to the first n characters of the object pointed by s2. END QUOTE QUOTE of the Returns part: The memcmp function returns an integer greater than, equal to, or less than zero, accordingly as the object pointed to by s1 is greater than, equal to, or less than the object pointed to by s2. END QUOTE If I had to guess the intent of "characters" would be based on the char type for C11. I did not find anything about the issue in the C99 rationale that I also happen to have available to look at. For all I know, POSIX or other standards may be more explicit and not agree. === 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote: > [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. > lib/libc/string/memcmp_test:diff is one of them.] > ===> Broken tests > lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case > received signal 6 (core dumped) [3.962s] The problem here is that our definition of memcmp() is tighter than the one in the standards and glibc. We define the return value to be the difference between the first differing bytes, while the standards and glibc only define the sign (negative, zero or positive). Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a bic pos, pos, #7 after the clz may help. On another note, the comment just below that, /* But we need to zero-extend (char is unsigned) the value and then perform a signed 32-bit subtraction. */ shows a wrong reason for doing the right thing since memcmp (as well as strcmp and strncmp) are defined to compare based on unsigned chars, regardless of the signedness of char. -- Jilles Tjoelker ___ 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On 2018-Sep-16, at 2:25 AM, Piotr P. Stefaniak wrote: > On 2018-09-11 02:44:49, Mark Millard wrote: >> usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see the >> output of the test for details [0.151s] >> usr.bin/indent/functional_test:sac -> failed: atf-check failed; see the >> output of the test for details [0.150s] > > Those were predictable since r334944 and before r336601, so I don't know > how it happens that you're getting them with r338518. > Hmm: # ls -lTdt /usr/tests/usr.bin/indent/* -r--r--r-- 1 root wheel 121 Sep 13 22:53:30 2018 /usr/tests/usr.bin/indent/Kyuafile . . . -r--r--r-- 1 root wheel 295 Sep 13 22:53:29 2018 /usr/tests/usr.bin/indent/binary.0 -r--r--r-- 1 root wheel92 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/sac.0.pro -r--r--r-- 1 root wheel 130 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/sac.0.stdout -r--r--r-- 1 root wheel 122 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/sac.0 -r--r--r-- 1 root wheel94 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/nsac.0.pro -r--r--r-- 1 root wheel 130 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/nsac.0.stdout -r--r--r-- 1 root wheel 123 May 1 19:35:24 2018 /usr/tests/usr.bin/indent/nsac.0 vs. ( note: usr.bin vs usr/bin ): Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Sun Jul 22 12:04:21 2018(r336600) +++ head/ObsoleteFiles.inc Sun Jul 22 12:45:02 2018(r336601) @@ -38,6 +38,13 @@ # xargs -n1 | sort | uniq -d; # done +# 20180722: indent(1) option renamed, test files follow +OLD_FILES+=usr/bin/indent/tests/nsac.0 +OLD_FILES+=usr/bin/indent/tests/nsac.0.pro +OLD_FILES+=usr/bin/indent/tests/nsac.0.stdout +OLD_FILES+=usr/bin/indent/tests/sac.0 +OLD_FILES+=usr/bin/indent/tests/sac.0.pro +OLD_FILES+=usr/bin/indent/tests/sac.0.stdout # 20180721: move of libmlx5.so.1 and libibverbs.so.1 OLD_LIBS+=usr/lib/libmlx5.so.1 OLD_LIBS+=usr/lib/libibverbs.so.1 === 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: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context
On 2018-09-11 02:44:49, Mark Millard wrote: usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see the output of the test for details [0.151s] usr.bin/indent/functional_test:sac -> failed: atf-check failed; see the output of the test for details [0.150s] Those were predictable since r334944 and before r336601, so I don't know how it happens that you're getting them with r338518. ___ 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"
