On Thu, Jul 28, 2016 at 04:18:44PM -0400, Rich Felker wrote:
> On Thu, Jul 28, 2016 at 04:00:47PM -0400, Rich Felker wrote:
> > On Thu, Jul 28, 2016 at 04:44:05PM +0200, Thomas Gleixner wrote:
> > > > +static int jcore_pit_cpu_notify(struct notifier_block *self,
> > > > + unsigned long action, void *hcpu)
> > > > +{
> > > > + struct jcore_pit_nb *nb = container_of(self, struct jcore_pit_nb, nb);
> > > > + switch (action & ~CPU_TASKS_FROZEN) {
> > > > + case CPU_STARTING:
> > > > + jcore_pit_local_init(this_cpu_ptr(nb->pit_percpu));
> > > > + break;
> > > > + }
> > > > + return NOTIFY_OK;
> > >
> > > Please convert this to the new state machine model of cpu
> > > hotplug. CPU_STARTING will be gone very soon. Here is an example:
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=smp/hotplug&id=7e86e8bd8dd67649d176e08d8dfb90039f0a1e98
> >
> > Trying this change now and I'm getting hangs inside
> > cpuhp_invoke_ap_callback between wake_up_process and
> > wait_for_completion. I suspect it's not possible to run a scheduled
> > task yet because there's no timer yet, or something like that. Do I
> > need further infrastructure from tip that's not upstream yet in order
> > to test this? I just rebased on linus/master and still have the same
> > problem, but none of the other driver changes are in Linus's tree yet.
> > Following the other drivers in tip (again, I don't have any of these
> > in my tree), I put the new state between CPUHP_AP_SCHED_STARTING and
> > CPUHP_AP_NOTIFY_STARTING; is this correct?
>
> I think it's this bug where the fix is not yet in Linus's tree:
>
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/kernel/cpu.c?h=smp/hotplug&id=6a4e24518c8a10f78f44da219835239cb5aca90d
>
> Cherry-picking that made it work. FWIW, it's really hard to do
> development on top of new infrastructure that's not yet working in any
> tree that's intended for others to pull, but I made it work and I'll
> have a new version of the patch for you soon.
I hit some more snags with rcu_sched stalls that I thought were my
fault, but it looks like it's actually something in the linus/master I
had to rebase on (I've tagged the revision locally in case this is
something we need to track later). They happen equally with or without
my latest changes for the notify_nb -> cpuhp transition and other
requested changes to the pit driver.
Rich
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
