On Fri, Jul 7, 2017 at 10:28 AM, Stewart Smith <stew...@linux.vnet.ibm.com> wrote: > Michael Ellerman <m...@ellerman.id.au> writes: >> Stewart Smith <stew...@linux.vnet.ibm.com> writes: >>> Oliver O'Halloran <ooh...@gmail.com> writes: >>>> diff --git a/arch/powerpc/include/asm/opal-api.h >>>> b/arch/powerpc/include/asm/opal-api.h >>>> index 0e2e57bcab50..cb9c0e6afb33 100644 >>>> --- a/arch/powerpc/include/asm/opal-api.h >>>> +++ b/arch/powerpc/include/asm/opal-api.h >>>> @@ -167,7 +167,8 @@ >>>> #define OPAL_INT_EOI 124 >>>> #define OPAL_INT_SET_MFRR 125 >>>> #define OPAL_PCI_TCE_KILL 126 >>>> -#define OPAL_LAST 126 >>>> +#define OPAL_SCRAPE_LOG 128 >>> >>> (another thought, along with the skiboot thoughts), I don't like the >>> SCRAPE_LOG name so much, as it's more of a "hey linux, here's some log >>> messages from firmware, possibly before you were >>> involved"... OPAL_FETCH_LOG ? >> >> I'm not a huge fan of an interrupt followed by an opal call just to >> fetch a single line of log. >> >> Can't we do something more like the existing msglog code, where we have >> a ring buffer and then the interrupt just becomes "hey Linux you should >> look at your ring buffer". > > Yeah... that would probably be a bit better... > > Although that would mean we can only ever tell the running kernel what's > in the ring buffer. We couldn't work out a way to (after kexec) resend > important bits of info such as "we garded things out, your OCC didn't > start and we trained everything at really slow speeds"
Isn't this is the use case for BMC based error logs? A ring buffer is fundamentally a structure for transient data. There's no real way to hack in permanence other than making sure that making sure it never fills.
