Files
android_kernel_xiaomi_sm8450/include/linux
Jason Wessel d6ad3e286d softlockup: Add sched_clock_tick() to avoid kernel warning on kgdb resume
When CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is set, sched_clock() gets
the time from hardware such as the TSC on x86. In this
configuration kgdb will report a softlock warning message on
resuming or detaching from a debug session.

Sequence of events in the problem case:

 1) "cpu sched clock" and "hardware time" are at 100 sec prior
    to a call to kgdb_handle_exception()

 2) Debugger waits in kgdb_handle_exception() for 80 sec and on
    exit the following is called ...  touch_softlockup_watchdog() -->
    __raw_get_cpu_var(touch_timestamp) = 0;

 3) "cpu sched clock" = 100s (it was not updated, because the
    interrupt was disabled in kgdb) but the "hardware time" = 180 sec

 4) The first timer interrupt after resuming from
    kgdb_handle_exception updates the watchdog from the "cpu sched clock"

update_process_times() { ...  run_local_timers() -->
softlockup_tick() --> check (touch_timestamp == 0) (it is "YES"
here, we have set "touch_timestamp = 0" at kgdb) -->
__touch_softlockup_watchdog() ***(A)--> reset "touch_timestamp"
to "get_timestamp()" (Here, the "touch_timestamp" will still be
set to 100s.)  ...

    scheduler_tick() ***(B)--> sched_clock_tick() (update "cpu sched
    clock" to "hardware time" = 180s) ...  }

 5) The Second timer interrupt handler appears to have a large
    jump and trips the softlockup warning.

update_process_times() { ...  run_local_timers() -->
softlockup_tick() --> "cpu sched clock" - "touch_timestamp" =
180s-100s > 60s --> printk "soft lockup error messages" ...  }

note: ***(A) reset "touch_timestamp" to
"get_timestamp(this_cpu)"

Why is "touch_timestamp" 100 sec, instead of 180 sec?

When CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is set, the call trace of
get_timestamp() is:

get_timestamp(this_cpu)
 -->cpu_clock(this_cpu)
 -->sched_clock_cpu(this_cpu)
 -->__update_sched_clock(sched_clock_data, now)

The __update_sched_clock() function uses the GTOD tick value to
create a window to normalize the "now" values.  So if "now"
value is too big for sched_clock_data, it will be ignored.

The fix is to invoke sched_clock_tick() to update "cpu sched
clock" in order to recover from this state.  This is done by
introducing the function touch_softlockup_watchdog_sync(). This
allows kgdb to request that the sched clock is updated when the
watchdog thread runs the first time after a resume from kgdb.

[yong.zhang0@gmail.com: Use per cpu instead of an array]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Dongdong Deng <Dongdong.Deng@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net
Cc: peterz@infradead.org
LKML-Reference: <1264631124-4837-2-git-send-email-jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-01 08:22:32 +01:00
..
2010-01-13 09:04:53 +00:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-10-27 16:47:55 -04:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-12-16 07:20:13 -08:00
2009-09-08 17:42:50 -07:00
2010-01-11 14:29:20 +01:00
2009-11-10 12:31:43 +01:00
2009-11-08 20:57:03 -08:00
2009-12-06 21:10:56 +01:00
2009-09-23 11:01:25 -07:00
2009-09-18 09:48:52 -07:00
2009-12-10 23:52:01 +00:00
2009-11-04 09:50:58 -08:00
2009-10-01 21:17:49 +02:00
2009-09-14 17:41:42 -07:00
2009-12-15 08:53:33 -08:00
2009-11-04 09:50:58 -08:00
2009-12-10 15:02:53 +01:00
2009-12-23 13:33:54 +01:00
2009-11-04 09:50:58 -08:00
2010-01-14 09:05:26 -05:00
2009-11-04 09:50:58 -08:00
2010-01-11 14:32:44 +01:00
2009-12-03 11:58:47 +00:00
2009-09-01 01:13:31 -07:00
2009-11-05 14:08:03 +01:00
2009-12-14 23:55:34 +01:00
2009-12-14 21:17:29 +01:00
2009-12-21 11:32:27 -05:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-12-25 17:30:22 -08:00
2009-12-02 23:38:13 -08:00
2009-11-04 09:50:58 -08:00
2009-09-26 10:17:19 -07:00
2009-10-18 18:52:53 -07:00
2009-08-29 15:53:00 +02:00
2009-09-23 07:39:58 -07:00
2009-09-26 10:17:19 -07:00
2009-12-16 06:56:12 -08:00
2009-12-03 09:32:17 +02:00
2009-12-09 17:14:38 +11:00
2009-12-15 08:53:36 -08:00
2009-10-01 21:17:49 +02:00
2009-09-22 07:17:35 -07:00
2009-12-15 08:53:20 -08:00
2009-12-12 13:08:15 +01:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-09-26 10:17:19 -07:00
2009-11-28 15:05:05 -05:00
2009-12-09 12:12:44 +02:00
2010-01-04 15:41:47 -08:00
2009-11-04 09:50:58 -08:00
2009-11-04 09:50:58 -08:00
2009-12-15 08:53:25 -08:00
2009-10-04 15:05:10 -07:00
2009-12-03 11:43:23 +00:00
2009-12-02 09:55:33 +01:00
2009-09-23 07:39:41 -07:00
2009-11-10 22:26:29 -08:00
2009-10-30 15:06:37 -07:00
2009-12-15 08:53:20 -08:00
2009-11-04 09:50:58 -08:00
2009-08-28 19:57:30 -04:00
2009-11-30 12:02:53 +09:00
2009-12-02 19:57:15 -08:00
2009-11-18 14:52:25 +01:00
2009-12-16 22:32:29 -05:00
2009-10-26 09:40:30 +01:00
2010-01-14 22:38:09 -05:00
2009-12-15 08:53:16 -08:00
2009-12-25 17:30:22 -08:00
2009-11-13 20:46:24 +01:00
2009-08-30 22:26:34 +02:00
2009-10-29 11:17:40 +11:00
2010-01-16 12:15:38 -08:00
2009-11-10 20:54:38 -08:00
2009-09-23 18:13:10 -07:00
2009-08-26 12:39:29 +01:00
2009-09-23 22:26:32 +09:30
2009-09-15 16:51:30 +02:00
2009-12-16 12:16:49 -05:00