[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] pvops-2.6.32 - Interrupt routing problem
Maybe we need allow dom0 to re-programme the first 15 GSIs to solve this issue. And the root-cause is that the IRQ info(polarity&trigger mode) provided in MP table in some platforms is not always trusted, and system should re-programme it according to the info parsed from ACPI. If the platform provide correct info in MP table, the issue should be gone. Attached a proposed patch, could you have a try to see whether it can fix your issue. Xiantao Bastian Blank wrote: > On Mon, Mar 15, 2010 at 09:31:14PM -0400, Konrad Rzeszutek Wilk wrote: >> 1) Can you boot your baremetal with these options: >> acpi.debug_level=0xffffffff acpi.debug_layer=0x2 apic=debug > >> IOAPIC[0]: Set routing entry (8-14 -> 0x3e -> IRQ 14 Mode:0 Active:0) >> IOAPIC[0]: Set routing entry (8-14 -> 0x3e -> IRQ 14 Mode:1 Active:1) > >> 2) And then later on your Xen with these (make SURE to _not_ have >> apic=debug on >> the Linux kernel command line with Xen, it will blow): >> xen.gz apic=debug apic_verbosity=debug console_to_ring >> sync_console loglvl=all guest_loglvl=all > >> (XEN) IOAPIC[0]: Set PCI routing entry (8-14 -> 0x88 -> IRQ 14 >> Mode:0 Active:0) (XEN) Pin 8-14 already programmed >> (XEN) IOAPIC[0]: Set PCI routing entry (8-14 -> 0x88 -> IRQ 14 >> Mode:1 Active:1) > >> (XEN) IOAPIC[0]: Set PCI routing entry (8-5 -> 0x38 -> IRQ 5 Mode:0 >> Active:0) (XEN) Pin 8-5 already programmed >> (XEN) IOAPIC[0]: Set PCI routing entry (8-5 -> 0x38 -> IRQ 5 Mode:1 >> Active:1) > > Still with my hack to allow 8-5 and 8-14 to be reprogrammed. > > Bastian Attachment:
allow-dom0-re-programe-irq-info-for-legacy-irqs.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |