Re: keyboard doesn't work at Boot Menu
- Reply: Mark Millard : "Re: keyboard doesn't work at Boot Menu"
- In reply to: bob prohaska : "Re: keyboard doesn't work at Boot Menu"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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