Panic on Boot - Current AMD64

[Manfred Antar]

I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018
***@pozo.com:/usr/src/sys/amd64/compile/pozo amd64
FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)
Table 'FACP' at 0xdfbc57e8
Table 'APIC' at 0xdfbc585c
Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943
Table 'TCPA' at 0xdfbc597f
Table 'SLIC' at 0xdfbc59b1
Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff820bc820
vpanic() at vpanic+0x18d/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0xffffffff80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0xffffffff820bc820
vpanic() at vpanic+0x1aa/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
db>

[Juan Ramón Molina Menor]

Post by Manfred Antar
I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018
root at pozo.com
<https://lists.freebsd.org/mailman/listinfo/freebsd-current>:/usr/src/sys/amd64/compile/pozo amd64
FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)
Table 'FACP' at 0xdfbc57e8
Table 'APIC' at 0xdfbc585c
Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943
Table 'TCPA' at 0xdfbc597f
Table 'SLIC' at 0xdfbc59b1
Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff820bc820
vpanic() at vpanic+0x18d/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0xffffffff80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0xffffffff820bc820
vpanic() at vpanic+0x1aa/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
db>

Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440
with 4 GB.

Workaround: break into the loader prompt and:

set vm.boot_pages=120
boot

When booting kernel.old, vm.boot_pages is 64.

There is something wrong with r328916.

Hope it helps,
Juan

[Juan Ramón Molina Menor]

Post by Juan Ramón Molina Menor

Post by Manfred Antar
I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018
root at pozo.com
<https://lists.freebsd.org/mailman/listinfo/freebsd-current>:/usr/src/sys/amd64/compile/pozo amd64
FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)
Table 'FACP' at 0xdfbc57e8
Table 'APIC' at 0xdfbc585c
Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943
Table 'TCPA' at 0xdfbc597f
Table 'SLIC' at 0xdfbc59b1
Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff820bc820
vpanic() at vpanic+0x18d/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0xffffffff80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0xffffffff820bc820
vpanic() at vpanic+0x1aa/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
db>

Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440
with 4 GB.
set vm.boot_pages=120
boot
When booting kernel.old, vm.boot_pages is 64.
There is something wrong with r328916.
Hope it helps,
Juan

Hi!

Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the
issue here.

Hope it helps,
Juan

[M&S - Krasznai András]

Hi

yesterday I experienced the problem, but after completely synchronizing the src tree (deleting the content of the /usr/src folder and svnlite checkout etc.) and recompiling the kernel I can boot my FreeBSD-CURRENT (12.0, amd64, r328967) with the default setting (64) for vm.boot_pages.

rgds
András Krasznai



-----Eredeti üzenet-----
Feladó: owner-freebsd-***@freebsd.org [mailto:owner-freebsd-***@freebsd.org] Meghatalmazó Juan Ramón Molina Menor
Küldve: 2018. február 7. 12:18
Címzett: freebsd-***@freebsd.org
Másolatot kap: ***@gmail.com; ***@freebsd.org
Tárgy: Panic on Boot - Current AMD64

Post by Juan Ramón Molina Menor

Post by Manfred Antar
I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb 6 11:30:57 PST 2018
root at pozo.com
<https://lists.freebsd.org/mailman/listinfo/freebsd-current>:/usr/src
/sys/amd64/compile/pozo amd64 FreeBSD clang version 6.0.0
(branches/release_60 324090) (based on LLVM 6.0.0) Table 'FACP' at
0xdfbc57e8 Table 'APIC' at 0xdfbc585c Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943 Table 'TCPA' at 0xdfbc597f Table 'SLIC' at
0xdfbc59b1 Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xffffffff820bc820
vpanic() at vpanic+0x18d/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0xffffffff80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0xffffffff820bc820
vpanic() at vpanic+0x1aa/frame 0xffffffff820bc880
panic() at panic+0x43/frame 0xffffffff820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0xffffffff820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0xffffffff820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0xffffffff820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0xffffffff820bca50
zone_import() at zone_import+0x5a/frame 0xffffffff820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0xffffffff820bcae0
uma_startup() at uma_startup+0x3d3/frame 0xffffffff820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0xffffffff820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0xffffffff820bcc50
mi_startup() at mi_startup+0x118/frame 0xffffffff820bcc70
btext() at btext+0x2c
db>

