Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

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ón Molina Menor 
>> wrote:
>> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>> >>
>> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón 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 formulated
>> > messages when trying to load an non-existent kernel:
>> >
>> > OK boot fake
>> > Failed to load kernel ’fake’
>> > Failed to load any kernel
>> > can’t load ’kernel’
>> >
>> > The two last lines are odd: Did the loader try to load a fallback kernel
>> > and
>> > failed? That would explain the ’kernel’ name in quotes, but I have such
>> > a
>> > kernel… Also, just nitpicking, but "can’t" should be capitalized.
>>
>> (CC'ing Rod, since he also commented on this)
>>
>> I'm only directly responsible for the first two messages. =) 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 new
>> > 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="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.

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 done
> that way in the forth loader, insert rant of Fear of FORTH here). So we
> 

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans  wrote:

> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor 
> wrote:
> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
> >>
> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <
> lis...@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 ’fake’
> > Failed to load any kernel
> > can’t load ’kernel’
> >
> > The two last lines are odd: Did the loader try to load a fallback kernel
> and
> > failed? That would explain the ’kernel’ name in quotes, but I have such a
> > kernel… Also, just nitpicking, but "can’t" should be capitalized.
>
> (CC'ing Rod, since he also commented on this)
>
> I'm only directly responsible for the first two messages. =) 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 new
> > 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="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
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Rodney W. Grimes]

> Le 20/02/2018 ? 22:45, Kyle Evans a ?crit?:
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram?n 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 formulated 
> messages when trying to load an non-existent kernel:
> 
> OK boot fake
> Failed to load kernel ?fake?
> Failed to load any kernel
> can?t load ?kernel?
> 
> The two last lines are odd: Did the loader try to load a fallback kernel 
> and failed? That would explain the ?kernel? name in quotes, but I have 
> such a kernel? Also, just nitpicking, but "can?t" should be capitalized.

To be supper nt picky can't should also be spelled can not.

> 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 new 
> loader is not implementing the inclusion of this file, because I can 
> change the gop mode in the loader with 'gop set [0-3]'.
> 
> This has thus nothing to do with the drawing lines, I guess.
> 
> Best regards.
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor  wrote:
> Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>>
>> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón 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 formulated
> messages when trying to load an non-existent kernel:
>
> OK boot fake
> Failed to load kernel ’fake’
> Failed to load any kernel
> can’t load ’kernel’
>
> The two last lines are odd: Did the loader try to load a fallback kernel and
> failed? That would explain the ’kernel’ name in quotes, but I have such a
> kernel… Also, just nitpicking, but "can’t" should be capitalized.

