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 : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp