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

Reply via email to