(CC'ing Rod, since he also commented on this)

I'm only directly responsible for the first two messages. =) 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 new
> 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="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)
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 20/02/2018 à 22:45, Kyle Evans a écrit :

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón 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 formulated 
messages when trying to load an non-existent kernel:


OK boot fake
Failed to load kernel ’fake’
Failed to load any kernel
can’t load ’kernel’

The two last lines are odd: Did the loader try to load a fallback kernel 
and failed? That would explain the ’kernel’ name in quotes, but I have 
such a kernel… Also, just nitpicking, but "can’t" should be capitalized.


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 new 
loader is not implementing the inclusion of this file, because I can 
change the gop mode in the loader with 'gop set [0-3]'.


This has thus nothing to do with the drawing lines, I guess.

Best regards.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón 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
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello!


On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.



Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...

In fact, I don’t think this has ever worked here… I’ve found a very old (July 
2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

Thanks.



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.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.

I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 
4GB RAM). The only thing I can think of is that the ACPI of this model is not 
well supported, but the errors I have are related to thermal zones…:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache 
and WITH_META_MODE, but this build process has been working nicely for months.

The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of things 
to slim down the memstick, but still, it has been stable till now:

juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks setting locale and thus tmux
#WITHOUT_LOCALES=
WITHOUT_LPR=

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 3:38 PM, "Kyle Evans"  wrote:

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco
to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script,
it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not
sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot
them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.


Forth has a framework for making all commands forth words. It leverages
that to run the intercept. We already have the intercept in place with a
stupidly simple policy. We totally can do something generic that would
solve this and maybe other problems. Let's chat online tomorrow about a
couple of possibilities we can choose from.

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: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 4:32 PM, Warner Losh  wrote:
> 
> 
> 
>> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>> 
>> 
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>> 
>> I can indeed confirm this as fact.
>> 
>> Not able to help much because I am driving cross-country (San Francisco to 
>> Orlando) right now with the spouse and dog.
>> 
>> We get back March 3rd, but I will be checking-in from time to time for 
>> sporadic responses during downtime.
> 
> The command in loader.4th is defined as:
> 
> : boot
>   0= if ( interpreted ) get_arguments then
> 
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ; 
> 
> The thing to know here is when you see 'boot' as part of above script, it's 
> calling the 'boot' cli command, not itself recursively.
> 

What is actually going on is that when the “boot” function is compiled, the 
reference to “boot” inside it is to the already-existing word defined 
previously. Forth allows you to have multiply-defined names. The “boot” command 
inside the “boot” function is replaced with the address of previous boot during 
function compilation because the function is m not defined and given an address 
in the dictionary until it is completed (last line compiled).
— 
Devin
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

 gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei  wrote:
>
>
> On 2/19/18 5:48 PM, Kyle Evans wrote:
>>
>>
>> On Feb 19, 2018 5:44 PM, "Peter Lei" > > wrote:
>>
>>
>>
>> On 2/19/18 2:21 PM, Kyle Evans wrote:
>> > Hello!
>> >
>> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
>> > wrote:
>> >> I have done a full build of r329555 to test the new Lua boot loader.
>> >>
>> >> Both the new and the old kernels panic after being loaded with:
>> >>
>> >> panic: running without device atpic requires a local APIC
>> >>
>> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
>> a previous
>> >> message:
>> >>
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>> 
>> 
>> >>
>> >> OK show hint.acpi.0.disabled
>> >> 1
>> >>
>> >> Setting ACPI to On resolves the issue.
>> >
>> > As David noted, this should actually Just Work (TM) now. Can you break
>> > into a loader prompt with just the forth loader and tell me what "show
>> > hint.acpi.0.rsdp" looks like?
>>
>>
>> This doesn't appear to "just work out-of-the-box" yet when EFI booting
>> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
>>
>> Under EFI and lua loader, the following is set when breaking to prompt:
>> hint.acpi.0.disabled=1
>> Under forth loader, this is not present/set.
>>
>> In neither case is hint.acpi.0.rsdp present/set as that appears to get
>> set during the exec of the loaded kernel...
>>
>> I've worked around the issue by adding hint.acpi.0.disabled="0" to
>> loader.conf (or patching the amd64 efi loader code to explicitly clear
>> that hint).
>>
>>
>> [Apologies for broken quoting, currently mobile]
>>
>> What happens if you patch this line out?
>> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233
>
>
> Ah, right - yep, commenting out that line works.
>

This should be fixed as of r329614. hint.acpi.0.rsdp gets set upon
exec of the loaded kernel in the EFI world, then in i386 world it's
before lualoader comes into play. We should probably do as forth does
and disable ACPI stuff on !i386 (IIRC the option disappears
completely), but IIRC we haven't yet exposed TARGET/TARGET_ARCH to
lua.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 5:48 PM, Kyle Evans wrote:
> 
> 
> On Feb 19, 2018 5:44 PM, "Peter Lei"  > wrote:
> 
> 
> 
> On 2/19/18 2:21 PM, Kyle Evans wrote:
> > Hello!
> >
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
> > wrote:
> >> I have done a full build of r329555 to test the new Lua boot loader.
> >>
> >> Both the new and the old kernels panic after being loaded with:
> >>
> >> panic: running without device atpic requires a local APIC
> >>
> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
> a previous
> >> message:
> >>
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
> 
> 
> >>
> >> OK show hint.acpi.0.disabled
> >> 1
> >>
> >> Setting ACPI to On resolves the issue.
> >
> > As David noted, this should actually Just Work (TM) now. Can you break
> > into a loader prompt with just the forth loader and tell me what "show
> > hint.acpi.0.rsdp" looks like?
> 
> 
> This doesn't appear to "just work out-of-the-box" yet when EFI booting
> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
> 
> Under EFI and lua loader, the following is set when breaking to prompt:
>     hint.acpi.0.disabled=1
> Under forth loader, this is not present/set.
> 
> In neither case is hint.acpi.0.rsdp present/set as that appears to get
> set during the exec of the loaded kernel...
> 
> I've worked around the issue by adding hint.acpi.0.disabled="0" to
> loader.conf (or patching the amd64 efi loader code to explicitly clear
> that hint).
> 
> 
> [Apologies for broken quoting, currently mobile]
> 
> What happens if you patch this line out?
> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233


Ah, right - yep, commenting out that line works.


> I'll have to go back and figure out what I was thinking here again. It
> made sense when I wrote it, maybe explicitly disabling ACPI if it's not
> immediately detected was the wrong move. =)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Feb 19, 2018 5:44 PM, "Peter Lei"  wrote:



On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).


[Apologies for broken quoting, currently mobile]

What happens if you patch this line out?
https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233

I'll have to go back and figure out what I was thinking here again. It made
sense when I wrote it, maybe explicitly disabling ACPI if it's not
immediately detected was the wrong move. =)
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
> 
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
> 
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script, it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:

>
>
> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> >
> > It seems that the Forth loader might be doing something sneaky and
> > replacing the standard common "boot" with a Forth boot that handles
> > this a lot better. CC'ing dteske@ so they can confirm.
>
> I can indeed confirm this as fact.
>
> Not able to help much because I am driving cross-country (San Francisco to
> Orlando) right now with the spouse and dog.
>
> We get back March 3rd, but I will be checking-in from time to time for
> sporadic responses during downtime.
>

The command in loader.4th is defined as:

: boot
  0= if ( interpreted ) get_arguments then

  \ Unload only if a path was passed
  dup if