Same panic here with HEAD from this afternoon in a Lenovo ThinkPad
S440 with 4 GB.
set vm.boot_pages=120
boot
When booting kernel.old, vm.boot_pages is 64.
There is something wrong with r328916.
Hope it helps,
Juan

Hi!

Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the issue here.

Hope it helps,
Juan
_______________________________________________
freebsd-***@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

[Gleb Smirnoff]

On Wed, Feb 07, 2018 at 12:18:26PM +0100, Juan Ramón Molina Menor wrote:
J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440
J> > with 4 GB.
J> >
J> > Workaround: break into the loader prompt and:
J> >
J> > set vm.boot_pages=120
J> > boot
J> >
J> > When booting kernel.old, vm.boot_pages is 64.
J> >
J> > There is something wrong with r328916.
J>
J> Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the
J> issue here.

r328982 should fix the boot without specifing vm.boot_pages.

I'm sorry for problems.

[Juan Ramón Molina Menor]

Post by Gleb Smirnoff
J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440
J> > with 4 GB.
J> >
J> >
J> > set vm.boot_pages=120
J> > boot
J> >
J> > When booting kernel.old, vm.boot_pages is 64.
J> >
J> > There is something wrong with r328916.
J>
J> issue here.
r328982 should fix the boot without specifing vm.boot_pages.
I'm sorry for problems.
--
Gleb Smirnoff

Yes, it is fixed, thanks!

[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

[David Wolfskill]

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a
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.

Post by Juan Ramón Molina Menor
OK show hint.acpi.0.disabled
1
Setting ACPI to On resolves the issue.
the keyboard only becomes responsive at the loader 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.)

Post by Juan Ramón Molina Menor
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).

Post by Juan Ramón Molina Menor
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).

Post by Juan Ramón Molina Menor
Hope it helps,
Juan
....

Peace,
david

[Juan Ramón Molina Menor]

Post by David Wolfskill

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a
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.

Post by Juan Ramón Molina Menor
OK show hint.acpi.0.disabled
1
Setting ACPI to On resolves the issue.
the keyboard only becomes responsive at the loader 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.)

Post by Juan Ramón Molina Menor
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).

Post by Juan Ramón Molina Menor
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).

Post by Juan Ramón Molina Menor
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…

[Kyle Evans]

Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
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?

Post by Juan Ramón Molina Menor
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...

Post by Juan Ramón Molina Menor
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.

Post by Juan Ramón Molina Menor
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

Post by Juan Ramón Molina Menor
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.

[Warner Losh]

On Feb 19, 2018 1:23 PM, "Kyle Evans" <***@freebsd.org> wrote:

Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
https://lists.freebsd.org/pipermail/freebsd-current/

2018-February/068497.html

Post by Juan Ramón Molina Menor
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?

Post by Juan Ramón Molina Menor
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...

Post by Juan Ramón Molina Menor
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.

Post by Juan Ramón Molina Menor
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

Post by Juan Ramón Molina Menor
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-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

[Kyle Evans]

Post by Kyle Evans
Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
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?

Post by Juan Ramón Molina Menor
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...

Post by Juan Ramón Molina Menor
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.

Post by Juan Ramón Molina Menor
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
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

[Devin Teske]

Post by Kyle Evans
It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles

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

[Warner Losh]

Post by Devin Teske

Post by Kyle Evans
It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles

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

Post by Devin Teske
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

[Kyle Evans]

Post by Warner Losh

