Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hostboot not respecting BT capabilities #57

Closed
ghost opened this issue May 20, 2016 · 3 comments
Closed

Hostboot not respecting BT capabilities #57

ghost opened this issue May 20, 2016 · 3 comments

Comments

@ghost
Copy link

ghost commented May 20, 2016

According to @rjknight , Hostboot has hardcoded values for BT capabilities rather than interrogating the BMC and acting accordingly within those capabilities.
@williamspatrick
Copy link

The capability that is hard-coded is the number of outstanding (parallel) IPMI commands.

The origin of this is buggy AMI code that lies to us. This code is "in the wild" and it is impossible for us to identify truthful and untruthful BMCs.

The side effect of this is a [arguably] slightly slower boot. Considering the risk of breaking machines with existing untruthful BMC code, I do not see the benefit of removing this for P8 machines.

Can you give a rationale on why this should be fixed in the near term?

@ghost
Copy link
Author

ghost commented May 23, 2016

We hardcode the outstanding requests for the same reason in skiboot (and as a bonus, it makes the code much simpler).

If HB takes the queue sizes from the capabilities, then we should likely just close this issue.

@dcrowell77
Copy link
Collaborator

If we got really motivated we could add a config flag to either ignore or believe the call so that partners could theoretically improve things if they know their BMC is trustworthy, but this doesn't seem worth the effort at this time.

wghoffa pushed a commit that referenced this issue Dec 1, 2017
@crgeddes @dcrowell77
Remove limit on max size of PNOR TOC
6bc72e2 
Previously we assumed the TOC would never be larger than 4kb, this
limited us to <31 sections in pnor. We are getting to the point that is
not enough. To satify the github issue a change was needed in the ffs
tool to correctly build the TOC so it describes its size correctly.
Those changes can be found here: github.com/open-power/ffs/pull/14
The changes in this commit fix hostboot so that it will correctly
parse TOCs > 4kb. Resolves open-power/zaius-openpower/#57.


Change-Id: Id2d8c250b0b1e6b87adfd4d927119fe006e8910d
RTC: 180032
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/49926
Reviewed-by: Matt Derksen <mderkse1@us.ibm.com>
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Reviewed-by: Martin Gloff <mgloff@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@williamspatrick @dcrowell77