On Wed, Aug 09, 2017 at 05:05:42PM +0800, Journey Journey wrote: > Test case: https://github.com/saiyamd/softlockup_test/blob/master/softlockup_test.c > Please in the future provide more information as to what you are trying to do, what it is you are trying, what you are seeing, and why you think it's wrong. Because otherwise, we're forced to reverse engineer your intent. :( I'm _guessing_ that what you meant to say was: I have a testcase module that I use that attempts to trigger the kernels softlockup detection. Here is a link: https://github.com/saiyamd/softlockup_test/blob/master/softlockup_test.c I'm expecting it to fire the softlockup detector and panic the system (I use CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC in my test rig), however, when I load this module on an RT system, it doesn't appear to trigger the softlockup detector![1] What could be wrong? If that's what you meant, then the answer is: The way that you are "hogging" the CPU, on PREEMPT_RT, doesn't prevent the kernel from scheduling other tasks in and out (including the watchdog thread which pets the watchdog!). Your test case, effectively is: spin_lock(&lock) while (1) printk("..."); spin_unlock(&lock) On RT, spin-lock protected regions are preemptible. When the watchdog hrtimer fires and wakes up the softlockup thread, that thread preempts the thread stuck in this region and touches the watchdog. This prevents the watchdog threshold from being reached. The good news for you is that it should be entirely possible for you to trigger the softlockup detector on RT entirely in usermode. All you'd need to do is disable RT throttling, and set a thread SCHED_FIFO w/ prio 99 spinning. Julia 1: Note: this has nothing to do with Kdump whatsoever. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
