On 23/08/12 19:03, Ben Guthro wrote:
I did some more bisecting here, and I came up with another changeset
that seems to be problematic, Re: IRQs
After bisecting the problem discussed earlier in this thread to the
changeset below,
http://xenbits.xen.org/hg/xen-unstable.hg/rev/0695a5cdcb42
I worked past that issue by the following hack:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1103,7 +1103,7 @@ void evtchn_destroy_final(struct domain *d)
void evtchn_move_pirqs(struct vcpu *v)
{
struct domain *d = v->domain;
- const cpumask_t *mask = cpumask_of(v->processor);
+ //const cpumask_t *mask = cpumask_of(v->processor);
unsigned int port;
struct evtchn *chn;
@@ -1111,7 +1111,9 @@ void evtchn_move_pirqs(struct vcpu *v)
for ( port = v->pirq_evtchn_head; port; port = chn->u.pirq.next_port )
{
chn = evtchn_from_port(d, port);
+#if 0
pirq_set_affinity(d, chn->u.pirq.irq, mask);
+#endif
}
spin_unlock(&d->event_lock);
}
This seemed to work for this rather old changeset, but it was not
sufficient to fix it against the 4.1, or unstable trees.
I further bisected, in combination with this hack, and found the
following changeset to also be problematic:
http://xenbits.xen.org/hg/xen-unstable.hg/rev/c2cb776a5365
That is, before this change I could resume reliably (with the hack
above) - and after I could not.
This was surprising to me, as this change also looks rather innocuous.
And by the looks of that changeset, the logic in fixup_irqs() in irq.c
was changed.
Jan: The commit message says "simplify operations [in] a few cases".
Was the change in fixup_irqs() deliberate?
~Andrew
