Re: building LLVM threads gets killed
[In part a resend from the right Email account.
In part adding a note about another Mark Johnston
patch for reporting information.]
On 2018-Aug-19, at 11:25 PM, Mark Millard wrote:
> blubee blubeeme gurenchan at gmail.com wrote on
> Mon Aug 20 03:02:01 UTC 2018 :
>
>> I am running current compiling LLVM60 and when it comes to linking
>> basically all the processes on my computer gets killed; Chrome, Firefox and
>> some of the LLVM threads as well
>
>> . . .
>
>> last pid: 20965; load averages: 0.64, 5.79, 7.73
>> up 12+01:35:46 11:00:36
>> 76 processes: 1 running, 75 sleeping
>> CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% idle
>> Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free
>> ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other
>> 630M Compressed, 2G Uncompressed, 2.74:1 Ratio
>> Swap: 2G Total, 1G Used, 739M Free, 63% Inuse
>> . . .
>
> The timing of that top output relative to the first or
> any OOM kill of a process is not clear. After? Just
> before? How long before? What it is like leading up
> to the first kill is of interest.
>
> Folks that deal with this are likely to want do know
> if you got console messages ( or var/log/messages content)
> such as:
>
> pid 49735 (c++), uid 0, was killed: out of swap space
>
> (Note: "out of swap space" can be a misnomer for having
> low Free RAM for "too long" [vm.pageout_oom_seq based],
> even with swap unused or little used.)
>
> And: Were you also getting messages like:
>
> swap_pager_getswapspace(4): failed
>
> and/or:
>
> swap_pager: out of swap space
>
> (These indicate the "killed: out of swap space" is not
> necessarily a misnomer relative to swap space, even if
> low free RAM over a time drives the process kills.)
>
> How about messages like:
>
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536
>
> or any I/O error reports or retry reports?
>
>
>
> Notes:
>
> Mark Johnston published a patch used for some investigations of
> the OOM killing:
>
> https://people.freebsd.org/~markj/patches/slow_swap.diff
>
> But this is tied to the I/O swap latencies involved and if they
> are driving some time frames. It just adds more reporting to
> the console ( and /var/log/messages ). It is not a fix. IT may
> not be likely to report much for your context.
>
>
> vm.pageout_oom_seq controls the "how long is low free RAM
> tolerated" (my hprasing), though the units are not directly
> time. In various arm contexts with small boards going from
> the default of 12 to 120 allowed things to complete or get
> much farther. So:
>
> sysctl vm.pageout_oom_seq=120
>
> but 120 is not the limit: it is a C int parameter.
>
> I'll note that "low free RAM" is as FreeBSD classifies it,
> whatever the details are.
>
>
>
> Most of the arm examples have been small memory contexts
> and many of them likely avoid ZFS and use UFS instead.
> ZFS and its ARC and such an additional complicated
> context to the type of issue. There are lots of reports
> around of the ARC growing too big. I do not know the
> status of -r336196 relative to ZFS/ARC memory management
> or if more recent versions have improvements. (I do not
> use ZFS normally.) I've seen messages making suggestions
> for controlling the growth but I'm no ZFS expert.
>
>
> Just to give an idea what is sufficient to build
> devel/llvm60:
>
> I will note that on a Pine64+ 2GB (so 2 GiBytes of RAM
> in a aarch64 context with 4 cores, 1 HW-thread per core)
> running -r337400, and using UFS on a USB drive and a
> swap partition that drive too, I have built devel/llvm60
> 2 times via poudriere-devel: just one builder
> allowed but it being allowed to use all 4 cores in
> parallel, about 14.5 hr each time. (Different USB media
> each time.) This did require the:
>
> sysctl vm.pageout_oom_seq=120
>
> Mark Johnston's slow_swap.diff patch code did not
> report any I/O latency problems in the swap subsystem.
>
> I've also built lang/gcc8 2 times, about 12.5 hrs
> each time.
>
> No ZFS, no ARC, no Chrome, no FireFox. Nothing else
> major going on beyond the devel/llvm60 build (or, later,
> the lang/gcc8 build) in each case.
Mark Johnston in the investigation for the arm context
also had us use the following patch:
diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 264c98203c51..9c7ebcf451ec 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int
page_shortage,
* start OOM. Initiate the selection and signaling of the
* victim.
*/
+ printf("v_free_count: %u, v_inactive_count: %u\n",
+ vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
vm_pageout_oom(VM_OOM_MEM);
/*
This patch is not about the I/O latencies but about the
free RAM and inactive RAM at exactly the point of the
OOM kill activity.
===
Mark Millard
marklmi at yahoo
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On Sat, Aug 18, 2018 at 04:36:15PM -0700, Cy Schubert wrote: > You can use NFS or rsync. Make sure the src and obj path names are > exactly the same on all thes servers. I used to use NFS until a year or > two ago when I started using different patches on different machines. > On occasion I've used rsync followed by a NO_CLEAN, WORLDFAST, KERNFAST > build on the target machine or simply installkernel and installworld. > I had a quick try of this, with rsync. installkernel worked properly and I can boot, howver installworld fails with lot of $PROGRAM not found erroer for env, mktemp etc. Thanks for all the suggestions I will grok at the installworld a bit more, and will also give PkgBase a try. - Dhananjay Balan ___ 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: Sharing compiled builds between multiple 12-CURRENT boxes.
On 19/8/18 5:31 pm, Matthew Seaman wrote: > On 19/08/2018 01:55, Shane Ambler wrote: >>> I run 12-CURRENT on few machines, some more powerful that other (all >>> of them x86_64, march varies). > >> You can use freebsd-update by setting up your own update server >> https://www.freebsd.org/doc/en/articles/freebsd-update-server > > freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP > specified. While I haven't used it to make releases from current, I would be surprised if it doesn't work for current. The default config for release.sh is to checkout and build HEAD, so without setup, current would be used when building for the update server. I do expect an incremental numbering scheme would need to be used to differentiate each build, patch level builds should fit that. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ 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"
building LLVM threads gets killed
I am running current compiling LLVM60 and when it comes to linking basically all the processes on my computer gets killed; Chrome, Firefox and some of the LLVM threads as well I am using ninja which is a little better but gmake or make are a lot worse. uname -a: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336196: Wed Jul 11 21:52:50 CST 2018 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 me@blubee:~ % uname -K 1200072 me@blubee:~ % uname -U 1200072 building with -j1 still crashes and burns. Basically everything on my machine gets killed. This machine has sysctl hw.physmem hw.physmem: 34246332416 last pid: 20965; load averages: 0.64, 5.79, 7.73 up 12+01:35:46 11:00:36 76 processes: 1 running, 75 sleeping CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% idle Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other 630M Compressed, 2G Uncompressed, 2.74:1 Ratio Swap: 2G Total, 1G Used, 739M Free, 63% Inuse llvm/build % ninja -j8 [2408/2473] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes -Iinclude -I../include -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g-fno-exceptions -fno-rtti -MD -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c ../lib/Passes/PassBuilder.cpp c++: error: unable to execute command: Killed c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.cpp c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.sh c++: note: diagnostic msg: --- llvm/build % ninja -j8 [54/59] Linking CXX executable bin/opt FAILED: bin/opt : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,--export-dynamic -Wl,-z,origin tools/opt/CMakeFiles/opt.dir/AnalysisWrappers.cpp.o tools/opt/CMakeFiles/opt.dir/BreakpointPrinter.cpp.o tools/opt/CMakeFiles/opt.dir/Debugify.cpp.o tools/opt/CMakeFiles/opt.dir/GraphPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/NewPMDriver.cpp.o tools/opt/CMakeFiles/opt.dir/PassPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/PrintSCC.cpp.o tools/opt/CMakeFiles/opt.dir/opt.cpp.o -o bin/opt -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a
What's this gregset_t gregs thing
Linux has gregset_t gregs; https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h Defined above, I also see it in the RISC-V glibc stuff as well. FreeBSD doesn't seem to have this field defined, I see FreeBSD uses /usr/include/x86/ucontext.h but there's no gregs; If I wanted to return mcontext.gregs How could I implement that on FreeBSD? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic excl->shared for an AF_LOCAL socket
On Sun, Aug 19, 2018 at 4:32 PM Rick Macklem wrote: > Hi, > > PR#230752 shows a witness panic() for "excl->shared" on a vnode lock. > In this case, the kernel RPC code is trying to do a soconnect() on an > AF_LOCAL > socket. The code is unp_connectat() looks like is does a straightforward > namei()/lookup(), so I am surprised to see this. > > Does anyone know if AF_LOCAL (unix domain) sockets are somehow handled > differently for namei()/lookup() which might cause this? > > I've requested more info from the reporter w.r.t. when this happens. > (I'd guess when the nfsuserd is terminating or has terminated or ???) > > Thanks for any help with this, rick > I don't know what's special in this case, but I did revamp the locking there several months back so I'll take a look next weekend. -M ___ 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"
panic excl->shared for an AF_LOCAL socket
Hi, PR#230752 shows a witness panic() for "excl->shared" on a vnode lock. In this case, the kernel RPC code is trying to do a soconnect() on an AF_LOCAL socket. The code is unp_connectat() looks like is does a straightforward namei()/lookup(), so I am surprised to see this. Does anyone know if AF_LOCAL (unix domain) sockets are somehow handled differently for namei()/lookup() which might cause this? I've requested more info from the reporter w.r.t. when this happens. (I'd guess when the nfsuserd is terminating or has terminated or ???) Thanks for any help with this, rick ___ 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Sun, 19 Aug 2018 19:16:42 +0300 Konstantin Belousov wrote: > On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote: > > > > > > On Fri, 17 Aug 2018 10:02:08 +0100 > > John Baldwin wrote: > > > > > On 8/17/18 9:54 AM, Michael Gmelin wrote: > > > > > > > > > > > >> On 17. Aug 2018, at 08:17, John Baldwin > > > >> wrote: > > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > > > >>> > > > >>> > > > On 15. Aug 2018, at 15:55, Konstantin Belousov > > > mailto:kostik...@gmail.com>> wrote: > > > > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin > > > > wrote: > > > > > > > > > > > >>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > > >>> mailto:kostik...@gmail.com>> wrote: > > > >>> > > > >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > > > >>> wrote: Reviving this old thread, since I just updated to > > > >>> r337818 and a similar problem is happening again. Since > > > >>> the fix in r334799 (review > > > >>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have > > > >>> been touched, so maybe this is related > > > >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). > > > >>> > > > >>> Please see the screenshot of the panic below: > > > >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > > > >>> > > > >>> This is me not digging any deeper, hoping that this is > > > >>> something obvious. Please let me know if you need more > > > >>> input. > > > >> > > > >> I do not see how recent mp_machdep.c changes could affect > > > >> this. Can you try newest kernel but old loader ? > > > > > > > > I will try (but that will take a while). Oh, also, it still > > > > boots in save mode/with smp disabled. > > > > > > Right, this is because the access to that address through > > > DMAP is only needed when configuring AP startup resources. > > > > > > Also, I think it is safe to suggest that the bisect is > > > needed. > > > >>> > > > >>> Using an older loader didn???t help, but I identified the > > > >>> problem: > > > >>> > > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 > > > >>> > > > >>> modified the code you introduced in > > > >>> > > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 > > > >>> > > > >>> By correcting units to pages it also broke booting the > > > >>> Chromebook as a side effect - so the previous fix just worked > > > >>> due to a bug it seems. > > > >>> > > > >>> Is there an easy way to output the content of physmap at that > > > >>> point (debug.late_console=0 doesn???t work) - like an existing > > > >>> buffer I could use, or would this be more elaborate (I did > > > >>> something complicated last time but didn???t save it, so any > > > >>> simple solution would be preferred). > > > >> > > > >> How about reverting the commit for now so you get a working > > > >> console and print out the physmap array values along with > > > >> Maxmem later in the boot (or just use kgdb to examine them > > > >> once the system is running)? > > > > > > > > This is before the system has a working console (part of calling > > > > getmem...), disabling late console makes it hang, physmap > > > > changes afterwards, so running kgdb later doesn???t help. Last > > > > time I kept a copy of physmap and logged it later to know the > > > > original content. I can do that again, I just thought maybe > > > > there is a simple mechanism I???m not aware of that would save > > > > me some time. > > > > > > I thought we only modified phys_avail[], but saving a copy of > > > physmap[] and dumping it from kgdb is probably the simplest thing > > > to do. > > > > > > > Okay, so I had some time to investigate a bit more: > > > > Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), > > physmap looks like this: > > > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x3 0x30 > > 2 0x4 0x40 > > 3 0x9e400 0x9e > > 4 0x10 0x100 > > 5 0xf0 0xf00 > > 6 0x100 0x1000 > > 7 0x7bf7a000 0x7bf7a > > 8 0x1 0x10 > > 9 0x10060 0x100600 > > 10 0x0 0x0 > > Maxmem: 0x10060 0x100600 > > > > Without using atop (the "buggy" version that actually boots without > > crashing), the loop in mp_bootaddress looks like this: > > > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > > 8 0x1 0x10060 0x100600 0x100600 > > 6 0x100 0x7bf7a000 0x7bf7a 0x100600 > > 4 0x10 0xf0 0xf00 0x100600 > > 2 0x4 0x9e400 0x9e 0x100600 > > > > And physmap looks like this afterwards: > > > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x3 0x30 > > 2 0x43000 0x43 <-- here > > 3 0x9e400 0x9e > > 4 0x10 0x100 > > 5 0xf0 0xf00 > > 6 0x100 0x1000 > > 7 0x7bf7a000 0x7bf7a > > 8 0x1 0x10 > > 9 0x10060 0x100600 > > 10 0x0 0x0 > > mptra
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:10 AM, Warner Losh wrote:
>
> I think including both loaders in userboot is probably a no-start
>> based on the current interface.
>>
>
> Yea, it would be a challenge... Sadly, we have POLA violations either way
> we jump here.
>
Just to summarize the IRC conversation:
I just committed r338064 which reverts userboot.so to 4th always. This is a
quick band-aide until a longer term solution happens.
There was the suggestion of adding a hack so that if there was no lua, we
could use the 4th interpreter instead. There's a number of ways to do this,
but they all involve a bit of work.
There was the suggestion of installing a userboot_{lua,4th}.so and hard
linking (but this provides a built-in way to get the right userboot_*.so to
use with a bhyveload -l lessening the burden).
The notion of putting some smarts into bhyveload to cope, since it's also
updated at the same time that userboot.so is, typically.
There may be another notion as well. Working through the details and will
present a plan when I have it.
Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: non UEFI boxes have weird ssh output
On Sun, Aug 19, 2018 at 12:33 PM, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Just updated some boxes to 12-CURRENT r338057 and I face a very strange > behaviour: > > on non-UEFI booting boxes (older Fujitsu and Dell servers from 2008/2009, > PCengine APU > 2C4), logging in via ssh reveals broken output: even top does show nothing, > the box is > stuck. Calling vi(1) on some files does alos freeze the terminal - no > response, nothing. > On the PCengine, also applications like Asterisk do not work anymore - not > output on the > console. The program is running, but stopped servicing. Only the serial > console to some > of the "ssd-brain-dead" systems work, sshd is dead. This isn't the case on > UEFI boxes > with the very same revision (r338057). > > Is this a coincidence or is this/could this related to the switch to LUA > loader? > This is probably a coincidence. Most of the important stuff that happens in loader is independent of the interpreter that's built into it, the exceptions being that the interpreter is tasked with reading loader.conf(5) and sets up some ACPI stuff on x86 BIOS boots. ___ 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"
LUA loader: non UEFI boxes have weird ssh output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Just updated some boxes to 12-CURRENT r338057 and I face a very strange behaviour: on non-UEFI booting boxes (older Fujitsu and Dell servers from 2008/2009, PCengine APU 2C4), logging in via ssh reveals broken output: even top does show nothing, the box is stuck. Calling vi(1) on some files does alos freeze the terminal - no response, nothing. On the PCengine, also applications like Asterisk do not work anymore - not output on the console. The program is running, but stopped servicing. Only the serial console to some of the "ssd-brain-dead" systems work, sshd is dead. This isn't the case on UEFI boxes with the very same revision (r338057). Is this a coincidence or is this/could this related to the switch to LUA loader? - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3mp7gAKCRDS528fyFhY lDJaAf9G8h7uEgHkAdWJNjb+QSUpNu1TqF4gqvJ01mVh0eQqtYe8+YTPA5I/8LMb x7S7HXvRxBSwiL6YB2tNEBgzWTryAgCQ7FzpE1x+gKImVUq+8BYvgCTJEnAYqYlC 79Ib2MRzRU6qxyCi8qiCxoPI/7hCYoO5lbjaVms7ylpJGtMj+wSI =YIBD -END PGP SIGNATURE- ___ 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: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:03 AM, Kyle Evans wrote: > On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote: > > On 8/19/18 5:28 PM, Kyle Evans wrote: > >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman > wrote: > >>> > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman > wrote: > > > >> With today's change to LUA as the loader, I seem to have an issue > with > >> bhyhve: > >> > >> Consoles: userboot > >> > >> FreeBSD/amd64 User boot, Revision 1.1 > >> (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > >> Startup error in /boot/lua/loader.lua: > >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or > directory. > >> > >> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > >> syms=[0x8+0x14cf28+0x8+0x163e57] > >> Hit [Enter] to boot immediately, or any other key for command > prompt. > >> Booting [/boot/kernel/kernel]... > >> > >> These VM's have been running for MONTHS. > >> > >> Ideas? > >> > > > > There's no boot/lua/loader.lua. > > > > You can either fix that, or you can recompile with > > LOADER_DEFAULT_INTERP=4th for the moment. > actually on the host there is: > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > total 131 > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > borg.lerctr.org /home/ler $ > > This is when booting the vm, and it's not on the vm's disk. > > So the bhyveload behavior *CHANGED*. > > POLA? > > >>> > >>> Unlikely, but a couple of questions. Have you always used the LUA > loader, > >>> or is this a change with the recent default switch? > >>> > >>> And to be clear, you expect the host's file to be used for this, not > the VM > >>> filesystem? > >>> > >> > >> (CC'ing jhb@ and tychon@, who might have better insight) > >> > >> If we can swing it, I think the best model here should have always > >> been that userboot uses the host's scripts but the guest's > >> loader.conf. The current model doesn't tolerate any mismatch between > >> host and guest and looks unsustainable. > > > > Err, normally guests read things out of the a guest disk image (think > most > > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk > image. > > Now, userboot isn't memory limited like the BIOS boot, so if it's > > possible to have userboot just include both lua and forth perhaps with > > some auto-detection based on what is in /boot/loader.rc to determine > > which interpreter to use, that is really the best path forward. > > > > Right, but userboot is clearly a special monkey... it seems that it > would have made a lot more sense to emulate an actual BIOS boot (or > something) and boot a real boot1/loader from a guest, but instead we > end up with this host dependency of userboot that's invoking scripts > from the guest -- which may or may not match. > It's special so that bhyve doesn't have to emulate more > I think including both loaders in userboot is probably a no-start > based on the current interface. > Yea, it would be a challenge... Sadly, we have POLA violations either way we jump here. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:04 AM, Larry Rosenman wrote: > so it still looks forth'ish, but it's using lua. > It will always look forthish becuase it's unused in loader_lua. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 10:58 AM, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: > > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman > wrote: > >> > >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman > wrote: > > > With today's change to LUA as the loader, I seem to have an issue > with > > bhyhve: > > > > Consoles: userboot > > > > FreeBSD/amd64 User boot, Revision 1.1 > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > Startup error in /boot/lua/loader.lua: > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or > directory. > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > syms=[0x8+0x14cf28+0x8+0x163e57] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > > > These VM's have been running for MONTHS. > > > > Ideas? > > > > There's no boot/lua/loader.lua. > > You can either fix that, or you can recompile with > LOADER_DEFAULT_INTERP=4th for the moment. > >>> actually on the host there is: > >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ > >>> total 131 > >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > >>> borg.lerctr.org /home/ler $ > >>> > >>> This is when booting the vm, and it's not on the vm's disk. > >>> > >>> So the bhyveload behavior *CHANGED*. > >>> > >>> POLA? > >>> > >> > >> Unlikely, but a couple of questions. Have you always used the LUA > loader, > >> or is this a change with the recent default switch? > >> > >> And to be clear, you expect the host's file to be used for this, not > the VM > >> filesystem? > >> > > > > (CC'ing jhb@ and tychon@, who might have better insight) > > > > If we can swing it, I think the best model here should have always > > been that userboot uses the host's scripts but the guest's > > loader.conf. The current model doesn't tolerate any mismatch between > > host and guest and looks unsustainable. > > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk > image. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. > You can't have both interpreters in the same image. You can't easily determine what the language to use for the interpreter. You can only determine if lua is present or not. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 05:58:43PM +0100, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: > > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > >> > >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > With today's change to LUA as the loader, I seem to have an issue with > > bhyhve: > > > > Consoles: userboot > > > > FreeBSD/amd64 User boot, Revision 1.1 > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > Startup error in /boot/lua/loader.lua: > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > syms=[0x8+0x14cf28+0x8+0x163e57] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > > > These VM's have been running for MONTHS. > > > > Ideas? > > > > There's no boot/lua/loader.lua. > > You can either fix that, or you can recompile with > LOADER_DEFAULT_INTERP=4th for the moment. > >>> actually on the host there is: > >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ > >>> total 131 > >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > >>> borg.lerctr.org /home/ler $ > >>> > >>> This is when booting the vm, and it's not on the vm's disk. > >>> > >>> So the bhyveload behavior *CHANGED*. > >>> > >>> POLA? > >>> > >> > >> Unlikely, but a couple of questions. Have you always used the LUA loader, > >> or is this a change with the recent default switch? > >> > >> And to be clear, you expect the host's file to be used for this, not the VM > >> filesystem? > >> > > > > (CC'ing jhb@ and tychon@, who might have better insight) > > > > If we can swing it, I think the best model here should have always > > been that userboot uses the host's scripts but the guest's > > loader.conf. The current model doesn't tolerate any mismatch between > > host and guest and looks unsustainable. > > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk image. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. That won't help (looking at /boot/loader.rc) as my lua updated system still has: borg.lerctr.org /home/ler $ more /boot/loader.rc \ Loader.rc \ $FreeBSD: head/stand/i386/loader/loader.rc 331326 2018-03-21 22:01:51Z kevans $ \ \ Includes additional commands include /boot/loader.4th include /boot/efi.4th try-include /boot/loader.rc.local \ Reads and processes loader.conf variables initialize maybe-efi-resizecons \ Tests for password -- executes autoboot first if a password was defined check-password \ Load in the boot menu include /boot/beastie.4th \ Start the boot menu beastie-start borg.lerctr.org /home/ler $ so it still looks forth'ish, but it's using lua. > > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > >> With today's change to LUA as the loader, I seem to have an issue with >> bhyhve: >> >> Consoles: userboot >> >> FreeBSD/amd64 User boot, Revision 1.1 >> (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >> >> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 >> syms=[0x8+0x14cf28+0x8+0x163e57] >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> >> These VM's have been running for MONTHS. >> >> Ideas? >> > > There's no boot/lua/loader.lua. > > You can either fix that, or you can recompile with > LOADER_DEFAULT_INTERP=4th for the moment. actually on the host there is: borg.lerctr.org /home/ler $ ls -l /boot/lua/ total 131 -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua borg.lerctr.org /home/ler $ This is when booting the vm, and it's not on the vm's disk. So the bhyveload behavior *CHANGED*. POLA? >>> >>> Unlikely, but a couple of questions. Have you always used the LUA loader, >>> or is this a change with the recent default switch? >>> >>> And to be clear, you expect the host's file to be used for this, not the VM >>> filesystem? >>> >> >> (CC'ing jhb@ and tychon@, who might have better insight) >> >> If we can swing it, I think the best model here should have always >> been that userboot uses the host's scripts but the guest's >> loader.conf. The current model doesn't tolerate any mismatch between >> host and guest and looks unsustainable. > > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk image. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. > Right, but userboot is clearly a special monkey... it seems that it would have made a lot more sense to emulate an actual BIOS boot (or something) and boot a real boot1/loader from a guest, but instead we end up with this host dependency of userboot that's invoking scripts from the guest -- which may or may not match. I think including both loaders in userboot is probably a no-start based on the current interface. ___ 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: LUA loader: bhyve now doesn't?
On 8/19/18 5:28 PM, Kyle Evans wrote: > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: >> >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > With today's change to LUA as the loader, I seem to have an issue with > bhyhve: > > Consoles: userboot > > FreeBSD/amd64 User boot, Revision 1.1 > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > Startup error in /boot/lua/loader.lua: > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > syms=[0x8+0x14cf28+0x8+0x163e57] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > > These VM's have been running for MONTHS. > > Ideas? > There's no boot/lua/loader.lua. You can either fix that, or you can recompile with LOADER_DEFAULT_INTERP=4th for the moment. >>> actually on the host there is: >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ >>> total 131 >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua >>> borg.lerctr.org /home/ler $ >>> >>> This is when booting the vm, and it's not on the vm's disk. >>> >>> So the bhyveload behavior *CHANGED*. >>> >>> POLA? >>> >> >> Unlikely, but a couple of questions. Have you always used the LUA loader, >> or is this a change with the recent default switch? >> >> And to be clear, you expect the host's file to be used for this, not the VM >> filesystem? >> > > (CC'ing jhb@ and tychon@, who might have better insight) > > If we can swing it, I think the best model here should have always > been that userboot uses the host's scripts but the guest's > loader.conf. The current model doesn't tolerate any mismatch between > host and guest and looks unsustainable. Err, normally guests read things out of the a guest disk image (think most VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk image. Now, userboot isn't memory limited like the BIOS boot, so if it's possible to have userboot just include both lua and forth perhaps with some auto-detection based on what is in /boot/loader.rc to determine which interpreter to use, that is really the best path forward. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:35 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote: >> > filesystem? >> > >> >> (CC'ing jhb@ and tychon@, who might have better insight) >> >> If we can swing it, I think the best model here should have always >> been that userboot uses the host's scripts but the guest's >> loader.conf. The current model doesn't tolerate any mismatch between >> host and guest and looks unsustainable. > > Yeah, I have a FreeBSD-10, and a HardendBSD-12 VM, and BOTH failed until > I loaded the old /boot/userboot.so to my host. > > We really need to tolerate this condition, and NOT surprise the user. Right. That's what we're trying to figure out here, the best route forward to make this stuff reliably work. ___ 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: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote: > > filesystem? > > > > (CC'ing jhb@ and tychon@, who might have better insight) > > If we can swing it, I think the best model here should have always > been that userboot uses the host's scripts but the guest's > loader.conf. The current model doesn't tolerate any mismatch between > host and guest and looks unsustainable. Yeah, I have a FreeBSD-10, and a HardendBSD-12 VM, and BOTH failed until I loaded the old /boot/userboot.so to my host. We really need to tolerate this condition, and NOT surprise the user. > > Thanks, > > Kyle Evans > ___ > 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" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > >> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: >> > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: >> > >> > > With today's change to LUA as the loader, I seem to have an issue with >> > > bhyhve: >> > > >> > > Consoles: userboot >> > > >> > > FreeBSD/amd64 User boot, Revision 1.1 >> > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) >> > > Startup error in /boot/lua/loader.lua: >> > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >> > > >> > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 >> > > syms=[0x8+0x14cf28+0x8+0x163e57] >> > > Hit [Enter] to boot immediately, or any other key for command prompt. >> > > Booting [/boot/kernel/kernel]... >> > > >> > > These VM's have been running for MONTHS. >> > > >> > > Ideas? >> > > >> > >> > There's no boot/lua/loader.lua. >> > >> > You can either fix that, or you can recompile with >> > LOADER_DEFAULT_INTERP=4th for the moment. >> actually on the host there is: >> borg.lerctr.org /home/ler $ ls -l /boot/lua/ >> total 131 >> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua >> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua >> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua >> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua >> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua >> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua >> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua >> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua >> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua >> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua >> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua >> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua >> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua >> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua >> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua >> borg.lerctr.org /home/ler $ >> >> This is when booting the vm, and it's not on the vm's disk. >> >> So the bhyveload behavior *CHANGED*. >> >> POLA? >> > > Unlikely, but a couple of questions. Have you always used the LUA loader, > or is this a change with the recent default switch? > > And to be clear, you expect the host's file to be used for this, not the VM > filesystem? > (CC'ing jhb@ and tychon@, who might have better insight) If we can swing it, I think the best model here should have always been that userboot uses the host's scripts but the guest's loader.conf. The current model doesn't tolerate any mismatch between host and guest and looks unsustainable. Thanks, Kyle Evans ___ 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote: > > > On Fri, 17 Aug 2018 10:02:08 +0100 > John Baldwin wrote: > > > On 8/17/18 9:54 AM, Michael Gmelin wrote: > > > > > > > > >> On 17. Aug 2018, at 08:17, John Baldwin wrote: > > >> > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > > >>> > > >>> > > On 15. Aug 2018, at 15:55, Konstantin Belousov > > mailto:kostik...@gmail.com>> wrote: > > > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: > > > > > > > > >>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > >>> mailto:kostik...@gmail.com>> wrote: > > >>> > > >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > > >>> wrote: Reviving this old thread, since I just updated to > > >>> r337818 and a similar problem is happening again. Since the > > >>> fix in r334799 (review https://reviews.freebsd.org/D15675) > > >>> (mp_)machdep.c have been touched, so maybe this is related > > >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). > > >>> > > >>> Please see the screenshot of the panic below: > > >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > > >>> > > >>> This is me not digging any deeper, hoping that this is > > >>> something obvious. Please let me know if you need more > > >>> input. > > >> > > >> I do not see how recent mp_machdep.c changes could affect this. > > >> Can you try newest kernel but old loader ? > > > > > > I will try (but that will take a while). Oh, also, it still > > > boots in save mode/with smp disabled. > > > > Right, this is because the access to that address through DMAP > > is only needed when configuring AP startup resources. > > > > Also, I think it is safe to suggest that the bisect is needed. > > >>> > > >>> Using an older loader didn???t help, but I identified the problem: > > >>> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 > > >>> > > >>> modified the code you introduced in > > >>> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 > > >>> > > >>> By correcting units to pages it also broke booting the Chromebook > > >>> as a side effect - so the previous fix just worked due to a bug > > >>> it seems. > > >>> > > >>> Is there an easy way to output the content of physmap at that > > >>> point (debug.late_console=0 doesn???t work) - like an existing > > >>> buffer I could use, or would this be more elaborate (I did > > >>> something complicated last time but didn???t save it, so any simple > > >>> solution would be preferred). > > >> > > >> How about reverting the commit for now so you get a working console > > >> and print out the physmap array values along with Maxmem later in > > >> the boot (or just use kgdb to examine them once the system is > > >> running)? > > > > > > This is before the system has a working console (part of calling > > > getmem...), disabling late console makes it hang, physmap changes > > > afterwards, so running kgdb later doesn???t help. Last time I kept a > > > copy of physmap and logged it later to know the original content. I > > > can do that again, I just thought maybe there is a simple mechanism > > > I???m not aware of that would save me some time. > > > > I thought we only modified phys_avail[], but saving a copy of > > physmap[] and dumping it from kgdb is probably the simplest thing to > > do. > > > > Okay, so I had some time to investigate a bit more: > > Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), > physmap looks like this: > > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x3 0x30 > 2 0x4 0x40 > 3 0x9e400 0x9e > 4 0x10 0x100 > 5 0xf0 0xf00 > 6 0x100 0x1000 > 7 0x7bf7a000 0x7bf7a > 8 0x1 0x10 > 9 0x10060 0x100600 > 10 0x0 0x0 > Maxmem: 0x10060 0x100600 > > Without using atop (the "buggy" version that actually boots without > crashing), the loop in mp_bootaddress looks like this: > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > 8 0x1 0x10060 0x100600 0x100600 > 6 0x100 0x7bf7a000 0x7bf7a 0x100600 > 4 0x10 0xf0 0xf00 0x100600 > 2 0x4 0x9e400 0x9e 0x100600 > > And physmap looks like this afterwards: > > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x3 0x30 > 2 0x43000 0x43 <-- here > 3 0x9e400 0x9e > 4 0x10 0x100 > 5 0xf0 0xf00 > 6 0x100 0x1000 > 7 0x7bf7a000 0x7bf7a > 8 0x1 0x10 > 9 0x10060 0x100600 > 10 0x0 0x0 > mptramp_pagetables is 0x4 > > So a three page gap was made at 0x4 (atop(idx 2) is now 0x43 > instead of 0x40) > > In the current version (using atop), the loop in mp_bootaddress > looks like this: > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > 8 0x1 0x10060 0x100600 0x100600 > 6 0x100 0x7bf7a000 0x7bf7a 0x100600 > > And physmap looks like this afterwards: >
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 10:05 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 11:54:51AM -0400, Joe Maloney wrote: > > I ran into this as well months ago. To workaround it I extracted > > userboot.so for the VM's, and launched bhyve with the alternate > > userboot.so. You can use a flag as described in the manpage to start > > userboot.so from an alternate location. > > > > https://www.freebsd.org/cgi/man.cgi?query=bhyveload&sektion=8 > > > > Also support was recently added for vm-bhyve to specify alternate > > userboot.so location for one that is compatible with 4th. You just need > to > > extract that somewhere onto the host, and specify it to load when > starting > > the VM. > > > > https://github.com/churchers/vm-bhyve/blob/ > d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample > > > > Alternatively you could just use UEFI, or UEFI-CSM firmware. > Ok, so pulling /boot/userboot.so from my non-upgraded 12 system and > putting it in /boot/userboot-4th.so on the host allows the VM's to boot > after changing the config files to point bhyveload_loader to it (yes, > I'm using vm-bhyve). > > This default change is a POLA violation for bhyve/vm-bhyve users. OK. We're on it. Thanks for the heads up. We were unaware of the issue when we flipped the switch. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 11:54:51AM -0400, Joe Maloney wrote: > I ran into this as well months ago. To workaround it I extracted > userboot.so for the VM's, and launched bhyve with the alternate > userboot.so. You can use a flag as described in the manpage to start > userboot.so from an alternate location. > > https://www.freebsd.org/cgi/man.cgi?query=bhyveload&sektion=8 > > Also support was recently added for vm-bhyve to specify alternate > userboot.so location for one that is compatible with 4th. You just need to > extract that somewhere onto the host, and specify it to load when starting > the VM. > > https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample > > Alternatively you could just use UEFI, or UEFI-CSM firmware. Ok, so pulling /boot/userboot.so from my non-upgraded 12 system and putting it in /boot/userboot-4th.so on the host allows the VM's to boot after changing the config files to point bhyveload_loader to it (yes, I'm using vm-bhyve). This default change is a POLA violation for bhyve/vm-bhyve users. [snip] -- Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: LUA loader: bhyve now doesn't?
I ran into this as well months ago. To workaround it I extracted userboot.so for the VM's, and launched bhyve with the alternate userboot.so. You can use a flag as described in the manpage to start userboot.so from an alternate location. https://www.freebsd.org/cgi/man.cgi?query=bhyveload&sektion=8 Also support was recently added for vm-bhyve to specify alternate userboot.so location for one that is compatible with 4th. You just need to extract that somewhere onto the host, and specify it to load when starting the VM. https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample Alternatively you could just use UEFI, or UEFI-CSM firmware. Joe Maloney QA Manager / iXsystems Enterprise Storage & Servers Driven By Open Source On Sun, Aug 19, 2018 at 11:38 AM Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > > > With today's change to LUA as the loader, I seem to have an issue with > > > bhyhve: > > > > > > Consoles: userboot > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > > Startup error in /boot/lua/loader.lua: > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > > syms=[0x8+0x14cf28+0x8+0x163e57] > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > > > > These VM's have been running for MONTHS. > > > > > > Ideas? > > > > > > > There's no boot/lua/loader.lua. > > > > You can either fix that, or you can recompile with > > LOADER_DEFAULT_INTERP=4th for the moment. > actually on the host there is: > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > total 131 > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > borg.lerctr.org /home/ler $ > > This is when booting the vm, and it's not on the vm's disk. > > So the bhyveload behavior *CHANGED*. > > POLA? > > > > > > 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" > > -- > Larry Rosenman https://people.FreeBSD.org/~ler/ > Phone: +1 214-642-9640 E-Mail: l...@freebsd.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 > ___ 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: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 09:42:05AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > > > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > > > > > With today's change to LUA as the loader, I seem to have an issue with > > > > bhyhve: > > > > > > > > Consoles: userboot > > > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > > > Startup error in /boot/lua/loader.lua: > > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > > > syms=[0x8+0x14cf28+0x8+0x163e57] > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > Booting [/boot/kernel/kernel]... > > > > > > > > These VM's have been running for MONTHS. > > > > > > > > Ideas? > > > > > > > > > > There's no boot/lua/loader.lua. > > > > > > You can either fix that, or you can recompile with > > > LOADER_DEFAULT_INTERP=4th for the moment. > > actually on the host there is: > > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > > total 131 > > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > > borg.lerctr.org /home/ler $ > > > > This is when booting the vm, and it's not on the vm's disk. > > > > So the bhyveload behavior *CHANGED*. > > > > POLA? > > > > Unlikely, but a couple of questions. Have you always used the LUA loader, > or is this a change with the recent default switch? I've *NEVER* used the lua loader until today's default change. > > And to be clear, you expect the host's file to be used for this, not the VM > filesystem? No, but apparently /boot/userboot.so (from the host?) DOES expect the VM's disk to have lua now. > > I'll look into this later today. Thanks. > > 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" -- Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > > > With today's change to LUA as the loader, I seem to have an issue with > > > bhyhve: > > > > > > Consoles: userboot > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > > Startup error in /boot/lua/loader.lua: > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > > syms=[0x8+0x14cf28+0x8+0x163e57] > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > > > > These VM's have been running for MONTHS. > > > > > > Ideas? > > > > > > > There's no boot/lua/loader.lua. > > > > You can either fix that, or you can recompile with > > LOADER_DEFAULT_INTERP=4th for the moment. > actually on the host there is: > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > total 131 > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > borg.lerctr.org /home/ler $ > > This is when booting the vm, and it's not on the vm's disk. > > So the bhyveload behavior *CHANGED*. > > POLA? > Unlikely, but a couple of questions. Have you always used the LUA loader, or is this a change with the recent default switch? And to be clear, you expect the host's file to be used for this, not the VM filesystem? I'll look into this later today. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > With today's change to LUA as the loader, I seem to have an issue with > > bhyhve: > > > > Consoles: userboot > > > > FreeBSD/amd64 User boot, Revision 1.1 > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > > Startup error in /boot/lua/loader.lua: > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > syms=[0x8+0x14cf28+0x8+0x163e57] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > > > These VM's have been running for MONTHS. > > > > Ideas? > > > > There's no boot/lua/loader.lua. > > You can either fix that, or you can recompile with > LOADER_DEFAULT_INTERP=4th for the moment. actually on the host there is: borg.lerctr.org /home/ler $ ls -l /boot/lua/ total 131 -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua borg.lerctr.org /home/ler $ This is when booting the vm, and it's not on the vm's disk. So the bhyveload behavior *CHANGED*. POLA? > > 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" -- Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: LUA loader: bhyve now doesn't?
On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > With today's change to LUA as the loader, I seem to have an issue with > bhyhve: > > Consoles: userboot > > FreeBSD/amd64 User boot, Revision 1.1 > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) > Startup error in /boot/lua/loader.lua: > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > syms=[0x8+0x14cf28+0x8+0x163e57] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > > These VM's have been running for MONTHS. > > Ideas? > There's no boot/lua/loader.lua. You can either fix that, or you can recompile with LOADER_DEFAULT_INTERP=4th for the moment. 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"
LUA loader: bhyve now doesn't?
With today's change to LUA as the loader, I seem to have an issue with bhyhve: Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org) Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 syms=[0x8+0x14cf28+0x8+0x163e57] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... These VM's have been running for MONTHS. Ideas? -- Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 signature.asc Description: PGP signature
Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Fri, 17 Aug 2018 10:02:08 +0100 John Baldwin wrote: > On 8/17/18 9:54 AM, Michael Gmelin wrote: > > > > > >> On 17. Aug 2018, at 08:17, John Baldwin wrote: > >> > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > >>> > >>> > On 15. Aug 2018, at 15:55, Konstantin Belousov > mailto:kostik...@gmail.com>> wrote: > > On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: > > > > > >>> On 15. Aug 2018, at 15:04, Konstantin Belousov > >>> mailto:kostik...@gmail.com>> wrote: > >>> > >>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > >>> wrote: Reviving this old thread, since I just updated to > >>> r337818 and a similar problem is happening again. Since the > >>> fix in r334799 (review https://reviews.freebsd.org/D15675) > >>> (mp_)machdep.c have been touched, so maybe this is related > >>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). > >>> > >>> Please see the screenshot of the panic below: > >>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > >>> > >>> This is me not digging any deeper, hoping that this is > >>> something obvious. Please let me know if you need more > >>> input. > >> > >> I do not see how recent mp_machdep.c changes could affect this. > >> Can you try newest kernel but old loader ? > > > > I will try (but that will take a while). Oh, also, it still > > boots in save mode/with smp disabled. > > Right, this is because the access to that address through DMAP > is only needed when configuring AP startup resources. > > Also, I think it is safe to suggest that the bisect is needed. > >>> > >>> Using an older loader didn’t help, but I identified the problem: > >>> > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 > >>> > >>> modified the code you introduced in > >>> > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 > >>> > >>> By correcting units to pages it also broke booting the Chromebook > >>> as a side effect - so the previous fix just worked due to a bug > >>> it seems. > >>> > >>> Is there an easy way to output the content of physmap at that > >>> point (debug.late_console=0 doesn’t work) - like an existing > >>> buffer I could use, or would this be more elaborate (I did > >>> something complicated last time but didn’t save it, so any simple > >>> solution would be preferred). > >> > >> How about reverting the commit for now so you get a working console > >> and print out the physmap array values along with Maxmem later in > >> the boot (or just use kgdb to examine them once the system is > >> running)? > > > > This is before the system has a working console (part of calling > > getmem...), disabling late console makes it hang, physmap changes > > afterwards, so running kgdb later doesn’t help. Last time I kept a > > copy of physmap and logged it later to know the original content. I > > can do that again, I just thought maybe there is a simple mechanism > > I’m not aware of that would save me some time. > > I thought we only modified phys_avail[], but saving a copy of > physmap[] and dumping it from kgdb is probably the simplest thing to > do. > Okay, so I had some time to investigate a bit more: Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), physmap looks like this: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x3 0x30 2 0x4 0x40 3 0x9e400 0x9e 4 0x10 0x100 5 0xf0 0xf00 6 0x100 0x1000 7 0x7bf7a000 0x7bf7a 8 0x1 0x10 9 0x10060 0x100600 10 0x0 0x0 Maxmem: 0x10060 0x100600 Without using atop (the "buggy" version that actually boots without crashing), the loop in mp_bootaddress looks like this: i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem 8 0x1 0x10060 0x100600 0x100600 6 0x100 0x7bf7a000 0x7bf7a 0x100600 4 0x10 0xf0 0xf00 0x100600 2 0x4 0x9e400 0x9e 0x100600 And physmap looks like this afterwards: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x3 0x30 2 0x43000 0x43 <-- here 3 0x9e400 0x9e 4 0x10 0x100 5 0xf0 0xf00 6 0x100 0x1000 7 0x7bf7a000 0x7bf7a 8 0x1 0x10 9 0x10060 0x100600 10 0x0 0x0 mptramp_pagetables is 0x4 So a three page gap was made at 0x4 (atop(idx 2) is now 0x43 instead of 0x40) In the current version (using atop), the loop in mp_bootaddress looks like this: i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem 8 0x1 0x10060 0x100600 0x100600 6 0x100 0x7bf7a000 0x7bf7a 0x100600 And physmap looks like this afterwards: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x3 0x30 2 0x4 0x40 3 0x9e400 0x9e 4 0x10 0x100 5 0xf0 0xf00 6 0x1003000 0x1003 <-- here 7 0x7bf7a000 0x7bf7a 8 0x1 0x10 9 0x10060 0x100600 10 0x0 0x0 mptramp_pagetables: 0x100 So a three page gap was made at 0x100 (atop(idx 6) is now 0x1003 instead of 0x1000) When chan
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On Sun, Aug 19, 2018 at 6:30 PM O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sun, 19 Aug 2018 00:34:20 +0200 > Dhananjay Balan schrieb: > > > Hi, > > > > I run 12-CURRENT on few machines, some more powerful that other (all > > of them x86_64, march varies). > > > > Is there is a way to avoid building CURRENT on all machines? Rather > > than building everywhere, can I just build it on the big server that I > > have and copy and update my laptop? > > > > - > > Dhananjay Balan > [...] > > Yes, you can. > We do this via a custom build and creating packages as this is introduced > at > > https://wiki.freebsd.org/PkgBase > > But beware! As many others have already stated, take care about to use the > least common > denominator of achitectural specifications amongst your pools! This means > to not use any > kind of optimizations for a specific CPU type for pkg-base distributed > builds! > > Because we build the local OS for fast/server machines always(!) with > optimisations, the > pkg-base builds are done in a separate way - which is very easy if you've > once understood > the really neat and great build framework of FreeBSD's! > > Instead of building the traditional (probably optimised) system from > /usr/src > and /usr/obj, now you've to consider a separate path like > /pool/sources/CURRENT/src (our > way, since we also try to build packages and object trees for 11.X), then > setup a small > build script that essentially sets > > MAKEOBJDIRPREFIX > KERNCONFDIR > KERNCONF > > and especially > > __MAKE_CONF > SRCCONF > SRC_ENV_CONF > > if you use usually optimisations for the native target build on the > building host and > more generic binaries for the Intel x86 crap for redistribution. > > Doing so, we also perform builds for some ARM64 based experimental boxes. > > The next step is then up to you how to distribute. We copy all the pkg > stuff coming out > of the build cycle to a folder which is accessible by pkg via HTTP(S) - so > www/apache24 > is our platform to redistribute the binaries over the network and even to > remote sites > (beware of the security implications!). You also can distribute the > obj-folder (/usr/obj, > or, if using another approach, like /pool/sources/CURRENT/obj) via NFS. > > Once you've understood the (easy to learn) concept of building the source > tree, creating > the packages for pkg-base and having dealt with the more labor for the > setting of a > distribution server, you can use the most potent server/box on you network > for building > dedicated distributions > > Even a "Release" build is possible as long as there are not pitfalls like > they occured > during the transition from 11.X to more 12-CURRENT spcific development > (i.e. LINT). > > If you use pkg-base as mentioned above, be aware to setup a proper > pkg.conf file as > introduced on the Wiki and please be also aware of the fact, that there is > at the moment > no sharp separation between pkg-base and oridnary pkg for packages - so > take the > warinig serious, that pkg delete -a will not only kill all packages, it > also will kill > all packages installed for the base system! > > Once installed you'll see how fast compared to source build the pkg-base > installation > is (although I still prefer source build, optimised builds ...). > > And by the way: depending on the sophistication of your build script for > dedicated > tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're > able to also > build optimised binary trees for different CPU types, but you have to deal > yourself > with the fact that you've to put the binaries into a proper place and then > delegate the > URI in pkg.conf to the correct branch of your tree. The ABI environmental > variable > doesn't take care of the "set" you may have used to optimise. But this is > something > you're able to deal with easily yourself after having setup your basic > build > environment. > > Regards, > > oh > > - -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > -BEGIN PGP SIGNATURE- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY > lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2 > PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG > 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM > =/rzO > -END PGP SIGNATURE- > ___ > 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" > I would say setup a poudriere build bot on your most powerful machine to build and test all the applications and tools that your weaker machines need, then setup a custom pkg repo so once poudriere builds all the ports and create packages from them. Then you use the custom pkg url to update your oth
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Sun, 19 Aug 2018 00:34:20 +0200 Dhananjay Balan schrieb: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? > > - > Dhananjay Balan [...] Yes, you can. We do this via a custom build and creating packages as this is introduced at https://wiki.freebsd.org/PkgBase But beware! As many others have already stated, take care about to use the least common denominator of achitectural specifications amongst your pools! This means to not use any kind of optimizations for a specific CPU type for pkg-base distributed builds! Because we build the local OS for fast/server machines always(!) with optimisations, the pkg-base builds are done in a separate way - which is very easy if you've once understood the really neat and great build framework of FreeBSD's! Instead of building the traditional (probably optimised) system from /usr/src and /usr/obj, now you've to consider a separate path like /pool/sources/CURRENT/src (our way, since we also try to build packages and object trees for 11.X), then setup a small build script that essentially sets MAKEOBJDIRPREFIX KERNCONFDIR KERNCONF and especially __MAKE_CONF SRCCONF SRC_ENV_CONF if you use usually optimisations for the native target build on the building host and more generic binaries for the Intel x86 crap for redistribution. Doing so, we also perform builds for some ARM64 based experimental boxes. The next step is then up to you how to distribute. We copy all the pkg stuff coming out of the build cycle to a folder which is accessible by pkg via HTTP(S) - so www/apache24 is our platform to redistribute the binaries over the network and even to remote sites (beware of the security implications!). You also can distribute the obj-folder (/usr/obj, or, if using another approach, like /pool/sources/CURRENT/obj) via NFS. Once you've understood the (easy to learn) concept of building the source tree, creating the packages for pkg-base and having dealt with the more labor for the setting of a distribution server, you can use the most potent server/box on you network for building dedicated distributions Even a "Release" build is possible as long as there are not pitfalls like they occured during the transition from 11.X to more 12-CURRENT spcific development (i.e. LINT). If you use pkg-base as mentioned above, be aware to setup a proper pkg.conf file as introduced on the Wiki and please be also aware of the fact, that there is at the moment no sharp separation between pkg-base and oridnary pkg for packages - so take the warinig serious, that pkg delete -a will not only kill all packages, it also will kill all packages installed for the base system! Once installed you'll see how fast compared to source build the pkg-base installation is (although I still prefer source build, optimised builds ...). And by the way: depending on the sophistication of your build script for dedicated tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're able to also build optimised binary trees for different CPU types, but you have to deal yourself with the fact that you've to put the binaries into a proper place and then delegate the URI in pkg.conf to the correct branch of your tree. The ABI environmental variable doesn't take care of the "set" you may have used to optimise. But this is something you're able to deal with easily yourself after having setup your basic build environment. Regards, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2 PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM =/rzO -END PGP SIGNATURE- ___ 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: Sharing compiled builds between multiple 12-CURRENT boxes.
Dhananjay Balan wrote on 2018/08/19 00:34: Hi, I run 12-CURRENT on few machines, some more powerful that other (all of them x86_64, march varies). Is there is a way to avoid building CURRENT on all machines? Rather than building everywhere, can I just build it on the big server that I have and copy and update my laptop? Yes and we are using it (for STABLE, but it works for all versions). You can build it on you build server and export it with NFS. https://www.freebsd.org/cgi/man.cgi?query=development&sektion=7 Miroslav Lachman ___ 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: Sharing compiled builds between multiple 12-CURRENT boxes.
On 19/08/2018 01:55, Shane Ambler wrote: >> I run 12-CURRENT on few machines, some more powerful that other (all >> of them x86_64, march varies). > You can use freebsd-update by setting up your own update server > https://www.freebsd.org/doc/en/articles/freebsd-update-server freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP specified. Cheers, Matthew signature.asc Description: OpenPGP digital signature