Post by Devin Teske

Post by Kyle Evans
It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles

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.

: boot
0= if ( interpreted ) get_arguments then
\ Unload only if a path was passed
dup if

Post by Devin Teske
r over r> swap

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

[Warner Losh]

Post by Warner Losh

Post by Devin Teske

Post by Kyle Evans
It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles

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.

: boot
0= if ( interpreted ) get_arguments then
\ Unload only if a path was passed
dup if

Post by Devin Teske
r over r> swap

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

[Devin Teske]

Post by Warner Losh

Post by Devin Teske

Post by Kyle Evans
It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles

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.

: boot
0= if ( interpreted ) get_arguments then
\ Unload only if a path was passed
dup if

Post by Devin Teske
r over r> swap

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

[Juan Ramón Molina Menor]

Post by Kyle Evans
Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
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.

Post by Kyle Evans
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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

Post by Juan Ramón Molina Menor
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:

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

ident MEMSTICK

nodevice fdc

nodevice ch
nodevice sa
nodevice ses

nodevice amr
nodevice arcmsr
nodevice ciss
nodevice dpt
nodevice hptmv
nodevice hptnr
nodevice hptrr
nodevice hpt27xx
nodevice iir
nodevice ips
nodevice mly
nodevice twa
nodevice tws

nodevice aac
nodevice aacp
nodevice aacraid
nodevice ida
nodevice mfi
nodevice mlx
nodevice mrsas
nodevice pmspcv
nodevice twe

nodevice nvme
nodevice nvd

nodevice virtio
nodevice virtio_pci
nodevice vtnet
nodevice virtio_blk
nodevice virtio_scsi
nodevice virtio_balloon

nooptions HYPERV
nodevice hyperv

nooptions XENHVM
nodevice xenpci

nodevice vmx


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:

***@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=
WITHOUT_MAIL=
WITHOUT_NETCAT=
WITHOUT_PC_SYSINSTALL=
WITHOUT_PF=
WITHOUT_PORTSNAP=
WITHOUT_PPP=
WITHOUT_PROFILE=
WITHOUT_QUOTAS=
WITHOUT_RADIUS_SUPPORT=
WITHOUT_RBOOTD=
WITHOUT_RCS=
WITHOUT_SHAREDOCS=
WITH_SVN=
WITHOUT_SYSCONS=
WITHOUT_TALK=
WITHOUT_TCP_WRAPPERS=
WITHOUT_TELNET=
WITHOUT_TESTS=
WITHOUT_TFPT=
WITHOUT_TIMED=
WITHOUT_UNBOUND=
WITHOUT_UTMPX=
WITHOUT_ZFS=
WITHOUT_ZONEINFO=


Thanks for your attention.
Juan

[Peter Lei]

Post by Kyle Evans
Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
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).

[Kyle Evans]

Post by Kyle Evans
Hello!

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
https://lists.freebsd.org/pipermail/freebsd-current/

2018-February/068497.html

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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. =)

[Peter Lei]

Post by Juan Ramón Molina Menor

Post by Kyle Evans
Hello!
On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in

a previous
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
<https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html>

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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
    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.

Post by Juan Ramón Molina Menor
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. =)

[Kyle Evans]

Post by Peter Lei

Post by Juan Ramón Molina Menor

Post by Kyle Evans
Hello!
On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in

a previous
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
<https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html>

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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
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.

[Juan Ramón Molina Menor]

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

Post by Kyle Evans

Post by Juan Ramón Molina Menor
I have done a full build of r329555 to test the new Lua boot loader.
panic: running without device atpic requires a local APIC
For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
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.

Post by Kyle Evans
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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.

Post by Kyle Evans

Post by Juan Ramón Molina Menor
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

