r344398 Import ACPICA 20190215: breaks bhyve
Hi, most likely r344398[1] commit breaks bhyve with the following errors: Subtable Type : 02 Error6302 - Flag value is too large ^ (Maximum 1 bit) 58: [0002] Flags (decoded below) : 0005 Error6302 - Flag value is too large ^ (Maximum 2 bit) 66: [0004] Interrupt : 0009 Error6302 - Flag value is too large ^ (Maximum 2 bit) Assertion failed: (error == 0), function main, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 1190. Can anyone else confirm this? Howto reproduce: fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -i -I FreeBSD-10.3-RELEASE-amd64-bootonly.iso guestname __ [1] - https://svnweb.freebsd.org/base?view=revision&revision=r344398 ___ 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: r344398 Import ACPICA 20190215: breaks bhyve
Oops, to the list this time.
Hi Oleg,
Those look like the ACPI lines bhyve attempts to generate and compile
in basl_fwrite_madt():
272 /* Legacy IRQ0 is connected to pin 2 of the IOAPIC */
273 EFPRINTF(fp, "[0001]\t\tSubtable Type : 02\n");
274 EFPRINTF(fp, "[0001]\t\tLength : 0A\n");
275 EFPRINTF(fp, "[0001]\t\tBus : 00\n");
276 EFPRINTF(fp, "[0001]\t\tSource : 00\n");
277 EFPRINTF(fp, "[0004]\t\tInterrupt : 0002\n");
278 EFPRINTF(fp, "[0002]\t\tFlags (decoded below) : 0005\n");
^^^ this line ("maximum 1 bit")
279 EFPRINTF(fp, "\t\t\tPolarity : 1\n");
280 EFPRINTF(fp, "\t\t\tTrigger Mode : 1\n");
281 EFPRINTF(fp, "\n");
282
283 EFPRINTF(fp, "[0001]\t\tSubtable Type : 02\n");
284 EFPRINTF(fp, "[0001]\t\tLength : 0A\n");
285 EFPRINTF(fp, "[0001]\t\tBus : 00\n");
286 EFPRINTF(fp, "[0001]\t\tSource : %02X\n", SCI_INT);
287 EFPRINTF(fp, "[0004]\t\tInterrupt : %08X\n", SCI_INT);
^^^ this line ("maximum 2 bit"; SCI_INT==9)
288 EFPRINTF(fp, "[0002]\t\tFlags (decoded below) : \n");
289 EFPRINTF(fp, "\t\t\tPolarity : 3\n");
290 EFPRINTF(fp, "\t\t\tTrigger Mode : 3\n");
291 EFPRINTF(fp, "\n");
Would you mind filing a PR to track this investigation?
The error message and constraint on Value being in range of BitLength
was added to DtCompileFlag() in compiler/dtfield.c way back in r208625
(ACPICA 20100528) — it's not new. What must be new is the idea that
these fields have a smaller bit width that the numbers bhyve has
chosen, or bhyve's choice of numbers.
We can eliminate bhyve as a suspect, maybe? acpi.c hasn't changed
substantially for years. In fact, there is a seemingly related commit
r272838 which converted some fields to hexadecimal in order to comply
with length limitations. The first of these two tables was introduced
in r257933 by tycho@ / neel@. The second was changed from a bare
constant by jhb@ in r259998, but previously held the value 9. It
dates to the original 2012 "ACPI support for bhyve" commit by grehan@
in r243327.
So yeah, probably something changed recently in ACPICA.
Best,
Conrad
On Thu, Feb 21, 2019 at 8:38 AM Oleg Ginzburg wrote:
>
> Hi,
>
> most likely r344398[1] commit breaks bhyve with the following errors:
>
> Subtable Type : 02
> Error6302 - Flag value is too large ^ (Maximum 1 bit)
> 58: [0002] Flags (decoded below) : 0005
> Error6302 - Flag value is too large ^ (Maximum 2 bit)
> 66: [0004] Interrupt : 0009
> Error6302 - Flag value is too large ^ (Maximum 2 bit)
> Assertion failed: (error == 0), function main, file
> /usr/src/usr.sbin/bhyve/bhyverun.c, line 1190.
>
> Can anyone else confirm this?
>
> Howto reproduce:
>
> fetch
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso
>
> sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -i -I
> FreeBSD-10.3-RELEASE-amd64-bootonly.iso guestname
>
>
> __
> [1] - https://svnweb.freebsd.org/base?view=revision&revision=r344398
> ___
> 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"
Re: r344398 Import ACPICA 20190215: breaks bhyve
On Thu, Feb 21, 2019 at 8:15 PM Conrad Meyer wrote: > Would you mind filing a PR to track this investigation? Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235922 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"
FreeBSD CI Weekly Report 2019-02-17
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-02-17 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-02-11 to 2019-02-17. During this period, we have: * 2348 builds (93.4% passed, 6.6% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 553 test runs (23.7% passed, 73.6% unstable, 2.7% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 12 doc buils (100% passed) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. Web version of this report is available at https://hackmd.io/s/By8HaYcSV and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big These two began failing since r343964 and do not show up after r344128. ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 See https://bugs.freebsd.org/235200 and https://bugs.freebsd.org/234809 for deails. WIP: https://bugs.freebsd.org/234809 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 see https://bugs.freebsd.org/235200 and https://bugs.freebsd.org/234809 for deails. WIP: https://bugs.freebsd.org/234809 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sbin.bectl.bectl_test.bectl_mount * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues ### Cause build fails * [29: genassym.o build race](https://bugs.freebsd.org/29) * Patch available: https://people.freebsd.org/~bdrewery/patches/PR29.diff * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ## Other News * QEMU has onboarded FreeBSD CI: https://cirrus-ci.com/github/qemu/qemu * New clang800-import project jobs added: * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-aarch64-build/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-amd64-build/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-amd64-test/ * https://ci.freebsd.org/job/FreeBSD-srcproj-clang800-import-i386-build/ * The artifacts are available at https://artifact.ci.freebsd.org/snapshot/clang800-import/ for further testing needs. * Jobs for testing if drm pkgs (graphics/drm-*) can be built fine on latest -current and -stable, are being tested in staging env. ___ 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"
kernel build failed
hello, I am new to running FreeBSD current. My kernel build failed with this message: https://pastebin.com/raw/Cpg7nAiX My kernel config: https://pastebin.com/raw/3nnKdKtS also another question, I have options ZFS because I use ZFS. but my ZFS worked before. so is that line not needed? thanks for your help ___ 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"
r343567 aka PAE vs non-PAE merge breaks i386 freebsd
r343567 merges the PAE vs non-PAE pmap headers for i386 freebsd. After bisection and dealing with the drm-legacy-kmod fallout, I bisected /usr/src to r343567. Building world and a GENERIC kernel and the minimum set of ports to start Xorg on my Dell Latitude D530 laptop, results in a black screen of death and a locked up laptop (no keyboard, mouse, or video). A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads and functions) and r353467 (Xorg black screen of death) shows that /boot/modules/i915kms.ko loads correctly as the log files are identical. Comparing dmesg for r343566 to r343567 shows the following --- dmesg.3435662019-02-20 08:13:07.727202000 -0800 +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800 @@ -3,11 +3,11 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 13.0-CURRENT r343566 GENERIC i386 +FreeBSD 13.0-CURRENT r343567 GENERIC i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd @@ -16,7 +16,7 @@ VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) -avail memory = 3639914496 (3471 MB) +avail memory = 4154175488 (3961 MB) Somehow the r343567 kernel found an addition 490 MB of memory, which leads me to believe the after loading i915kms.ko there is some serious memory stomping issues. I willing to do whatever is necessary to fix this issue (shorter of mailing the laptop to someone). Is it possible to revert r343567 and move forward? -- Steve ___ 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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > r343567 merges the PAE vs non-PAE pmap headers for i386 > freebsd. After bisection and dealing with the drm-legacy-kmod > fallout, I bisected /usr/src to r343567. Building world and > a GENERIC kernel and the minimum set of ports to start Xorg > on my Dell Latitude D530 laptop, results in a black screen > of death and a locked up laptop (no keyboard, mouse, or video). > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > and functions) and r353467 (Xorg black screen of death) shows > that /boot/modules/i915kms.ko loads correctly as the log > files are identical. > > Comparing dmesg for r343566 to r343567 shows the following > > --- dmesg.343566 2019-02-20 08:13:07.727202000 -0800 > +++ dmesg.343567 2019-02-21 19:02:24.469562000 -0800 > @@ -3,11 +3,11 @@ > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class > CPU) > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > Features=0xbfebfbff >Features2=0xe3bd > @@ -16,7 +16,7 @@ >VT-x: (disabled in BIOS) HLT,PAUSE >TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > -avail memory = 3639914496 (3471 MB) > +avail memory = 4154175488 (3961 MB) > > Somehow the r343567 kernel found an addition 490 MB of memory, > which leads me to believe the after loading i915kms.ko there > is some serious memory stomping issues. > > I willing to do whatever is necessary to fix this issue (shorter > of mailing the laptop to someone). Is it possible to revert > r343567 and move forward? > More info from sysctl. With the "good" r343566, I see vm.kmem_map_free: 1187033088 vm.kmem_map_size: 27234304 vm.kmem_size_scale: 3 vm.kmem_size_max: 1715470336 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1214267392 hw.physmem: 3714269184 hw.usermem: 3650867200 hw.realmem: 4294963200 With the problematic r343567, I see vm.kmem_map_free: 1683152896 vm.kmem_map_size: 28123136 vm.kmem_size_scale: 1 vm.kmem_size_max: 1711276032 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1711276032 hw.physmem: 4252360704 hw.usermem: 4146999296 hw.realmem: 4294963200 Ideas? -- Steve ___ 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"
