Well, as already mentioned in the two comments before more details are
needed:
If a system is not on the latest kernel level, but shows kernel issues, it is
first of all needed to update the system to the latest kernel level and try to
recreate the issue there.
So I agree with Pedro that this needs to be verified on (currently) latest
5.4.0.73, since especially 5.4.0.73 includes hundreds of upstream stable
patches because it includes the range from v5.4.102 to .106.
Testing on 5.4.0-74 (currently in proposed) would be the next crucial
step, since it incl. even more upstream stable patches ranging from
v5.4.107 to .114 - again hundreds of patches.
This is needed to be sure that we don't hunt a bug that may already have
been fixed.
If the issue is re-produceable on these kernel levels, wee need more details on
the environment:
- which IBM Z or LinuxONE system is in use
- which storage backend is attached and used?
- is zFCP/SCSI used or DASDs?
- and what is the dump device and how did it got configured?
(again detailed steps to re-produce, like Andrew asked for)
** Changed in: ubuntu-z-systems
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929923
Title:
[UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic -
rq_qos_wake_function
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929923/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
