Interrupt handling in Xen 3.5 changed. There's no longer
a hardcoded upper limit. So *our* upper limit of 200 may be different from machine to machine now. So just retry if the hypercall failed.
This commit is contained in:
parent
677e91afbc
commit
84dc7c540d
@ -103,7 +103,7 @@
|
||||
*/
|
||||
|
||||
#include <sys/cdefs.h>
|
||||
__KERNEL_RCSID(0, "$NetBSD: intr.c,v 1.23 2009/04/22 21:16:40 ad Exp $");
|
||||
__KERNEL_RCSID(0, "$NetBSD: intr.c,v 1.24 2009/06/03 12:43:22 cegger Exp $");
|
||||
|
||||
#include "opt_multiprocessor.h"
|
||||
#include "opt_xen.h"
|
||||
@ -257,6 +257,9 @@ xen_intr_map(int *pirq, int type)
|
||||
* of the next device if this one used this IRQ. The easiest is
|
||||
* to allocate IRQs top-down, starting with a high number.
|
||||
* 250 and 230 have been tried, but got rejected by Xen.
|
||||
*
|
||||
* Xen 3.5 also rejects 200. Try out all values until Xen accepts
|
||||
* or none is available.
|
||||
*/
|
||||
static int xen_next_irq = 200;
|
||||
struct ioapic_softc *ioapic = ioapic_find(APIC_IRQ_APIC(*pirq));
|
||||
@ -271,11 +274,16 @@ xen_intr_map(int *pirq, int type)
|
||||
irq = APIC_IRQ_LEGACY_IRQ(*pirq);
|
||||
if (irq <= 0 || irq > 15)
|
||||
irq = xen_next_irq--;
|
||||
retry:
|
||||
/* allocate vector and route interrupt */
|
||||
op.cmd = PHYSDEVOP_ASSIGN_VECTOR;
|
||||
op.u.irq_op.irq = irq;
|
||||
if (HYPERVISOR_physdev_op(&op) < 0)
|
||||
panic("PHYSDEVOP_ASSIGN_VECTOR irq %d", irq);
|
||||
if (HYPERVISOR_physdev_op(&op) < 0) {
|
||||
irq = xen_next_irq--;
|
||||
if (xen_next_irq == 15)
|
||||
panic("PHYSDEVOP_ASSIGN_VECTOR irq %d", irq);
|
||||
goto retry;
|
||||
}
|
||||
irq2vect[irq] = op.u.irq_op.vector;
|
||||
vect2irq[op.u.irq_op.vector] = irq;
|
||||
pic->pic_addroute(pic, &phycpu_info_primary, pin,
|
||||
|
Loading…
Reference in New Issue
Block a user