[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. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |