[Skiboot] [PATCH v3 06/13] hiomap: Enable Async IPMI messaging
Oliver O'Halloran
oohall at gmail.com
Mon Nov 25 17:59:10 AEDT 2019
On Thu, Nov 7, 2019 at 4:25 AM Deb McLemore <debmc at linux.ibm.com> wrote:
>
> +static int hiomap_wait_for_cc(struct ipmi_hiomap *ctx, int *cc, uint8_t *seq, uint64_t ticks)
> +{
> + uint64_t now;
> + uint64_t start_time;
> + uint64_t wait_time;
> + uint64_t ipmi_hiomap_ticks;
> + uint64_t timeout_counter;
> + int rc;
> +
> + prlog(PR_TRACE, "Start wait for cc ipmi seq=%i *cc=%i ticks=%llu\n", *seq, *cc, ticks);
> + rc = 0;
> + if (this_cpu()->tb_invalid) {
> + /*
> + * SYNC paths already have *cc success
> + * ASYNC will RE-QUEUE and retry
> + * we just need to skip the tb logic handling
> + * we need to close the window to have the logic try the move again
> + */
> + if (*cc != IPMI_CC_NO_ERROR) {
> + lock(&ctx->lock);
> + ctx->window_state = closed_window;
> + ++ctx->missed_cc_count;
> + prlog(PR_NOTICE, "%s tb_invalid, CLOSING WINDOW for cc "
> + "ipmi seq=%i ctx->missed_cc_count=%i\n",
> + __func__, *seq, ctx->missed_cc_count);
> + unlock(&ctx->lock);
> + rc = FLASH_ERR_MISSED_CC;
> + }
> + prlog(PR_NOTICE, "%s tb_invalid, hopefully this will "
> + "retry/recover rc=%i\n",
> + __func__, rc);
> + return rc;
> + }
Mahesh, what's the correct way to deal with the timebase going invalid
at runtime if we need to do a time_wait()? You added a hack in
1764f2452565 ("opal: Fix hang in time_wait* calls on HMI for TB
errors.") to no-op the timebase if tb_invalid is set so we don't get
stuck in the HMI recovery path, but I guess it breaks anything else
that needs a wait? I would prefer we didn't start open-coding
tb_invalid checks.
More information about the Skiboot
mailing list