Re: Third server now locked up after reboot due to no keyboard attached
On 2019-12-15 18:25:33 Nick Holland wrote: > If the boot loader echoed anything, it's behaving As Desired Actually, one of my machines that hangs on boot> doesn't echo anything. > a char at the command line means "STOP ALL BOOTING I wonder if a filter can be applied to the input e.g. Ignore all non-printable input. I am curious as to why the one server that doesn't echo anything is stopping on boot> prompt. Can anyone give me pointers to modifying the boot code to show what character code is stopping the boot? > BIOS upgrade. Long shot, but maybe? The one server that is echoing is updated to the latest bios. The other one that is not echoing is not and has an interesting BIOS update description of "Improve USB compatibility" so I'm going to have to try that. > BIOS config option I've tried several bios config options. No change. > a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf A great suggestion. I had "boot bsd" in my boot.conf from someone recommending this to me but then I ran into trouble when I did a sysupgrade and then it didn't come back since I think the reboot failed to get to boot bsd.upgrade and bsd kernel wasn't ready to boot yet. "boot" in the boot.conf sounds like this would fix my problem and sysupgrade problem. On 2019-12-16 18:02:19 Andrew Daugherity wrote: > If you have console redirection configured in the BIOS I don't. I am using the standard terminal. > Note that this is not yet implemented in the UEFI bootloader Ctrl key would be nice. I am using UEFI boot. -alfred
Re: Third server now locked up after reboot due to no keyboard attached
On Sun, Dec 15, 2019 at 12:28 PM Nick Holland wrote: > > Well...yeah. > If the boot loader echoed anything, it's behaving As Desired -- a char at > the command line means "STOP ALL BOOTING, I have something special I want > you to do". > > [...] > However, I think there are a few things you might be able to do to solve > your problem... > > 1) BIOS upgrade. Long shot, but maybe? > 2) BIOS config option? Also a long shot, but since I'd call this a > boot firmware bug, maybe some combination of USB related options would > fix this? Always a good idea. If you have console redirection configured in the BIOS, make sure redirection after boot is *disabled*, and configure the serial console in the bootloader instead. I've seen garbage characters produced by the BIOS console on some systems, but the OS and bootloader usually work better. > 3) a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf > should override anything in the keyboard buffer. Need to "control" the > boot? plug in a keyboard and hold down either CTRL key, and you will be > given the boot> prompt. Note that this is not yet implemented in the UEFI bootloader: https://github.com/openbsd/src/blob/43e343f8aa17502e68dbb74fa3dd463280c74fe5/sys/arch/amd64/stand/efi64/efiboot.c#L514-L519 (Compare pc_getshifts() in .../libsa/bioscons.c, which calls BIOS interrupts. Anyone know the UEFI equivalent?) -Andrew
Re: Third server now locked up after reboot due to no keyboard attached
On 2019-12-14 14:28, Alfred Morgan wrote: > I have now another machine running OpenBSD not recover from a reboot. I > thought I was having hardware issues with my two other servers (both zbox) > and now this third one (Dell) with totally different hardware is having the > same problem getting stuck at the boot> prompt. The problem goes away and > boots continue normally if I attach a USB keyboard in all three cases. I > feel like this problem started showing up around OpenBSD 6.4. Is this a > known issue? certainly not a universal issue...(i.e., I haven't experienced it) > When there is no keyboard attached the boot> prompt shows a box with a > question mark in it looking like an unknown character. Picture showing this > on bootx64 3.46: > https://photos.app.goo.gl/7HAqQic6GArLGzaXA Well...yeah. If the boot loader echoed anything, it's behaving As Desired -- a char at the command line means "STOP ALL BOOTING, I have something special I want you to do". The boot loader is entirely depenedent upon the firmware (BIOS), the kernel isn't loaded, OpenBSD isn't running. There's not a lot that OpenBSD can do about this -- the boot loader could "eat" all chars sitting in the buffer, but that would make interrupting the boot process just a little more difficult when you DO want to stop it. However, I think there are a few things you might be able to do to solve your problem... 1) BIOS upgrade. Long shot, but maybe? 2) BIOS config option? Also a long shot, but since I'd call this a boot firmware bug, maybe some combination of USB related options would fix this? 3) a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf should override anything in the keyboard buffer. Need to "control" the boot? plug in a keyboard and hold down either CTRL key, and you will be given the boot> prompt. Nick. > Here is the dmesg from my latest Dell server: > > OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019 > r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > GENERIC.MP > real mem = 8487182336 (8094MB) > avail mem = 8217251840 (7836MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (71 entries) > bios0: vendor Dell Inc. version "A02" date 11/14/2014 > bios0: Dell Inc. OptiPlex 3020M ...
Third server now locked up after reboot due to no keyboard attached
I have now another machine running OpenBSD not recover from a reboot. I thought I was having hardware issues with my two other servers (both zbox) and now this third one (Dell) with totally different hardware is having the same problem getting stuck at the boot> prompt. The problem goes away and boots continue normally if I attach a USB keyboard in all three cases. I feel like this problem started showing up around OpenBSD 6.4. Is this a known issue? When there is no keyboard attached the boot> prompt shows a box with a question mark in it looking like an unknown character. Picture showing this on bootx64 3.46: https://photos.app.goo.gl/7HAqQic6GArLGzaXA Here is the dmesg from my latest Dell server: OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 8487182336 (8094MB) avail mem = 8217251840 (7836MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (71 entries) bios0: vendor Dell Inc. version "A02" date 11/14/2014 bios0: Dell Inc. OptiPlex 3020M acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC SSDT SSDT SSDT HPET SSDT MCFG SSDT MSDM BGRT acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.45 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.08 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.07 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4150T CPU @ 3.00GHz, 2993.07 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP03) acpiprt3 at acpi0: bus 3 (RP04) acpiprt4 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0:
