Message ID | 20140723092236.4740.33763.stgit@hegdevasant.in.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Headers | show |
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes: > We can continue to read the error log (up to MAX size) even if > we get the elog size more than MAX size. Hence change BUG_ON to > WARN_ON. > > Also updated error message. > > Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com> > Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> > Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> > Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com> So, it turns out the BUG_ON actually caught an FSP bug, at the very least in their documentation. The WARN_ON is probably the best thing we can do, along with the OPAL/skiboot side fixes that I've mentioned separately. Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c index 10268c4..0ad533b 100644 --- a/arch/powerpc/platforms/powernv/opal-elog.c +++ b/arch/powerpc/platforms/powernv/opal-elog.c @@ -249,7 +249,7 @@ static void elog_work_fn(struct work_struct *work) rc = opal_get_elog_size(&id, &size, &type); if (rc != OPAL_SUCCESS) { - pr_err("ELOG: Opal log read failed\n"); + pr_err("ELOG: OPAL log info read failed\n"); return; } @@ -257,7 +257,7 @@ static void elog_work_fn(struct work_struct *work) log_id = be64_to_cpu(id); elog_type = be64_to_cpu(type); - BUG_ON(elog_size > OPAL_MAX_ERRLOG_SIZE); + WARN_ON(elog_size > OPAL_MAX_ERRLOG_SIZE); if (elog_size >= OPAL_MAX_ERRLOG_SIZE) elog_size = OPAL_MAX_ERRLOG_SIZE;