Post by Juan Ramón Molina Menor
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.

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.
include GENERIC-NODEBUG
ident MEMSTICK
nodevice fdc
nodevice ch
nodevice sa
nodevice ses
nodevice amr
nodevice arcmsr
nodevice ciss
nodevice dpt
nodevice hptmv
nodevice hptnr
nodevice hptrr
nodevice hpt27xx
nodevice iir
nodevice ips
nodevice mly
nodevice twa
nodevice tws
nodevice aac
nodevice aacp
nodevice aacraid
nodevice ida
nodevice mfi
nodevice mlx
nodevice mrsas
nodevice pmspcv
nodevice twe
nodevice nvme
nodevice nvd
nodevice virtio
nodevice virtio_pci
nodevice vtnet
nodevice virtio_blk
nodevice virtio_scsi
nodevice virtio_balloon
nooptions HYPERV
nodevice hyperv
nooptions XENHVM
nodevice xenpci
nodevice vmx
# 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=
WITHOUT_MAIL=
WITHOUT_NETCAT=
WITHOUT_PC_SYSINSTALL=
WITHOUT_PF=
WITHOUT_PORTSNAP=
WITHOUT_PPP=
WITHOUT_PROFILE=
WITHOUT_QUOTAS=
WITHOUT_RADIUS_SUPPORT=
WITHOUT_RBOOTD=
WITHOUT_RCS=
WITHOUT_SHAREDOCS=
WITH_SVN=
WITHOUT_SYSCONS=
WITHOUT_TALK=
WITHOUT_TCP_WRAPPERS=
WITHOUT_TELNET=
WITHOUT_TESTS=
WITHOUT_TFPT=
WITHOUT_TIMED=
WITHOUT_UNBOUND=
WITHOUT_UTMPX=
WITHOUT_ZFS=
WITHOUT_ZONEINFO=
Thanks for your attention.
Juan

Hi!

Updated today to r239641 and indeed the ACPI issue is gone.

Drawing chars in the loader are still missing. I guess it is related to
a difference I forgot to explain in my previous message: the Forth
loader used a higher resolution (lots of space around the logo and
menu), while the Lua one is using a lower one and occupies the whole screen.

Hope it helps,
Juan

[Juan Ramón Molina Menor]

Kyle,
I've moved to Lua loader to help testing and it worked fine. The only
odd thing I noted is the menu box with odd chars as you can see at [1].
My laptop is running a recent current (r330275) with ZFS and UEFI.
[1] https://imgur.com/a/kIQ0O
--
Renato Botelho

Hi,
Thanks for testing! =) Can you give it a shot with EFI boot after
r330281 (just committed), please?
I think our working theory is that we were printing newlines along
with our box-drawing characters, and that could be problematic. The
new version handles all of that a little better and respects
loader_menu_frame to boot.

Hi!

The drawing issue was still there after updating to r330281, but pushing
it up to r330287 has solved it.

Thanks!

[Kyle Evans]

[... snip ...]
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

[Juan Ramón Molina Menor]

Post by Kyle Evans

[... snip ...]
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.

[Kyle Evans]

Post by Juan Ramón Molina Menor

Post by Kyle Evans

[... snip ...]
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
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.

Post by Juan Ramón Molina Menor
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)

[Warner Losh]

Post by Kyle Evans

Post by Juan Ramón Molina Menor

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

[... snip ...]
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
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

Post by Juan Ramón Molina Menor
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.

Post by Juan Ramón Molina Menor
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

Post by Juan Ramón Molina Menor
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

[Kyle Evans]

Post by Kyle Evans

Post by Juan Ramón Molina Menor

Post by Kyle Evans
On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor

[... snip ...]
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
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.

Post by Juan Ramón Molina Menor
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
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.

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

[Juan Ramón Molina Menor]

Post by Juan Ramón Molina Menor
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

[Rodney W. Grimes]

Post by Juan Ramón Molina Menor

Post by Kyle Evans

[... snip ...]
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
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.

Post by Juan Ramón Molina Menor
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.