On 1 July 2016 at 17:46, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Fri, Jul 01, 2016 at 05:31:33PM +0200, Ard Biesheuvel wrote: >> On 1 July 2016 at 17:22, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> > On Fri, Jul 01, 2016 at 05:01:30PM +0200, Ard Biesheuvel wrote: >> >> It is the firmware's job to clear any pending SErrors before entering >> >> the kernel. On UEFI, we can fail gracefully rather than panic during >> >> early boot, so check for this condition in the stub. >> >> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> >> > >> > An SError could be triggered either asynchronously by FW, or as a result >> > of our actions at any point after this, e.g. due to the filesystem >> > accesses made to load an initrd. >> > >> > So in practice, is checking here useful? Have we seen FW with masked but >> > pending SError at the point we enter the stub rather than that SError >> > being triggered later,? >> >> Yes. EDK2 keeps SError masked throughout its execution by default, and >> so any condition that triggered an SError up till this point is likely >> to still be pending, and blow up the kernel as soon as it unmasks it. > > Ok. > >> > I'm also not sure what this means for CPER, which may use SError to >> > signal to the OS. It's possible that the UEFI implementation polls >> > ISR_EL1 itself, and handles SError appropriately internally, or that the >> > OS can later deal with the SError based on CPER and friends. >> >> Currently, the kernel panics on an SError, and so what the kernel >> should do once we start dealing with them in a more sophisticated way >> is hypothetical at the moment. Once that code arrives, it may revert >> this change, but for now, being dropped back into the UEFI shell does >> sound more appealing than panic early imo. > > Logging something while the UART is available is certainly appealing. > Not just the UART, the graphical console as well, if the system has one. > As you say, we can change this later if/when we have more advanced > SError handling. So modulo my prior comments, I guess this is fine for > now. > OK, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
