Description of problem:

In RHEL 8 the hrtimer_cpu_base struct now contains 8 hrtimer_clock_base ‘s and crash timer cmd does not account for them. It needs to be updated.


Crash version:
Crash 7.3.1++
GNU gdb (GDB) 7.6

crash> hrtimer_cpu_base
struct hrtimer_cpu_base {
    raw_spinlock_t lock;
    unsigned int cpu;
    unsigned int active_bases;
    unsigned int clock_was_set_seq;
    unsigned int hres_active : 1;
    unsigned int in_hrtirq : 1;
    unsigned int hang_detected : 1;
    unsigned int softirq_activated : 1;
    unsigned int nr_events;
    unsigned short nr_retries;
    unsigned short nr_hangs;
    unsigned int max_hang_time;
    spinlock_t softirq_expiry_lock;
    atomic_t timer_waiters;
    ktime_t expires_next;
    struct hrtimer *next_timer;
    ktime_t softirq_expires_next;
    struct hrtimer *softirq_next_timer;
    struct hrtimer_clock_base clock_base[8];   <----
}
SIZE: 0x480
crash> 


Version-Release number of selected component (if applicable):

Crash version:
Crash 7.3.1++
GNU gdb (GDB) 7.6

How reproducible:
always.

Steps to Reproduce:
1.run crash on a rhel8 dump.
2.
3.

Actual results:


Expected results:


Additional info:

Example from dump:

Dump files:
     KERNEL: /cores/retrace/repos/kernel/x86_64/usr/lib/debug/lib/modules/4.18.0-305.19.1.rt7.91.el8_4.x86_64/vmlinux  [TAINTED]
    DUMPFILE: /cores/retrace/tasks/510256984/crash/vmcore  [PARTIAL DUMP]


Timer cmd:

crash> timer -r -C 11
CPU: 11  HRTIMER_CPU_BASE: ffff8f829f95ee00
  CLOCK: 0  HRTIMER_CLOCK_BASE: ffff8f829f95ee80  [ktime_get]
  (empty)

  CLOCK: 1  HRTIMER_CLOCK_BASE: ffff8f829f95ef00  [ktime_get_real]
  (empty)

  CLOCK: 2  HRTIMER_CLOCK_BASE: ffff8f829f95ef80  [ktime_get_boottime]
  (empty)
crash> 



In this dump we are actually waiting for a timer on CPU 11 clock 4 to be run.

I hard coded the clocks to show all 8 of them.
 
Same dump:
crash-vl> sys
      KERNEL: /cores/retrace/repos/kernel/x86_64/usr/lib/debug/lib/modules/4.18.0-305.19.1.rt7.91.el8_4.x86_64/vmlinux
    DUMPFILE: /cores/retrace/tasks/510256984/crash/vmcore  [PARTIAL DUMP]



Now you can see the timers we are waiting on clock 4 and 5.

crash-vl> timer -r -C 11
CPU: 11  HRTIMER_CPU_BASE: ffff9a775f95ee00
  CLOCK: 0  HRTIMER_CLOCK_BASE: ffff9a775f95ee80  [ktime_get]
  (empty)

  CLOCK: 1  HRTIMER_CLOCK_BASE: ffff9a775f95ef00  [ktime_get_real]
  (empty)

  CLOCK: 2  HRTIMER_CLOCK_BASE: ffff9a775f95ef80  [ktime_get_boottime]
  (empty)

  CLOCK: 3  HRTIMER_CLOCK_BASE: ffff9a775f95f000  [ktime_get_clocktai]
  (empty)

  CLOCK: 4  HRTIMER_CLOCK_BASE: ffff9a775f95f080  [ktime_get]
      CURRENT   
  48114047000000
    SOFTEXPIRES       EXPIRES          TTE          HRTIMER           FUNCTION    
  48048203002814  48048203052814  -65843947186  ffffae5889f67e78  ffffffff96770fa0  <hrtimer_wakeup>

  CLOCK: 5  HRTIMER_CLOCK_BASE: ffff9a775f95f100  [ktime_get_real]
        CURRENT      
  1640021151290259551
      SOFTEXPIRES            EXPIRES             TTE          HRTIMER           FUNCTION    
  1640021064148260307  1640021064148310307  -87141949244  ffffae588a9c7d30  ffffffff96770fa0  <hrtimer_wakeup>

  CLOCK: 6  HRTIMER_CLOCK_BASE: ffff9a775f95f180  [ktime_get_boottime]
  (empty)

  CLOCK: 7  HRTIMER_CLOCK_BASE: ffff9a775f95f200  [ktime_get_clocktai]
  (empty)
crash-vl> 


The real issue in the dump is that they are late but that has nothing to do with  crash’s timer cmd.