Re: keyboard doesn't work at Boot Menu

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 18 Jun 2023 03:08:01 UTC
On Jun 17, 2023, at 19:09, bob prohaska <fbsd@www.zefox.net> wrote:

> [apologies if I'm barging in]
> 
> Just for fun I tried rebooting my 8GB Pi4 running -current
> from the video console and USB keyboard (old Logitec). 
> 
> On reboot there was no beastie menu (maybe it was turned off)

You later show /boot/loader.conf as having:

beastie_disable="YES"

So: turned off.

> but the loader responded to the USB keyboard to allow boot to
> single user mode.

So you entered "boot -s" as a loader command?

> The HDMI output ended with
> ....
> Dual Console: Serial Primary, Video Secondary
> and after that the keyboard became unresponsive,

USB keyboard specifically (not serial console)?
Serial console?

Also, does "unresponsive" mean that neither the
serial console output nor the HDMI display showed
evidence of progress? Did you look in both places?

And which HDMI port was in use, the one nearer to
the USB3 power port?

> although the caps lock key still toggled the light.
> 
> Meanwhile the serial console reported:

Was there serial console output between the "Dual
Console" line and the below that you have not
reported?

> 
> Enter full pathname of shell or RETURN for /bin/sh:
> After hitting return,

USB keyboard specifically (not serial console)?
Serial console?

> it continued 
> Cannot read termcap database;
> using dumb terminal settings.
> Cannot read termcap database;
> using dumb terminal settings.
> 
> Issuing exit to the root shell on the serial
> console brought up a login prompt on the video
> console and it worked as normal. 
> 
> At this point /boot/msdos/config.txt contains
> [all]
> arm_64bit=1
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
> 
> [pi4]
> #hdmi_safe=1
> armstub=armstub8-gic.bin
> gpio=2,3=a0

Having hdmi_safe=1 commented out is not default
content but likely is very common to improve what
is displayed. An alernative is to have a separate,
later line that has "hdmi_safe=0" if you want the
first part of the file to match the default
content exactly.

The gpio line is not default content.

I'm not aware of any of this being a problem.

> which I think haven't been tampered with.
> 
> /boot/loader.conf contains
> # Configure USB OTG; see usb_template(4).
> hw.usb.template=3
> umodem_load="YES"
> # Multiple console (serial+efi gop) enabled.
> boot_multicons="YES"
> boot_serial="YES"
> # Disable the beastie menu and color
> beastie_disable="YES"
> loader_color="NO"
> filemon_load="YES"
> # net.inet.tcp.tolerate_missing_ts="1"
> #hw.usb.debug=1
> vm.pageout_oom_seq="4096"

Having a figure bigger than the default
vm.pageout_oom_seq=12 may well be
important. I've never needed more than
120.

> vm.pfault_oom_attempts="120"
> vm.pfault_oom_wait="20"

That is 20 seconds * 120 == 2400 seconds,
i.e., 40 minutes being allowed overall for
trying a specific page fault up to 120
times.

This seems oddly large. The defaults are:

vm.pfault_oom_attempts= 3
vm.pfault_oom_wait= 10

so 30 seconds overall for trying the
specific page fault up to 3 times.

> [likely the vm stuff is pointless]
> 
> If there's anything useful I can try please say so.
> 

I'll have to set up an experiment and try it
based on the recent snapshot of main.


===
Mark Millard
marklmi at yahoo.com