** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1736954
Title:
ppc64el: Do not call ibm,os-term on panic
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Artful:
Fix Committed
Status in linux source package in Bionic:
Fix Released
Bug description:
[Impact]
When panic_timeout is set, the user would expect the system to reboot.
However, it is shutdown, possibly requiring user intervention to power on the
system again. This may impact availability. This happens under certain versions
of qemu (2.10+) emulating pseries.
[Test Case]
Built kernels (trusty, xenial, zesty, artful) have been tested and they
reboot after the fix, when running under an affected qemu.
[Regression Potential]
fadump might require that RTAS ibm,os-term be called. The fix should still
allow it to be called when fadump is registered.
-----------
When panic_timeout is set, the user would expect that the system would
reboot after some timeout after a panic.
However, on powerpc architecture, a panic notifier may not ever return
and even shutdown the system. The main example that impacts platforms
we support is pseries calling RTAS ibm,os-term.
That panic notifier and calling RTAS ibm,os-term is useful for fadump,
so this should not be impacted.
The Linux code has changed back and forth on considering the
panic_timeout setting and checking whether ibm,extended-os-term was
available. Unfortunately, recent changes on qemu led to the guest
being shut down when calling ibm,os-term even when ibm,extended-os-
term was available.
Luckily, upstream Linux already has the change that does not call ibm
,os-term on panic, but only during fadump. So, we can use that commit
for fixing this. Changing qemu itself is harder as: 1) qemu community
already decided some qemu settings should override PAPR; 2) updating
deployed hypervisor is harder than updating our guest kernels.
Cascardo.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1736954/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
