From owner-freebsd-current@freebsd.org Wed Feb 21 15:37:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 454C1F0DF03 for ; Wed, 21 Feb 2018 15:37:13 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDF4881DCA; Wed, 21 Feb 2018 15:37:12 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-ua0-f169.google.com with SMTP id z3so1270254uae.12; Wed, 21 Feb 2018 07:37:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=APwLQJs1AI5z0aKrXkG8vzxK7t/+8jgUZuw8Yfuljnw=; b=gx8Sv7pfM/bSDAKSO7HdXVJm1eZe1X9lH0tGHT7ZALDwhesUrDSYe+ZIXEkA/3puHV ZFmdWc5xHA6MtsSeNjTgcHCZ+iX750kQ+vCDT48q/fLsDln2nzMSkkzcy52mEelvJBye UqNuqjxRP/MqsZbGaPzYioLLCNy+nn5Vf4mfTh4vlkIjptrwHbeAilqxGvTtve/qXlWh WY4KDyXJPj9UzTD9OT31DsX4uEN6OAVB9yfnVldoVjDP/xZ9KVhTbdLmveDsmJujwgM1 Jk4KFj5ipf25Uvn9K6H1qH69KK3lHmRuBgFMXyrQOSPGScqPGrdFVUFR7xs3SdJBQvLh QaTA== X-Gm-Message-State: APf1xPDfJq8WlpmWKb3Ff0+nzKQigxYdQs0Kk8AI4Xr/xQjsqlPW8Yy1 pCIcR6dG98SADwueMJeRQ8S6zHsD X-Google-Smtp-Source: AH8x225M92CwNIOA2hCCvCAXzMPNTzBoxhmEeVKpdq5J4bLCwtRbbGvo6g8WHjHqI/4lpcbsxERMRQ== X-Received: by 10.176.72.197 with SMTP id y5mr2822445uac.122.1519227047619; Wed, 21 Feb 2018 07:30:47 -0800 (PST) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com. [209.85.217.179]) by smtp.gmail.com with ESMTPSA id v2sm9223641uaf.7.2018.02.21.07.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 07:30:47 -0800 (PST) Received: by mail-ua0-f179.google.com with SMTP id c20so406209uak.6; Wed, 21 Feb 2018 07:30:47 -0800 (PST) X-Received: by 10.159.62.13 with SMTP id o13mr2634222uai.83.1519227046780; Wed, 21 Feb 2018 07:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.197.146 with HTTP; Wed, 21 Feb 2018 07:30:26 -0800 (PST) In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Kyle Evans Date: Wed, 21 Feb 2018 09:30:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Warner Losh Cc: =?UTF-8?Q?Juan_Ram=C3=B3n_Molina_Menor?= , "Rodney W. Grimes" , FreeBSD Current , Warner Losh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:37:13 -0000 On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh wrote: > > > On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans wrote: >> >> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ram=C3=B3n Molina Menor >> wrote: >> > Le 20/02/2018 =C3=A0 22:45, Kyle Evans a =C3=A9crit : >> >> >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram=C3=B3n Molina Menor >> >> >> >> wrote: >> >>> >> >>> [... snip ...] >> >>> >> >>> Moreover, the "boot [kernel]" loader command does not work: >> >>> >> >>> OK ls /boot/kernel.old/kernel >> >>> /boot/kernel.old/kernel >> >>> OK boot kernel.old >> >>> Command failed >> >>> OK boot /boot/kernel.old/kernel >> >>> Command failed >> >>> OK boot kernel >> >>> Command failed >> >>> >> >>> On the other hand, just "boot" works. >> >>> >> >> >> >> This part should work as expected as of r329674, so please give that = a >> >> shot. I'm still trying to see if I can reproduce your box drawing >> >> problem. >> >> >> >> Thanks, >> >> >> >> Kyle Evans >> >> >> > >> > Thanks Kyle. >> > >> > boot command works now. There is though a somewhat strangely formulate= d >> > messages when trying to load an non-existent kernel: >> > >> > OK boot fake >> > Failed to load kernel =E2=80=99fake=E2=80=99 >> > Failed to load any kernel >> > can=E2=80=99t load =E2=80=99kernel=E2=80=99 >> > >> > The two last lines are odd: Did the loader try to load a fallback kern= el >> > and >> > failed? That would explain the =E2=80=99kernel=E2=80=99 name in quotes= , but I have such >> > a >> > kernel=E2=80=A6 Also, just nitpicking, but "can=E2=80=99t" should be c= apitalized. >> >> (CC'ing Rod, since he also commented on this) >> >> I'm only directly responsible for the first two messages. =3D) I've >> removed the second one, though, since it was a carry-over from when it >> would try to load the selected kernel and then some default kernel >> that might be in your module_path. >> >> We can look at changing "can't load 'kernel'" to capitalize and remove >> the contraction, but that's common loader stuff and should've also >> been displayed for the same Forth scenario. >> >> > Then, I have just remembered why I was seeing a higher resolution menu >> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the n= ew >> > loader is not implementing the inclusion of this file, because I can >> > change >> > the gop mode in the loader with 'gop set [0-3]'. >> > >> >> Oy. This is actually a Forth file, so we can't really maintain all of >> the functionality that would have been allowed there. Technically, >> things like this should probably either appear in your loader.conf(5) >> in the form of 'exec=3D"gop set 3"' to be applied when loader.conf(5) is >> read, or we should provide some other means of running pure loader >> command scripts at different points in the loader sequence. (CC >> Warner, because he probably has thoughts about this latter idea) > > > While loader.rc is FORTH, it's contrived FORTH designed to look like comm= and > line interaction. While some crazy people like me have actual forth in > these, most do not, really (apart from the include /boot/XXX.4th lines, t= hat > is, which could be filtered). > > We have two choices here: Try to provide some level of compatibility shim= s, > or provide a new way to say these things in Lua. > > In the original SoC code, loader.lua lived in /boot and looked to be > something that people could modify. We likely need to do something simila= r. > loader.lua right now has nothing but were in the forth world called > 'include' and then very similar commands to the forth loader.rc. Perhaps = the > right answer is to move cli_execute out of /boot/lua/loader.lua, move tha= t > file up, and add the try-include functionality to try to include a > loader.local.lua. Then we could tell people to move to the Lua syntax way= of > doing things. We'd have to hunt down all the hacks like this, but that > wouldn't be terrible. Bonus points if we could convert the common ones > either to lua code automatically, or to loader.conf variables. We have something like this that I added yesterday in r329692, but named a little bit differently ("local.lua", "local module"). Mostly added because I've been using it to locally add test menu options and writing some of the documentation for how to hook into our new lua system to do things, and it was getting tiresome having to manually revert those bits in loader.lua when I wanted to make changes to the in-tree loader.lua. We'd basically rename this to loader.local.lua to match more closely to current convention, move "cli_execute" out to either core.lua or maybe it and the boot commands are worthy of their own "cli" module, then be happy. > This specific example should have always been a loader.conf variable (and > not an exec). While the gop command is useful, the loader should have, as > part of it's forth sequence, had something that would set the GOP mode if > the uefi_gop_mode loader.conf variable was set (I get why that wasn't don= e > that way in the forth loader, insert rant of Fear of FORTH here). So we > should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few > other things that are simple settings to make it easier for users to set > this stuff up and start to move away from the FoF kludges that we've > accumulated. A new loader.conf variable would also allow coexistence of t= he > two loaders, which will be further helped with some patches I have to the > build system coming soon. Right, this seemed like something worthy of its own loader.conf(5) variable. I didn't patch that idea, though, because I didn't necessarily want to write the Forth handling of it. =3D)