From owner-freebsd-current@freebsd.org Wed Feb 21 14:55:06 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 AF001F090F3 for ; Wed, 21 Feb 2018 14:55:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 3E2227F87F for ; Wed, 21 Feb 2018 14:55:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id t22so2407529iob.3 for ; Wed, 21 Feb 2018 06:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hgJUYyKx0DUr06Rt0mqjxkv8Mz8iPvpm+JBzet8nWmo=; b=0AiDP+gdVCRkhYTNsdvO5R0fYQEq4VJ3Cfigq3ZWnIfBXhZyoOqC3uea0/uB6HKcDY 1hj+OdgIBPgmQmI/gj1ZImq4feG85Ai6rxTr+8x6PBvKa7Zgp29i3JVB14RzcCl9nZ9x L+XoyeSfoyBac0IoM8GSfPGU88xeo1j+7AjXorkSwlMyKIpEJX+CtNZbbINN6j94CxuH DBSg263C3d9zF3ugo4Eog8E3c7GbKgY09YEjQ1mH5dwjTbWEuWWvme0Mh2iJNtOq/lbw RWyKz9vg615yKUlrDJUOiGvD+AyTrUEZrBLtMRJWbbDYoKynQ7EXsqoCsdqQFcrBQXvE ny8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hgJUYyKx0DUr06Rt0mqjxkv8Mz8iPvpm+JBzet8nWmo=; b=tw0M293znbHpkKs6tDeGpdgbz5PZJrlYCHvNQpx+dEB6jtZPMyA9Ov8noVfUJw0fNg h4Bef+Jw6gaxqQaOr6PGcfBYBjAo5p4WwhVkv/ajw1Gf1b61EfzjU72dbx1Gd7PnKUxI txuzotzYVUxIHpz0KytQgR8X4cTHXZqvU0rGg/Slsf4oxOQlEpBv+gXpsni201u0EDoq T56Iapu9G1J61afTZbogcB3BkFNNKu1IkmdFm47yYwhOTUv1BXMRV4bIAMlNk4By0tdW dOJduXhgWQj1bQhl7Q1FP9UrnoqbvPOV2h9JlrazyFUkbvErjkeCgN1KQTy0w1HHVk6i yAXg== X-Gm-Message-State: APf1xPC85Obnz86oAfVmxc8DG7y8en/djTjfS2S59ge7+esp/2/GwoJk MZ/vXu7NaXN2QXl0NYiXpI/QsyfyN/J05cEhX3yRCA== X-Google-Smtp-Source: AG47ELvw714Vmt2q4oaECQMkQ5BHIJFYGRFCZBXfEQnn6wRzJ00s9IcaGlVqWmwZQ+JVeS6LagYK7kKezirbryvInsY= X-Received: by 10.107.2.6 with SMTP id 6mr4334870ioc.117.1519224905299; Wed, 21 Feb 2018 06:55:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 21 Feb 2018 06:55:04 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <2AFF3AE4-8740-4776-9D8D-7D709EE051C6@gmail.com> <1b9e58fe-2616-b04b-13c2-fee78a33ad6e@club.fr> From: Warner Losh Date: Wed, 21 Feb 2018 07:55:04 -0700 X-Google-Sender-Auth: SsPfQOS9xl4ui3HrSuqAI2Il9O4 Message-ID: Subject: Re: ACPI panic on boot with new Lua loader and other minor issues To: Kyle Evans 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-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 14:55:07 -0000 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 < > listjm@club.fr> > >> 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 formulated > > 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 kerne= l > 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 ca= pitalized. > > (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 ne= w > > 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 command 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, that is, which could be filtered). We have two choices here: Try to provide some level of compatibility shims, 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 similar. 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 that 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. 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 done 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 the two loaders, which will be further helped with some patches I have to the build system coming soon. Warner