From: Michael Richardson <mcr@sandelman.ca>
To: Andrew Geissler <geissonator@gmail.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: preventing chassis power-on until bmc Ready
Date: Wed, 20 Apr 2022 14:37:02 -0400 [thread overview]
Message-ID: <820955.1650479822@dooku> (raw)
In-Reply-To: <FE2B7C36-070C-4DCF-84C0-FB3A53EC0837@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
Andrew Geissler <geissonator@gmail.com> wrote:
> I know in the past I've heard of servers that allow both the BMC and
> Host to boot in parallel (which sounds awesome) but we're not there
> yet.
That would really be awesome... server boot times have become ridiculous,
with the time amount of Black Screen (BMC boot time I think) time seeming to
be increasing...
I think that Dell had to tweak some things a decade ago when people started
putting multiple hundred Gb of ram in; I have old servers that take 10+
minutes to POST.
I do wonder if, as you say, the whack-a-mole should continue, or if the host
should just be able to inquire (and wait) for the BMC to finish booting.
So, don't prevent the host from booting, but allow the host to synchronize
with the BMC before it continues.
That would be in the BIOS, and perhaps could even be a prototyped as a (host) grub module.
It seems like there is a lot of mechanism in the BMC that affects the host
booting. (Like virtual USB bootable media)
It would also be very very annoying if one never could get boot console
capture after a cold boot, but only after a warm boot.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
prev parent reply other threads:[~2022-04-20 18:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 21:02 preventing chassis power-on until bmc Ready Andrew Geissler
2022-04-19 21:30 ` William Kennington
2022-05-13 13:19 ` Andrew Geissler
2022-04-20 18:37 ` Michael Richardson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=820955.1650479822@dooku \
--to=mcr@sandelman.ca \
--cc=geissonator@gmail.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.