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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1929923
Title:
[UBUNTU 20.04] LPAR becomes unresponsive after the Kernel panic -
rq_qos_wake_function
Status in Ubuntu on IBM z Systems:
Incomplete
Status in linux package in Ubuntu:
New
Bug description:
---Problem Description---
kernel panic rq_qos_wake_function
---uname output---
Linux version 5.4.0-71-generic
Machine Type = s390x
---Debugger---
A debugger is not configured
Stack trace output:
May 15 20:21:04 data1 kernel: Call Trace:
May 15 20:21:04 data1 kernel: ([<000000234091e670>] 0x234091e670)
May 15 20:21:04 data1 kernel: [<0000003e10047e3a>]
rq_qos_wake_function+0x8a/0xa0
May 15 20:21:04 data1 kernel: [<0000003e0fbec482>]
__wake_up_common+0xa2/0x1b0
May 15 20:21:04 data1 kernel: [<0000003e0fbec984>]
__wake_up_common_lock+0x94/0xe0
May 15 20:21:04 data1 kernel: [<0000003e0fbec9fa>] __wake_up+0x2a/0x40
May 15 20:21:04 data1 kernel: [<0000003e1005ee70>] wbt_done+0x90/0xe0
May 15 20:21:04 data1 kernel: [<0000003e10047f42>] __rq_qos_done+0x42/0x60
May 15 20:21:04 data1 kernel: [<0000003e10033cb0>]
blk_mq_free_request+0xe0/0x140
May 15 20:21:04 data1 kernel: [<0000003e101d46f0>]
dm_softirq_done+0x140/0x230
May 15 20:21:04 data1 kernel: [<0000003e100326c0>]
blk_done_softirq+0xc0/0xe0
May 15 20:21:04 data1 kernel: [<0000003e103fc084>] __do_softirq+0x104/0x360
May 15 20:21:04 data1 kernel: [<0000003e0fb9da1e>] irq_exit+0x9e/0xc0
May 15 20:21:04 data1 kernel: [<0000003e0fb28ae8>] do_IRQ+0x78/0xb0
May 15 20:21:04 data1 kernel: [<0000003e103fb588>]
ext_int_handler+0x130/0x134
May 15 20:21:04 data1 kernel: [<0000003e101d4416>] dm_mq_queue_rq+0x36/0x1d0
May 15 20:21:04 data1 kernel: Last Breaking-Event-Address:
May 15 20:21:04 data1 kernel: [<0000003e0fbce75e>] wake_up_process+0xe/0x20
May 15 20:21:04 data1 kernel: Kernel panic - not syncing: Fatal exception in
interrupt
Oops output:
no
System Dump Info:
The system was configured to capture a dump, however a dump was not
produced.
-Attach sysctl -a output output to the bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929923/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp