[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] nr_irqs_gsi
On 07/23/12 23:34, Konrad Rzeszutek Wilk wrote: > On Mon, Jul 23, 2012 at 02:30:37PM +0100, Jan Beulich wrote: >>>>> On 12.07.12 at 04:17, Joe Jin <joe.jin@xxxxxxxxxx> wrote: >>>>>> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) >>>>>> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 >>>>>> (XEN) ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32]) >>>>>> (XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec80000, GSI 32-55 >>> >>> Below came from dom0: >>> >>> ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) >>> ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) >>> IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI 0-255 >> >> Now this and ... >> >>> ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32]) >>> IOAPIC[1]: apic_id 1, version 255, address 0xfec80000, GSI 32-287 >> >> ... this is clearly bogus, contradicting what Xen itself prints (see >> above). > > Yeah, that got fixed up in v3.5 (merge git > f08b9c2f8af0d61faa1170aeae4fbca1eff6a504) > specifically: > > x86/apic: Fix UP boot crash > xen/apic: implement io apic read with hypercall > xen/x86: Implement x86_apic_ops > x86/apic: Replace io_apic_ops with x86_io_apic_ops. > x86/ioapic: Add io_apic_ops driver layer to allow interception > Konrad, Would you please point out which commit is make sense for this issue? so far I still suspend it's a hypervisor issue rather than dom0 kernel. Thanks in advance, Joe _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |