On 11/12/19 2:33 PM, Paul Thomas wrote: > I hope this helps. Good luck! > > -Paul [PATCH] needed Hi Paul, A+ for your help. Thanks very much for your valuable time and excellent post. The problem is two fold: 1) the configuration variable CONFIG_HOTPLUG_CPU controls the existence of the *definition* of 'takedown_cpu_task' at kernel/cpu.c line 880. (The *declaration* is in a header file.) But there's a usage at kernel/sched/core.c line 7399 and following line which is not conditioned on that same CONFIG_HOTPLUG_CPU config variable. 3) The linker message is misleading. All they had to say was that the symbol was undefined. The continued detail about this being an offset out of range issue created ambiguity as to whether this was out of range first and foremost, leading to the undefined status. Clearly now it is simply an undefined usage. I am looking for a low latency transfer of control from a GPIO interrupt handler that I wrote in one of my drivers, all the way to a high RT priority wait_queue blocked user thread. And stock (non-RT) 5.1 kernel was atrocious, simply unbelievably bad. Somewhere along the way during the great hunt for improvement I turned off CONFIG_HOTPLUG_CPU just to try a simpler config. BTW cyclictest on that same stock 5.1 kernel was showing an intermittent 4 msecs of delay. Yes msecs, not usecs. I would have submitted a patch for this but since its so trivial, it seems somebody with commit rights could make this change faster than applying a patch. Thanks all, Dick
