Theo wrote: > Interesting. Wonder how common this is. It could possibly come back in some future bios update bug/change as well but very very rarely I would expect. This problem showed up for me in a different way as well; My clock would always drift and ntpd would report that it was always trying to adjust the clock but would never get closer to the target time. Now I can explain why since my bios clock was stuck.
> Should our code eventually advance if it has done millions of inspection loops? I saw code in there in /usr/src/sys/stand/boot/cmd.c that counted 1000 before calling getsecs() so I would weary about adding more counts: /* check for timeout expiration less often (for some very constrained archs) */ while (!cnischar()) if (!(i++ % 1000) && (getsecs() >= tt)) break; I don't know the amd64 architecture too well but I would think there would be a more reliable timer that can be used instead of the system clock. Only relative time is needed for the timeout to operate correctly. Or possibly use some known tick. http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch10lev1sec2.html > If you can re-create the condition, can you propose a diff which does that? I would if I can get someone to point me to a good timer or tick to use. -alfred On Wed, Jul 15, 2020 at 9:43 PM Theo de Raadt <dera...@openbsd.org> wrote: > Alfred Morgan <alf...@54.org> wrote: > > > Theo wrote: > > > Figure out how to build and install. It is not hard to test. > > > > Thank you, I did as you suggested and I was able to narrow down the issue > > to this line of code in /usr/src/sys/arch/amd64/stand/efiboot/efiboot.c: > > > > EFI_CALL(ST->RuntimeServices->GetTime, &t, NULL); > > > > > > The GetTime call would always return the same time. It turned out that my > > BIOS clock was frozen and was not ticking so the boot prompt was waiting > > for a time that never arrived. > > > > I learned a lot about OpenBSD efiboot and a good BIOS lesson. Always use > > the clear CMOS hardware jumper after a BIOS update. I have been using the > > "Load defaults" in the BIOS after a BIOS update but that is not good > enough. > > > > Thanks again Theo for your direction and encouragement. > > Interesting. Wonder how common this is. > > Should our code eventually advance if it has done millions of inspection > loops? If you can re-create the condition, can you propose a diff which > does that? >
