OPAL flash ops are not asynchronous

[rlippert]

We have recently started testing OPAL flash writes from the host on Zaius and have seen issues with thread hangs, lost interrupts, IPMI timeouts, etc. while the flash write operation is in progress.

The opal_flash_{read,write,erase} calls seem to be async operations and require a token but the actual implementation does all of the work before returning an async completion. Thus the thread performing the op seems to be "stuck" in skiboot the whole time and does not return to the kernel until the operation is finished which can take multiple seconds in the worst case.

[cyrilbur-ibm]

Hi Rob, I've been working on a solution to this, the Skiboot side is under review here: http://patchwork.ozlabs.org/patch/781967/ Unfortunately Linux isn't perfect either, it was written with async in mind but there are problems, I have a series under review here: http://patchwork.ozlabs.org/patch/782067/ Good to know someone cares about the work I'm doing! Cyril On 30 Jun 2017 05:05, "Rob Lippert" <notifications@github.com> wrote: We have recently started testing OPAL flash writes from the host on Zaius and have seen issues with thread hangs, lost interrupts, IPMI timeouts, etc. while the flash write operation is in progress. The opal_flash_{read,write,erase} calls seem to be async operations and require a token but the actual implementation does all of the work before returning an async completion. Thus the thread performing the op seems to be "stuck" in skiboot the whole time and does not return to the kernel until the operation is finished which can take multiple seconds in the worst case. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#90>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHn16Zy2TGCdjv2rDQ6XUZsgqHm55czWks5sI_FVgaJpZM4OJt-N> .

[rlippert]

Thanks that does look like it will help.

Are you planning to make the read and write ops asynchronous as well?

[cyrilbur-ibm]

On Thu, 2017-06-29 at 23:07 +0000, Rob Lippert wrote: Thanks that does look like it will help. Are you planning to make the read and write ops asynchronous as well?

Yes and no, I'm going to send a v2 of Patch 4/4 based on Alistairs review, which might go down better and can easily do read and write. If we pursue doing it the way I've done it inside the blocklevel abstraction I'm afraid read/write aren't high on my list as none of our tools do read or writes that are long enough to calls problems (although `dd` definitely could), that's not to say I won't do it but I just don't have the cycles. Sounds like another argument for just doing it in core/flash... If I find your email on github I'll cc you the v2.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.