[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen/arm: Assertion 'timer->status >= TIMER_STATUS_inactive' failed at timer.c:279

On 26/04/16 18:49, Dario Faggioli wrote:
> On Tue, 2016-04-26 at 15:25 +0100, Julien Grall wrote:
>> Hi Dario,
> Hi,
>> A couple of people have been reported Xen crash on the ARM64
>> Foundation Model [1] with recent unstable.
> Ok, thanks for reporting.
>> The crash seems to happen when Xen fails to bring up secondary CPUs
>> (see stack trace below).
> Ah... I see.
>> From my understanding, csched_free_pdata is trying to kill the
>> timer spc->ticker. However the status of this timer is
>> TIMER_STATUS_invalid.
>> This is because csched_init_pdata has set a deadline for the
>> timer (set_timer) and the softirq to schedule the timer has
>> not yet happen (indeed Xen is still in early boot).
> Yes, this is sort of what happens (only slightly different, see the
> changelog of the atached patch patch).
>> I am not sure how to fix this issue. How will you recommend
>> to fix it?
> Yeah, well, doing it cleanly includes a slight change in the scheduler
> hooks API, IMO... and we indeed should do it cleanly :-))
> George, what do you think?
> Honestly, this is similar to what I was thinking to do already (I mean,
> having an deinit_pdata hook, "symmetric" with the init_pdata one), when
> working on that series, because I do think it's cleaner... then, I
> abandoned the idea, as it looked to not be necessary... But apparently
> it may actually be! :-)
> Let me know, and I'll resubmit the patch properly (together with
> another bugfix I have in my queue).

Yeah, assuming the description in your changeset is accurate, this seems
like the right approach.

The main thing to add here I think is that we need to document what
different circumstances under which the various functions may be called
-- for instance, in credit1 free_pdata(), it seems to expect that spc
may == null at some point.  Future schedulers need to know the
circumstances under which this might happen so they can DTRT.

It might be nice at some point to have the alloc / free / init / deinit
functions in credit1 ordered in a rational way so that they could be
understood by glancing at them, rather than having to jump around, but
that's probably a nice-to-have clean-up for another time. :-)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.