>r over r> swap
c@ [char] - <> if
  0 1 unload drop
else
  s" kernelname" getenv? if ( a kernel has been loaded )
try-menu-unset
bootmsg 1 boot exit
  then
  load_kernel_and_modules
  ?dup if exit then
  try-menu-unset
  bootmsg 0 1 boot exit
then
  else
s" kernelname" getenv? if ( a kernel has been loaded )
  try-menu-unset
  bootmsg 1 boot exit
then
load_kernel_and_modules
?dup if exit then
try-menu-unset
bootmsg 0 1 boot exit
  then
  load_kernel_and_modules
  ?dup 0= if bootmsg 0 1 boot then
;

The thing to know here is when you see 'boot' as part of above script, it's
calling the 'boot' cli command, not itself recursively.

I can help do more interpretation of the details if you need Kyle. Not sure
how much to spell out, but the brief pseudo code is:

If there were any arguments that didn't start with '-', unload.
  otherwise if kernelname is in in the environment, run the 'menu-unset'
forth word if it exists, print the boot message and boot.
  Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if it exists), print the boot message and boot with kernelname
Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
it exists), print the boot message and boot with kernelname
if all that fails, load the kernel and modules and if that works boot them.

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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.




Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?


OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...


In fact, I don’t think this has ever worked here… I’ve found a very old 
(July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.




There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.


Thanks.



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.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.


I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U 
processor, 4GB RAM). The only thing I can think of is that the ACPI of 
this model is not well supported, but the errors I have are related to 
thermal zones…:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with 
ccache and WITH_META_MODE, but this build process has been working 
nicely for months.


The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of 
things to slim down the memstick, but still, it has been stable till now:


juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks setting locale and thus tmux
#WITHOUT_LOCALES=

Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> 
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.

I can indeed confirm this as fact.

Not able to help much because I am driving cross-country (San Francisco to 
Orlando) right now with the spouse and dog.

We get back March 3rd, but I will be checking-in from time to time for sporadic 
responses during downtime.
— 
Cheers,
Devin
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh  wrote:
>
>
> On Feb 19, 2018 1:23 PM, "Kyle Evans"  wrote:
>
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
>> previous
>> message:
>>
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?
>
>> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
>> keyboard only becomes responsive at the loader stage.
>
> Hmm...
>
>> There is an error during this stage:
>>
>> Loading /boot/defaults/loader.conf
>> Failed to open config: ’/boot/loader.conf.local’
>
> David's diagnosis of this is right- this is more of an informational
> message that you don't need to worry about.
>
>> 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.
>
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.
>
>
> Indeed, it does.
>
> Loader.4th defines boot. Search for ': boot' to see it.
>

I've created D14442 [1] to improve this situation a little bit. We
should also either:

1.) Provide a way for lua to register a function to handle a loader command, or
2.) Provide a way for lua/forth to tell the common boot what modules to load.

These both entail a good amount of work and quite a few places to
fail, but one of them needs to happen. =(

[1] https://reviews.freebsd.org/D14442
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 15:39, David Wolfskill a écrit :

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html


That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.


OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader:
the keyboard only becomes responsive at the loader stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)


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.


And the Lua loader permits kernel selection, as well (as the Forth
laoder has).


Finally, the double lines drawing a frame around the loader menu do not
work with the new loader and are replaced by ? characters in a box.


That has also been fixed for me (as of r329517).


Hope it helps,
Juan



Peace,
david


Thanks David. It’s strange I’m having issues resolved for you in commits 
older than the one I used here…


___
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: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 1:23 PM, "Kyle Evans"  wrote:

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> 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.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Indeed, it does.

Loader.4th defines boot. Search for ': boot' to see it.

Warner

> Finally, the double lines drawing a frame around the loader menu do not
work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> 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.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.

> Finally, the double lines drawing a frame around the loader menu do not work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
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: ACPI panic on boot with new Lua loader and other minor issues

[David Wolfskill]

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
> 
> Both the new and the old kernels panic after being loaded with:
> 
> panic: running without device atpic requires a local APIC
> 
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
> previous message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.

> OK show hint.acpi.0.disabled
> 1
> 
> Setting ACPI to On resolves the issue.
> 
> Also, I can not stop boot2 to try to use the copy of the Forth loader: 
> the keyboard only becomes responsive at the loader stage.

> There is an error during this stage:
> 
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)

> 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.

And the Lua loader permits kernel selection, as well (as the Forth
laoder has).

> Finally, the double lines drawing a frame around the loader menu do not 
> work with the new loader and are replaced by ? characters in a box.

That has also been fixed for me (as of r329517).

> Hope it helps,
> Juan
> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

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



I forgot that I tried starting with "unload", which seems to work, but 
does not correct the issue:


OK unload
OK boot kernel.old
Command failed
___
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"

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
previous message:

https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader: 
the keyboard only becomes responsive at the loader stage.


There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’

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.

Finally, the double lines drawing a frame around the loader menu do not 
work with the new loader and are replaced by ? characters in a box.


Hope it helps,
Juan
___
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"