Hello list,
Just for fun, I tried compiling the 3.0-rc4 kernel from Jeremy''s
git repo. Compilation and installation were successful, so does
booting into the kernel without xen.
With xen however, I get the following:
ACPI: SCI (IRQ9) allocation failed
ACPI: Unable to start the ACPI Interpreter
============================================================================BUG
Acpi-ParseExt: Objects remaining on kmem_cache_close()
-----------------------------------------------------------------------------
INFO: Slab 0xffffea0000a57308 objects=56 used=1 fp=0xffff88002f4577e0
flags=0x1000000000000080
INFO: Object 0xffff88002f457900 @offset=2304
SLUB Acpi-ParseExt: kmem_cache_destroy called for cache that still has objects.
SLUB: Unable to add boot slab alias [some weird characters] to sysfs
Loading, please wait...
There could be some mix ups between "0" and "8" in the
hex values
as the above were transcribed from a cameraphone photo. The system
continues to boot, but fails badly trying to start udev, stuck with
the following (with varying device IDs):
...
udevd[80]: timeout: killing ''/sbin/modprobe -b
pci:v000011ABd00006440sv0000d00006440bc01sc00i00'' [92]
...
Not looking for a solution here, just reporting this to the devs.
Attached is the kernel .config file. Running on xen-unstable compiled today.
Liwei
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Just a follow up. I found out that the boot failure''s due to a unsupported (faulty?) PATA controller. Removed it and the system actually boots. The SCI allocation failure still occurs though. Apparently this also occurs with the Debian experimental 3.0 kernel too. Here''s the full backtrace from dmesg: [ 3.934034] bio: create slab <bio-0> at 0 [ 3.936216] ACPI: SCI (IRQ9) allocation failed [ 3.936259] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119) [ 3.936264] ACPI: Unable to start the ACPI Interpreter [ 3.974522] ============================================================================[ 3.974570] BUG Acpi-ParseExt: Objects remaining on kmem_cache_close() [ 3.974613] ----------------------------------------------------------------------------- [ 3.974614] [ 3.974694] INFO: Slab 0xffffea0000a57308 objects=56 used=1 fp=0xffff88002f4577e0 flags=0x100000000000080 [ 3.974743] Pid: 1, comm: swapper Not tainted 3.0.0-rc4-amd64+ #1 [ 3.974745] Call Trace: [ 3.974753] [<ffffffff810e5f13>] ? slab_err+0x93/0xb5 [ 3.974758] [<ffffffff81006b4d>] ? xen_force_evtchn_callback+0x9/0xa [ 3.974762] [<ffffffff810071b2>] ? check_events+0x12/0x20 [ 3.974766] [<ffffffff810e8ff9>] ? kmem_cache_destroy+0x170/0x2dc [ 3.974770] [<ffffffff816c1db2>] ? acpi_sleep_proc_init+0x27/0x27 [ 3.974774] [<ffffffff811cf965>] ? acpi_os_delete_cache+0x6/0xa [ 3.974779] [<ffffffff811eedee>] ? acpi_ut_delete_caches+0x6a/0x7a [ 3.974783] [<ffffffff811efd3f>] ? acpi_terminate+0x3e/0x49 [ 3.974786] [<ffffffff816c2000>] ? acpi_init+0x24e/0x297 [ 3.974791] [<ffffffff8122f708>] ? __class_create+0x3d/0x61 [ 3.974795] [<ffffffff810f0c30>] ? mount_fs+0x144/0x144 [ 3.974799] [<ffffffff816bf936>] ? video_setup+0x75/0x75 [ 3.974803] [<ffffffff816bf99c>] ? fbmem_init+0x66/0x95 [ 3.974806] [<ffffffff81002086>] ? do_one_initcall+0x76/0x12c [ 3.974810] [<ffffffff81696bf4>] ? kernel_init+0xbd/0x137 [ 3.974815] [<ffffffff813278a4>] ? kernel_thread_helper+0x4/0x10 [ 3.974819] [<ffffffff813269b3>] ? int_ret_from_sys_call+0x7/0x1b [ 3.974823] [<ffffffff813216e5>] ? retint_restore_args+0x5/0x6 [ 3.974826] [<ffffffff813278a0>] ? gs_change+0x13/0x13 [ 3.974830] INFO: Object 0xffff88002f457900 @offset=2304 [ 3.974873] SLUB Acpi-ParseExt: kmem_cache_destroy called for cache that still has objects. [ 3.974920] Pid: 1, comm: swapper Not tainted 3.0.0-rc4-amd64+ #1 [ 3.974922] Call Trace: [ 3.974925] [<ffffffff810e9116>] ? kmem_cache_destroy+0x28d/0x2dc [ 3.974928] [<ffffffff816c1db2>] ? acpi_sleep_proc_init+0x27/0x27 [ 3.974931] [<ffffffff811cf965>] ? acpi_os_delete_cache+0x6/0xa [ 3.974934] [<ffffffff811eedee>] ? acpi_ut_delete_caches+0x6a/0x7a [ 3.974938] [<ffffffff811efd3f>] ? acpi_terminate+0x3e/0x49 [ 3.974941] [<ffffffff816c2000>] ? acpi_init+0x24e/0x297 [ 3.974944] [<ffffffff8122f708>] ? __class_create+0x3d/0x61 [ 3.974947] [<ffffffff810f0c30>] ? mount_fs+0x144/0x144 [ 3.974950] [<ffffffff816bf936>] ? video_setup+0x75/0x75 [ 3.974953] [<ffffffff816bf99c>] ? fbmem_init+0x66/0x95 [ 3.974956] [<ffffffff81002086>] ? do_one_initcall+0x76/0x12c [ 3.974960] [<ffffffff81696bf4>] ? kernel_init+0xbd/0x137 [ 3.974963] [<ffffffff813278a4>] ? kernel_thread_helper+0x4/0x10 [ 3.974966] [<ffffffff813269b3>] ? int_ret_from_sys_call+0x7/0x1b [ 3.974970] [<ffffffff813216e5>] ? retint_restore_args+0x5/0x6 [ 3.974973] [<ffffffff813278a0>] ? gs_change+0x13/0x13 On 25 June 2011 02:55, Liwei <xieliwei@gmail.com> wrote:> Hello list, > Just for fun, I tried compiling the 3.0-rc4 kernel from Jeremy''s > git repo. Compilation and installation were successful, so does > booting into the kernel without xen. > With xen however, I get the following: > > ACPI: SCI (IRQ9) allocation failed > ACPI: Unable to start the ACPI Interpreter > ============================================================================> BUG Acpi-ParseExt: Objects remaining on kmem_cache_close() > ----------------------------------------------------------------------------- > > INFO: Slab 0xffffea0000a57308 objects=56 used=1 fp=0xffff88002f4577e0 > flags=0x1000000000000080 > INFO: Object 0xffff88002f457900 @offset=2304 > SLUB Acpi-ParseExt: kmem_cache_destroy called for cache that still has objects. > SLUB: Unable to add boot slab alias [some weird characters] to sysfs > Loading, please wait... > > There could be some mix ups between "0" and "8" in the hex values > as the above were transcribed from a cameraphone photo. The system > continues to boot, but fails badly trying to start udev, stuck with > the following (with varying device IDs): > > ... > udevd[80]: timeout: killing ''/sbin/modprobe -b > pci:v000011ABd00006440sv0000d00006440bc01sc00i00'' [92] > ... > > Not looking for a solution here, just reporting this to the devs. > Attached is the kernel .config file. Running on xen-unstable compiled today. > > Liwei >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 15:12 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 27 June 2011 21:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: On Sat, Jun 25, 2011 at 08:33:04PM +0800, Liwei wrote:>> Just a follow up. I found out that the boot failure''s due to a >> unsupported (faulty?) PATA controller. Removed it and the system >> actually boots. The SCI allocation failure still occurs though. > > That in general causes the ACPI interpreter to stop working > completly.Does failure of the interpreter cause anything bad to happen? Common sense tells me that things should be going very wrong, but the system does come up. I can ssh in, run hvm domains, etc. The only problem I see though is that interrupt mapping for certain PCI passthrough devices (particularly one of the two Intel EHCI USB controllers and a firewire controller) fails. VGA passthrough with or without gfx_passthru = 1 still works fine though: #xl dmesg (XEN) physdev.c:164: dom2: 10:-1 already mapped to 16 (XEN) irq.c:1297:d0 Cannot bind IRQ 16 to guest. Others do not share. (XEN) domctl.c:914:d0 pt_irq_create_bind failed! (XEN) irq.c:1297:d0 Cannot bind IRQ 20 to guest. Others do not share. (XEN) domctl.c:914:d0 pt_irq_create_bind failed! #cat qemu-dm-vm.log IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.0 ... pt_iomul_init: Error: pt_iomul_init can''t open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0 pt_register_regions: IO region registered (size=0x00001000 base_addr=0xa0004000) pci_intx: intx=1 register_real_device: Error: Binding of interrupt failed! rc=-1 register_real_device: Real physical device 00:1a.0 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 0f:03.0 ... pt_iomul_init: Error: pt_iomul_init can''t open file /dev/xen/pci_iomul: No such file or directory: 0xf:0x3.0x0 pt_register_regions: IO region registered (size=0x00001000 base_addr=0xfbe04000) pt_register_regions: IO region registered (size=0x00004000 base_addr=0xfbe00000) pci_intx: intx=1 register_real_device: Error: Binding of interrupt failed! rc=-1 register_real_device: Real physical device 0f:03.0 registered successfuly! #lspci -v 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI]) Subsystem: eVga.com. Corp. Device 1014 Flags: bus master, medium devsel, latency 0, IRQ 10 Memory at a0004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: xen-pciback 0f:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) Subsystem: nVidia Corporation Device cb84 Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at fbe04000 (32-bit, non-prefetchable) [size=4K] Memory at fbe00000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Kernel driver in use: xen-pciback (Only IRQs 1, 3, 5, 8, 10, 11, 12, 200++ appear in /proc/interrupts)> > If you look at the full serial log do you see INT_SRC_OVR for IRQ 9? > You should see something akin to this: >----snip---- Yes I do: [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information ----snip---- [ 3.405497] Memory: 776452k/13631488k available (3239k kernel code, 3146184k absent, 9708852k reserved, 3423k data, 532k init) [ 3.405579] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 3.405616] Preemptible hierarchical RCU implementation. [ 3.405630] NR_IRQS:33024 nr_irqs:2048 16 [ 3.405705] xen: sci override: global_irq=20 trigger=0 polarity=1 [ 3.405708] xen: registering gsi 20 triggering 0 polarity 1 [ 3.405721] xen: --> pirq=20 -> irq=20 [ 3.405728] xen: acpi sci 20 [ 3.405732] xen: --> pirq=1 -> irq=1 [ 3.405736] xen: --> pirq=2 -> irq=2 [ 3.405739] xen: --> pirq=3 -> irq=3 [ 3.405743] xen: --> pirq=4 -> irq=4 [ 3.405746] xen: --> pirq=5 -> irq=5 [ 3.405750] xen: --> pirq=6 -> irq=6 [ 3.405753] xen: --> pirq=7 -> irq=7 [ 3.405757] xen: --> pirq=8 -> irq=8 [ 3.405760] xen: --> pirq=10 -> irq=10 [ 3.405763] xen: --> pirq=11 -> irq=11 [ 3.405767] xen: --> pirq=12 -> irq=12 [ 3.405770] xen: --> pirq=13 -> irq=13 [ 3.405774] xen: --> pirq=14 -> irq=14 [ 3.405777] xen: --> pirq=15 -> irq=15 Also, it seems that the same SCI allocation failure and the problems described above is also present in the 2.6.39 branch as well. The only version which I can get to work reliably with is 2.6.32.xx. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-27 16:32 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Mon, Jun 27, 2011 at 11:12:43PM +0800, Liwei wrote:> On 27 June 2011 21:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Sat, Jun 25, 2011 at 08:33:04PM +0800, Liwei wrote: > >> Just a follow up. I found out that the boot failure''s due to a > >> unsupported (faulty?) PATA controller. Removed it and the system > >> actually boots. The SCI allocation failure still occurs though. > > > > That in general causes the ACPI interpreter to stop working > > completly. > > Does failure of the interpreter cause anything bad to happen? CommonWell yes. It can''t interpret the ACPI _PRT tables so the interrupt routing information is not present. Which means that the drivers fall back to polling mode or end up using the wrong IRQs.> sense tells me that things should be going very wrong, but the system > does come up. I can ssh in, run hvm domains, etc. The only problem I > see though is that interrupt mapping for certain PCI passthrough > devices (particularly one of the two Intel EHCI USB controllers and a > firewire controller) fails. VGA passthrough with or without > gfx_passthru = 1 still works fine though: > > #xl dmesg > (XEN) physdev.c:164: dom2: 10:-1 already mapped to 16 > (XEN) irq.c:1297:d0 Cannot bind IRQ 16 to guest. Others do not share. > (XEN) domctl.c:914:d0 pt_irq_create_bind failed! > (XEN) irq.c:1297:d0 Cannot bind IRQ 20 to guest. Others do not share. > (XEN) domctl.c:914:d0 pt_irq_create_bind failed! > > #cat qemu-dm-vm.log > IRQ type = MSI-INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 00:1a.0 ... > pt_iomul_init: Error: pt_iomul_init can''t open file > /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0 > pt_register_regions: IO region registered (size=0x00001000 base_addr=0xa0004000) > pci_intx: intx=1 > register_real_device: Error: Binding of interrupt failed! rc=-1 > register_real_device: Real physical device 00:1a.0 registered successfuly! > IRQ type = INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 0f:03.0 ... > pt_iomul_init: Error: pt_iomul_init can''t open file > /dev/xen/pci_iomul: No such file or directory: 0xf:0x3.0x0 > pt_register_regions: IO region registered (size=0x00001000 base_addr=0xfbe04000) > pt_register_regions: IO region registered (size=0x00004000 base_addr=0xfbe00000) > pci_intx: intx=1 > register_real_device: Error: Binding of interrupt failed! rc=-1 > register_real_device: Real physical device 0f:03.0 registered successfuly! > > #lspci -v > 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset > USB2 Enhanced Host Controller (rev 05) (prog-if 20 [EHCI]) > Subsystem: eVga.com. Corp. Device 1014 > Flags: bus master, medium devsel, latency 0, IRQ 10 > Memory at a0004000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [50] Power Management version 2 > Capabilities: [58] Debug port: BAR=1 offset=00a0 > Capabilities: [98] PCI Advanced Features > Kernel driver in use: xen-pciback > 0f:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A > IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) > Subsystem: nVidia Corporation Device cb84 > Flags: bus master, medium devsel, latency 64, IRQ 11 > Memory at fbe04000 (32-bit, non-prefetchable) [size=4K] > Memory at fbe00000 (32-bit, non-prefetchable) [size=16K] > Capabilities: [44] Power Management version 2 > Kernel driver in use: xen-pciback > > (Only IRQs 1, 3, 5, 8, 10, 11, 12, 200++ appear in /proc/interrupts) > > > > > If you look at the full serial log do you see INT_SRC_OVR for IRQ 9? > > You should see something akin to this: > > > ----snip---- > > Yes I do: > > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [ 0.000000] ACPI: IRQ0 used by override. > [ 0.000000] ACPI: IRQ2 used by override. > [ 0.000000] ACPI: IRQ9 used by override. > [ 0.000000] Using ACPI (MADT) for SMP configuration information > ----snip---- > [ 3.405497] Memory: 776452k/13631488k available (3239k kernel code, > 3146184k absent, 9708852k reserved, 3423k data, 532k init) > [ 3.405579] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, > CPUs=8, Nodes=1 > [ 3.405616] Preemptible hierarchical RCU implementation. > [ 3.405630] NR_IRQS:33024 nr_irqs:2048 16 > [ 3.405705] xen: sci override: global_irq=20 trigger=0 polarity=1 > [ 3.405708] xen: registering gsi 20 triggering 0 polarity 1 > [ 3.405721] xen: --> pirq=20 -> irq=20 > [ 3.405728] xen: acpi sci 20Whoa. 20. That is unusual, but we do set it up. Perhaps ineptly thought. Is there an option in the BIOS to toggle some ACPI SCI option? Does /proc/interrupts have this for IRQ 20: 9: 3 0 0 0 0 0 xen-pirq-ioapic-level acpi ?> [ 3.405732] xen: --> pirq=1 -> irq=1 > [ 3.405736] xen: --> pirq=2 -> irq=2 > [ 3.405739] xen: --> pirq=3 -> irq=3 > [ 3.405743] xen: --> pirq=4 -> irq=4 > [ 3.405746] xen: --> pirq=5 -> irq=5 > [ 3.405750] xen: --> pirq=6 -> irq=6 > [ 3.405753] xen: --> pirq=7 -> irq=7 > [ 3.405757] xen: --> pirq=8 -> irq=8 > [ 3.405760] xen: --> pirq=10 -> irq=10 > [ 3.405763] xen: --> pirq=11 -> irq=11 > [ 3.405767] xen: --> pirq=12 -> irq=12 > [ 3.405770] xen: --> pirq=13 -> irq=13 > [ 3.405774] xen: --> pirq=14 -> irq=14 > [ 3.405777] xen: --> pirq=15 -> irq=15 > > Also, it seems that the same SCI allocation failure and the problems > described above is also present in the 2.6.39 branch as well. The only > version which I can get to work reliably with is 2.6.32.xx._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 16:59 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 28 June 2011 00:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Mon, Jun 27, 2011 at 11:12:43PM +0800, Liwei wrote: >> >> Does failure of the interpreter cause anything bad to happen? Common > > Well yes. It can''t interpret the ACPI _PRT tables so the > interrupt routing information is not present. > > Which means that the drivers fall back to polling mode or end up > using the wrong IRQs. >----snip---->> Yes I do: >> >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) >> [ 0.000000] ACPI: IRQ0 used by override. >> [ 0.000000] ACPI: IRQ2 used by override. >> [ 0.000000] ACPI: IRQ9 used by override. >> [ 0.000000] Using ACPI (MADT) for SMP configuration information >> ----snip---- >> [ 3.405497] Memory: 776452k/13631488k available (3239k kernel code, >> 3146184k absent, 9708852k reserved, 3423k data, 532k init) >> [ 3.405579] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, >> CPUs=8, Nodes=1 >> [ 3.405616] Preemptible hierarchical RCU implementation. >> [ 3.405630] NR_IRQS:33024 nr_irqs:2048 16 >> [ 3.405705] xen: sci override: global_irq=20 trigger=0 polarity=1 >> [ 3.405708] xen: registering gsi 20 triggering 0 polarity 1 >> [ 3.405721] xen: --> pirq=20 -> irq=20 >> [ 3.405728] xen: acpi sci 20 > > Whoa. 20. That is unusual, but we do set it up. Perhaps ineptly thought. > Is there an option in the BIOS to toggle some ACPI SCI option?Did a reboot and checked the BIOS menus. Nothing about SCI in there. Is the SCI requirement something new in the 2.6.39+ kernels? Because things are working well with 2.6.32.> > Does /proc/interrupts have this for IRQ 20: > > 9: 3 0 0 0 0 0 xen-pirq-ioapic-level acpi > > ?Nope, IRQ 20 or any acpi related interrupts doesn''t show up: CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 1: 4 0 0 0 0 0 0 0 xen-pirq-ioapic-edge i8042 3: 0 0 0 0 0 0 0 0 xen-pirq-ioapic-edge mvsas 5: 0 0 0 0 0 0 0 0 xen-pirq-ioapic-edge mvsas 8: 3 0 0 0 0 0 0 0 xen-pirq-ioapic-edge rtc0 10: 0 0 0 0 0 0 0 0 xen-pirq-ioapic-edge mvsas 11: 0 0 0 0 0 0 0 0 xen-pirq-ioapic-edge mvsas 12: 6 0 0 0 0 0 0 0 xen-pirq-ioapic-edge i8042 272: 7433262 0 0 0 0 0 0 0 xen-percpu-virq timer0 273: 260592 0 0 0 0 0 0 0 xen-percpu-ipi resched0 274: 28786 0 0 0 0 0 0 0 xen-percpu-ipi callfunc0 275: 0 0 0 0 0 0 0 0 xen-percpu-virq debug0 276: 112 0 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle0 277: 0 5534620 0 0 0 0 0 0 xen-percpu-virq timer1 278: 0 430137 0 0 0 0 0 0 xen-percpu-ipi resched1 279: 0 1210410 0 0 0 0 0 0 xen-percpu-ipi callfunc1 280: 0 0 0 0 0 0 0 0 xen-percpu-virq debug1 281: 0 975 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle1 282: 0 0 114181 0 0 0 0 0 xen-percpu-virq timer2 283: 0 0 134749 0 0 0 0 0 xen-percpu-ipi resched2 284: 0 0 1211915 0 0 0 0 0 xen-percpu-ipi callfunc2 285: 0 0 0 0 0 0 0 0 xen-percpu-virq debug2 286: 0 0 69666 0 0 0 0 0 xen-percpu-ipi callfuncsingle2 287: 0 0 0 30680 0 0 0 0 xen-percpu-virq timer3 288: 0 0 0 10670 0 0 0 0 xen-percpu-ipi resched3 289: 0 0 0 1223807 0 0 0 0 xen-percpu-ipi callfunc3 290: 0 0 0 0 0 0 0 0 xen-percpu-virq debug3 291: 0 0 0 1141 0 0 0 0 xen-percpu-ipi callfuncsingle3 292: 0 0 0 0 21732 0 0 0 xen-percpu-virq timer4 293: 0 0 0 0 6725 0 0 0 xen-percpu-ipi resched4 294: 0 0 0 0 1223929 0 0 0 xen-percpu-ipi callfunc4 295: 0 0 0 0 0 0 0 0 xen-percpu-virq debug4 296: 0 0 0 0 3068 0 0 0 xen-percpu-ipi callfuncsingle4 297: 0 0 0 0 0 16427 0 0 xen-percpu-virq timer5 298: 0 0 0 0 0 5746 0 0 xen-percpu-ipi resched5 299: 0 0 0 0 0 1224228 0 0 xen-percpu-ipi callfunc5 300: 0 0 0 0 0 0 0 0 xen-percpu-virq debug5 301: 0 0 0 0 0 1002 0 0 xen-percpu-ipi callfuncsingle5 302: 0 0 0 0 0 0 17731 0 xen-percpu-virq timer6 303: 0 0 0 0 0 0 7430 0 xen-percpu-ipi resched6 304: 0 0 0 0 0 0 1222899 0 xen-percpu-ipi callfunc6 305: 0 0 0 0 0 0 0 0 xen-percpu-virq debug6 306: 0 0 0 0 0 0 5066 0 xen-percpu-ipi callfuncsingle6 307: 0 0 0 0 0 0 0 15633 xen-percpu-virq timer7 308: 0 0 0 0 0 0 0 5719 xen-percpu-ipi resched7 309: 0 0 0 0 0 0 0 1224195 xen-percpu-ipi callfunc7 310: 0 0 0 0 0 0 0 0 xen-percpu-virq debug7 311: 0 0 0 0 0 0 0 1522 xen-percpu-ipi callfuncsingle7 312: 2194 0 0 0 0 0 0 0 xen-dyn-event xenbus 313: 0 0 0 0 0 0 0 0 xen-percpu-virq pcpu 314: 0 0 0 0 0 0 0 0 xen-pirq-msi PCIe PME 316: 0 0 0 0 0 0 0 0 xen-pirq-msi PCIe PME 318: 325412 0 0 0 0 0 0 0 xen-pirq-msi sky2@pci:0000:0c:00.0 319: 451 0 0 0 0 0 0 0 xen-pirq-msi sky2@pci:0000:0d:00.0 320: 164703 0 0 0 0 0 0 0 xen-pirq-msi ahci 321: 1351 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenstored 322: 1 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenstored 323: 9 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenstored 324: 1 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenconsoled 325: 2417960 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 326: 1825452 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 327: 4102938 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 328: 1921778 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 329: 1556828 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 330: 1580859 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 331: 1633228 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 332: 1940019 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 333: 9 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenstored 334: 1 0 0 0 0 0 0 0 xen-dyn-event evtchn:xenconsoled 335: 3718012 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm 336: 3364579 0 0 0 0 0 0 0 xen-dyn-event evtchn:qemu-dm NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts LOC: 0 0 0 0 0 0 0 0 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 0 0 0 0 IRQ work interrupts RES: 261162 432314 134760 10685 6740 5756 7441 5732 Rescheduling interrupts CAL: 28902 1211389 1281588 1224956 1227002 1225236 1227982 1225717 Function call interrupts TLB: 0 0 0 0 0 0 0 0 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 0 0 0 0 0 0 0 0 Machine check polls ERR: 0 MIS: 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-27 17:33 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 12:59:04AM +0800, Liwei wrote:> On 28 June 2011 00:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Mon, Jun 27, 2011 at 11:12:43PM +0800, Liwei wrote: > >> > >> Does failure of the interpreter cause anything bad to happen? Common > > > > Well yes. It can''t interpret the ACPI _PRT tables so the > > interrupt routing information is not present. > > > > Which means that the drivers fall back to polling mode or end up > > using the wrong IRQs. > > > ----snip---- > >> Yes I do: > >> > >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > >> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > >> [ 0.000000] ACPI: IRQ0 used by override. > >> [ 0.000000] ACPI: IRQ2 used by override. > >> [ 0.000000] ACPI: IRQ9 used by override. > >> [ 0.000000] Using ACPI (MADT) for SMP configuration information > >> ----snip---- > >> [ 3.405497] Memory: 776452k/13631488k available (3239k kernel code, > >> 3146184k absent, 9708852k reserved, 3423k data, 532k init) > >> [ 3.405579] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, > >> CPUs=8, Nodes=1 > >> [ 3.405616] Preemptible hierarchical RCU implementation. > >> [ 3.405630] NR_IRQS:33024 nr_irqs:2048 16 > >> [ 3.405705] xen: sci override: global_irq=20 trigger=0 polarity=1 > >> [ 3.405708] xen: registering gsi 20 triggering 0 polarity 1 > >> [ 3.405721] xen: --> pirq=20 -> irq=20 > >> [ 3.405728] xen: acpi sci 20 > > > > Whoa. 20. That is unusual, but we do set it up. Perhaps ineptly thought. > > Is there an option in the BIOS to toggle some ACPI SCI option? > > Did a reboot and checked the BIOS menus. Nothing about SCI in there. > Is the SCI requirement something new in the 2.6.39+ kernels? BecauseNo.> things are working well with 2.6.32.Hmm. Can you attach the full serial log and on the Linux kernel line have ''loglevel=10 debug initcall_debug'' please? Is the serial log when running under 2.6.32 any different? (up to the ACPI interpretter blowing up)? What does the /proc/interrupts look under 2.6.32?> > > > > Does /proc/interrupts have this for IRQ 20: > > > > 9: 3 0 0 0 0 0 xen-pirq-ioapic-level acpi > > > > ? > > Nope, IRQ 20 or any acpi related interrupts doesn''t show up: > > CPU0 CPU1 CPU2 CPU3 CPU4 > CPU5 CPU6 CPU7 > 1: 4 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge i8042 > 3: 0 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge mvsas > 5: 0 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge mvsas > 8: 3 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge rtc0 > 10: 0 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge mvsas > 11: 0 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge mvsas > 12: 6 0 0 0 0 > 0 0 0 xen-pirq-ioapic-edge i8042Yeah, that is messed up. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 18:23 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 28 June 2011 01:33, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Hmm. Can you attach the full serial log and on the Linux kernel line have > ''loglevel=10 debug initcall_debug'' please?See attached.> > Is the serial log when running under 2.6.32 any different? (up to the ACPI interpretter > blowing up)? What does the /proc/interrupts look under 2.6.32?There''s too much noise for me to compare, but I think they''re more or less the same until the the interpreter blows up for 3.0 whereas 2.6.32 does not. I''ve attached the /proc/interrupts dump for both kernel versions. The difference to note is that IRQ 20 does appear in 2.6.32. Also attached is the xen dmesg. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-27 18:59 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 02:23:09AM +0800, Liwei wrote:> On 28 June 2011 01:33, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Hmm. Can you attach the full serial log and on the Linux kernel line have > > ''loglevel=10 debug initcall_debug'' please? > > See attached. > > > > > Is the serial log when running under 2.6.32 any different? (up to the ACPI interpretter > > blowing up)? What does the /proc/interrupts look under 2.6.32? > > There''s too much noise for me to compare, but I think they''re more or > less the same until the the interpreter blows up for 3.0 whereas > 2.6.32 does not.What is weird is: 1 [ 3.970863] ACPI: SCI (IRQ9) allocation failed [ 3.970906] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119) [ 3.970911] ACPI: Unable to start the ACPI Interpreter IRQ9.. It looks like it really wants to use 9 instead of 20. Looking at the code it does: 144 status 145 acpi_os_install_interrupt_handler((u32) acpi_gbl_FADT.sci_interrupt, 146 acpi_ev_sci_xrupt_handler, 147 acpi_gbl_gpe_xrupt_list_head); So it uses the acpi_glb_FADT.sci_interrupt. I think the best path is to stick a bunch of printks in drivers/acpi/osl.c in acpi_os_install_interrupt_handler and see what gsi, acpi_gbl_FADT.sci_interrupt, and what ''irq'' end up being.> > I''ve attached the /proc/interrupts dump for both kernel versions. The > difference to note is that IRQ 20 does appear in 2.6.32. > > Also attached is the xen dmesg.Ok, let me look at them in some more details. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-27 19:10 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 02:23:09AM +0800, Liwei wrote:> On 28 June 2011 01:33, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Hmm. Can you attach the full serial log and on the Linux kernel line have > > ''loglevel=10 debug initcall_debug'' please? > > See attached. > > > > > Is the serial log when running under 2.6.32 any different? (up to the ACPI interpretter > > blowing up)? What does the /proc/interrupts look under 2.6.32? > > There''s too much noise for me to compare, but I think they''re more or > less the same until the the interpreter blows up for 3.0 whereas > 2.6.32 does not.Another glance shows: (2.6.32): [ 3.502771] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) [ 3.502773] xen: sci override: source_irq=9 global_irq=20 trigger=c polarity=3 [ 3.502775] xen: registering gsi 20 triggering 0 polarity 1 [ 3.502780] alloc irq_desc for 20 on node 0 So it has IRQ 9 mapped to IRQ 20 while in 3.0: [ 3.803695] xen: --> pirq=7 -> irq=7 [ 3.803699] xen: --> pirq=8 -> irq=8 [ 3.803702] xen: --> pirq=10 -> irq=10 we skip over IRQ 9. We should have gotten something like this: [ 7.059735] xen_map_pirq_gsi: returning irq 20 for gsi 9 [ 7.064933] xen: --> pirq=20 -> irq=9 But we did not. If you can instrument ''acpi_get_override_irq'' to see at which of the numerous ''return -1'' it fails that might narrow down the issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 19:18 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 28 June 2011 03:10, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Another glance shows: > > (2.6.32): > [ 3.502771] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > [ 3.502773] xen: sci override: source_irq=9 global_irq=20 trigger=c polarity=3 > [ 3.502775] xen: registering gsi 20 triggering 0 polarity 1 > [ 3.502780] alloc irq_desc for 20 on node 0 > > So it has IRQ 9 mapped to IRQ 20 while in 3.0: > > [ 3.803695] xen: --> pirq=7 -> irq=7 > [ 3.803699] xen: --> pirq=8 -> irq=8 > [ 3.803702] xen: --> pirq=10 -> irq=10 > > we skip over IRQ 9. We should have gotten something like this: > > [ 7.059735] xen_map_pirq_gsi: returning irq 20 for gsi 9 > [ 7.064933] xen: --> pirq=20 -> irq=9 > > But we did not. If you can instrument ''acpi_get_override_irq'' to see > at which of the numerous ''return -1'' it fails that might narrow down > the issue. >Erm, do you want me to set up some kernel tracing or just add a printk to acpi_get_override_irq? My kernel hacking foo is very limited. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-27 19:30 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 03:18:21AM +0800, Liwei wrote:> On 28 June 2011 03:10, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Another glance shows: > > > > (2.6.32): > > [ 3.502771] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) > > [ 3.502773] xen: sci override: source_irq=9 global_irq=20 trigger=c polarity=3 > > [ 3.502775] xen: registering gsi 20 triggering 0 polarity 1 > > [ 3.502780] alloc irq_desc for 20 on node 0 > > > > So it has IRQ 9 mapped to IRQ 20 while in 3.0: > > > > [ 3.803695] xen: --> pirq=7 -> irq=7 > > [ 3.803699] xen: --> pirq=8 -> irq=8 > > [ 3.803702] xen: --> pirq=10 -> irq=10 > > > > we skip over IRQ 9. We should have gotten something like this: > > > > [ 7.059735] xen_map_pirq_gsi: returning irq 20 for gsi 9 > > [ 7.064933] xen: --> pirq=20 -> irq=9 > > > > But we did not. If you can instrument ''acpi_get_override_irq'' to see > > at which of the numerous ''return -1'' it fails that might narrow down > > the issue. > > > > Erm, do you want me to set up some kernel tracing or just add a printk > to acpi_get_override_irq? My kernel hacking foo is very limited.Just splash some printk''s around there and print out the values of gsi and pins. Nothing fancy. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 20:32 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
Sorry this took a while. Somehow make decided to recompile everything. Seems like the reason for IRQ 9 not being remapped is idx = -1. On 28 June 2011 03:30, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Tue, Jun 28, 2011 at 03:18:21AM +0800, Liwei wrote: >> On 28 June 2011 03:10, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> > >> > Another glance shows: >> > >> > (2.6.32): >> > [ 3.502771] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) >> > [ 3.502773] xen: sci override: source_irq=9 global_irq=20 trigger=c polarity=3 >> > [ 3.502775] xen: registering gsi 20 triggering 0 polarity 1 >> > [ 3.502780] alloc irq_desc for 20 on node 0 >> > >> > So it has IRQ 9 mapped to IRQ 20 while in 3.0: >> > >> > [ 3.803695] xen: --> pirq=7 -> irq=7 >> > [ 3.803699] xen: --> pirq=8 -> irq=8 >> > [ 3.803702] xen: --> pirq=10 -> irq=10 >> > >> > we skip over IRQ 9. We should have gotten something like this: >> > >> > [ 7.059735] xen_map_pirq_gsi: returning irq 20 for gsi 9 >> > [ 7.064933] xen: --> pirq=20 -> irq=9 >> > >> > But we did not. If you can instrument ''acpi_get_override_irq'' to see >> > at which of the numerous ''return -1'' it fails that might narrow down >> > the issue. >> > >> >> Erm, do you want me to set up some kernel tracing or just add a printk >> to acpi_get_override_irq? My kernel hacking foo is very limited. > > Just splash some printk''s around there and print out the values of gsi and pins. > Nothing fancy. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-27 21:09 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
Hmm, here''s the mapped IRQ list, interestingly IRQ 20 is on the list but not 9? [ 3.611820] acpi_get_override_irq: [ 3.611821] find_irq_entry: [ 3.611823] apic: 0 pin: 9 type: 0 mpc_ioapic_id: 8 MP_APIC_ALL: 255 [ 3.611825] i: 0 irqtype: 0 dstapic: 8 dstirq: 2 [ 3.611827] i: 1 irqtype: 0 dstapic: 8 dstirq: 20 [ 3.611829] i: 2 irqtype: 0 dstapic: 8 dstirq: 1 [ 3.611831] i: 3 irqtype: 0 dstapic: 8 dstirq: 3 [ 3.611833] i: 4 irqtype: 0 dstapic: 8 dstirq: 4 [ 3.611835] i: 5 irqtype: 0 dstapic: 8 dstirq: 5 [ 3.611836] i: 6 irqtype: 0 dstapic: 8 dstirq: 6 [ 3.611838] i: 7 irqtype: 0 dstapic: 8 dstirq: 7 [ 3.611840] i: 8 irqtype: 0 dstapic: 8 dstirq: 8 [ 3.611842] i: 9 irqtype: 0 dstapic: 8 dstirq: 10 [ 3.611844] i: 10 irqtype: 0 dstapic: 8 dstirq: 11 [ 3.611846] i: 11 irqtype: 0 dstapic: 8 dstirq: 12 [ 3.611848] i: 12 irqtype: 0 dstapic: 8 dstirq: 13 [ 3.611850] i: 13 irqtype: 0 dstapic: 8 dstirq: 14 [ 3.611852] i: 14 irqtype: 0 dstapic: 8 dstirq: 15 [ 3.611853] idx = -1 < 0, returning -1 On 28 June 2011 04:32, Liwei <xieliwei@gmail.com> wrote:> Sorry this took a while. Somehow make decided to recompile everything. > > Seems like the reason for IRQ 9 not being remapped is idx = -1. > > On 28 June 2011 03:30, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >> On Tue, Jun 28, 2011 at 03:18:21AM +0800, Liwei wrote: >>> On 28 June 2011 03:10, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: >>> > >>> > Another glance shows: >>> > >>> > (2.6.32): >>> > [ 3.502771] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) >>> > [ 3.502773] xen: sci override: source_irq=9 global_irq=20 trigger=c polarity=3 >>> > [ 3.502775] xen: registering gsi 20 triggering 0 polarity 1 >>> > [ 3.502780] alloc irq_desc for 20 on node 0 >>> > >>> > So it has IRQ 9 mapped to IRQ 20 while in 3.0: >>> > >>> > [ 3.803695] xen: --> pirq=7 -> irq=7 >>> > [ 3.803699] xen: --> pirq=8 -> irq=8 >>> > [ 3.803702] xen: --> pirq=10 -> irq=10 >>> > >>> > we skip over IRQ 9. We should have gotten something like this: >>> > >>> > [ 7.059735] xen_map_pirq_gsi: returning irq 20 for gsi 9 >>> > [ 7.064933] xen: --> pirq=20 -> irq=9 >>> > >>> > But we did not. If you can instrument ''acpi_get_override_irq'' to see >>> > at which of the numerous ''return -1'' it fails that might narrow down >>> > the issue. >>> > >>> >>> Erm, do you want me to set up some kernel tracing or just add a printk >>> to acpi_get_override_irq? My kernel hacking foo is very limited. >> >> Just splash some printk''s around there and print out the values of gsi and pins. >> Nothing fancy. >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-28 18:12 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 05:09:55AM +0800, Liwei wrote:> Hmm, here''s the mapped IRQ list, interestingly IRQ 20 is on the list but not 9?Looks like it. You are also in luck - I found a machine that has the same exact problem and while it does not bail out when installing the ACPI interpreter it does get the wrong IRQs for the rest of the devices. In other words, I can reproduce it here. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-28 18:33 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 02:12, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Tue, Jun 28, 2011 at 05:09:55AM +0800, Liwei wrote: >> Hmm, here''s the mapped IRQ list, interestingly IRQ 20 is on the list but not 9? > > Looks like it. You are also in luck - I found a machine that has the same > exact problem and while it does not bail out when installing the ACPI interpreter > it does get the wrong IRQs for the rest of the devices. > > In other words, I can reproduce it here. >Good to hear. Would you be able to CC me when you have a patch available so that I can test it out? I found out that the 3.0 kernel is somehow much more stable running windows HVMs, so I''d like to explore that. I''m subscribed to the devel list, but its hard effort keeping up with the email traffic from it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-28 19:27 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Tue, Jun 28, 2011 at 11:33:17AM -0700, Liwei wrote:> On 29 June 2011 02:12, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Tue, Jun 28, 2011 at 05:09:55AM +0800, Liwei wrote: > >> Hmm, here''s the mapped IRQ list, interestingly IRQ 20 is on the list but not 9? > > > > Looks like it. You are also in luck - I found a machine that has the same > > exact problem and while it does not bail out when installing the ACPI interpreter > > it does get the wrong IRQs for the rest of the devices. > > > > In other words, I can reproduce it here. > > > > Good to hear. > > Would you be able to CC me when you have a patch available so that IOf course.> can test it out? I found out that the 3.0 kernel is somehow much moreHere it is. diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index aac866e..09077b3 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -344,6 +344,7 @@ static int xen_register_pirq(u32 gsi, int triggering) struct physdev_map_pirq map_irq; int shareable = 0; char *name; + bool gsi_override = false; if (!xen_pv_domain()) return -1; @@ -360,11 +361,23 @@ static int xen_register_pirq(u32 gsi, int triggering) if (pirq < 0) goto out; - irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name); + /* We are installing the ACPI SCI */ + if (gsi == acpi_sci_override_gsi) { + /* Check whether the GSI != IRQ */ + acpi_gsi_to_irq(gsi, &irq); + printk(KERN_DEBUG "ACPI SCI GSI is %d, and ACPI IRQ thinks it is %d\n", gsi, irq); + if (irq != gsi) + /* Bugger, we MUST have that IRQ. */ + gsi_override = true; + } + if (gsi_override) + irq = xen_bind_pirq_gsi_to_irq(irq, pirq, shareable, name); + else + irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name); if (irq < 0) goto out; - printk(KERN_DEBUG "xen: --> pirq=%d -> irq=%d\n", pirq, irq); + printk(KERN_DEBUG "xen: --> pirq=%d -> gsi=%d -> irq=%d\n", pirq, gsi, irq); map_irq.domid = DOMID_SELF; map_irq.type = MAP_PIRQ_TYPE_GSI; @@ -414,6 +427,7 @@ static __init void xen_setup_acpi_sci(void) int rc; int trigger, polarity; int gsi = acpi_sci_override_gsi; + int irq = gsi; if (!gsi) return; @@ -426,12 +440,14 @@ static __init void xen_setup_acpi_sci(void) } trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE; polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH; - + + acpi_gsi_to_irq(gsi, &irq); + printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d " - "polarity=%d\n", gsi, trigger, polarity); + "polarity=%d irq %d\n", gsi, trigger, polarity, irq); gsi = xen_register_gsi(gsi, trigger, polarity); - printk(KERN_INFO "xen: acpi sci %d\n", gsi); + printk(KERN_INFO "xen: acpi sci %d -> irq %d\n", gsi, irq); return; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-28 19:49 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 03:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Here it is. >----snip---- Okay, that''s quick... The patch''s for 2.6.39 right? Seems to be slightly different in 3.0. May have to manually patch it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-28 19:51 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Wed, Jun 29, 2011 at 03:49:07AM +0800, Liwei wrote:> On 29 June 2011 03:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > Here it is. > > > ----snip---- > > Okay, that''s quick... > > The patch''s for 2.6.39 right? Seems to be slightly different in 3.0.Uh, it was against 3.0..> May have to manually patch it.<nods> Should be easy enough? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-28 19:55 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 03:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Wed, Jun 29, 2011 at 03:49:07AM +0800, Liwei wrote: >> ----snip---- >> >> Okay, that''s quick... >> >> The patch''s for 2.6.39 right? Seems to be slightly different in 3.0. > > Uh, it was against 3.0.. >> May have to manually patch it. > > <nods> Should be easy enough? >That''s weird.. looking at both Jeremy and your repos, the xen.c files from master and 3.0 are very different from the one the patch is based on. http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=blob;f=arch/x86/pci/xen.c;h=e6ad37e6b8c7aaad8216e6ae7e0786420a6f1eb8;hb=9b189285cb4030ea25f17cbe33946ce1f0ab7cd8 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-28 20:44 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On Wed, Jun 29, 2011 at 03:55:42AM +0800, Liwei wrote:> On 29 June 2011 03:51, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Wed, Jun 29, 2011 at 03:49:07AM +0800, Liwei wrote: > >> ----snip---- > >> > >> Okay, that''s quick... > >> > >> The patch''s for 2.6.39 right? Seems to be slightly different in 3.0. > > > > Uh, it was against 3.0.. > >> May have to manually patch it. > > > > <nods> Should be easy enough? > > > > That''s weird.. looking at both Jeremy and your repos, the xen.c files > from master and 3.0 are very different from the one the patch is based > on.Oh, you are using my branch! I was thinking you were using the 3.0-rc4 virgin kernel (ie, from ftpkernel.org) There are some cleanups in there. Try this patch instead: commit c79ba10a5de908ae48643a9a0d74bc6da3cb4b66 Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Tue Jun 28 15:48:38 2011 -0400 xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ. In the past we would use the GSI value to preset the ACPI SCI IRQ which worked great as GSI == IRQ: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) While that is most often seen, there are some oddities: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) which means that GSI 20 (or pin 20) is to be override for IRQ 9. Our code that presets the interrupt for ACPI SCI however would use the GSI 20 instead of IRQ 9 ending up with: xen: sci override: global_irq=20 trigger=0 polarity=1 xen: registering gsi 20 triggering 0 polarity 1 xen: --> pirq=20 -> irq=20 xen: acpi sci 20 .. snip.. calling acpi_init+0x0/0xbc @ 1 ACPI: SCI (IRQ9) allocation failed ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119) ACPI: Unable to start the ACPI Interpreter as the ACPI interpreter made a call to ''acpi_gsi_to_irq'' which got the value 9 returned. It used that value to request the IRQ 9 and since it was not preset it would fail. The fix is to recognize that for interrupts that are overriden (in our case we only care about the ACPI SCI) we should use the IRQ number to present the IRQ instead of the using GSI. End result is that we get: xen: sci override: global_irq=20 trigger=0 polarity=1 xen: registering gsi 20 triggering 0 polarity 1 xen: --> pirq=20 -> irq=9 (gsi=9) xen: acpi sci 9 which fixes the ACPI interpreter failing. Reported-by: Liwei <xieliwei@gmail.com> [http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index e6ad37e..62a08d9 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -93,11 +93,29 @@ static int xen_register_pirq(u32 gsi, int triggering, bool alloc_pirq) name = "ioapic-level"; } + /* Before we bind the GSI to a Linux IRQ, check whether + * we need to override it with bus_irq (IRQ) value. Usually for + * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so: + * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) + * but there are oddballs where the IRQ != GSI: + * ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) + * which ends up being: gsi_to_irq[9] == 20 + * (which is what acpi_gsi_to_irq ends up calling when starting the + * the ACPI interpreter and keels over since IRQ 9 has not been + * setup as we had setup IRQ 20 for it). + */ + if (acpi_sci_override_gsi == gsi) { + acpi_gsi_to_irq(gsi, &irq); + if (gsi != irq) + /* Bugger, we MUST have that IRQ! */ + gsi = irq; + } irq = xen_bind_pirq_gsi_to_irq(gsi, map_irq.pirq, shareable, name); if (irq < 0) goto out; - printk(KERN_DEBUG "xen: --> pirq=%d -> irq=%d\n", pirq, map_irq.pirq); + printk(KERN_DEBUG "xen: --> pirq=%d -> irq=%d (gsi=%d)\n", + map_irq.pirq, irq, gsi); out: return irq; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-29 13:09 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 04:44, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> > Oh, you are using my branch! I was thinking you were using the 3.0-rc4 virgin > kernel (ie, from ftpkernel.org)Hmm, I''ve always wondered, which would be a better choice for a Dom0 kernel? I''ve always thought Jeremy''s and yours would be better since they have xen specific patches/bug fixes. Is there a reason to favour the vanilla kernels?> > There are some cleanups in there. Try this patch instead: >----snip---- Sweet! The patch works perfectly and I''ve upgraded to 3.0 and the latest xen. PCI passthrough on windows HVM is very stable too (used to crash every few hours, and sound goes crazy after a while), up for almost 12 hours with no issues. Thanks! =) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-29 13:37 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 21:09, Liwei <xieliwei@gmail.com> wrote: ----snip----> Sweet! The patch works perfectly and I''ve upgraded to 3.0 and the > latest xen. PCI passthrough on windows HVM is very stable too (used to > crash every few hours, and sound goes crazy after a while), up for > almost 12 hours with no issues. > > Thanks! =) >Also, a minor note, I noticed that on 2.6.39 and above, the pci-list-assignable-devices command is not working, but PCI passthrough works nonetheless: # xm pci-list-assignable-devices Error: pciback/pci-stub not loaded? # xl pci-list-assignable-devices libxl: error: libxl_pci.c:509:libxl_device_pci_list_assignable: Looks like pciback driver not loaded _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Wilk
2011-Jun-29 14:23 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
----- xieliwei@gmail.com wrote:> On 29 June 2011 04:44, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > wrote: > > > > Oh, you are using my branch! I was thinking you were using the > 3.0-rc4 virgin > > kernel (ie, from ftpkernel.org) > > Hmm, I''ve always wondered, which would be a better choice for a Dom0 > kernel? I''ve always thought Jeremy''s and yours would be better since > they have xen specific patches/bug fixes. Is there a reason to favourWe have "earlier" patches. Meaning the #master branches has patches that are going to be in proposed for 3.1. So you get the extra fancy stuff before it is integrated in the vanilla.> the vanilla kernels?Mostly just separation of patches. The "extra fancy stuff" could bring in bugs so if you use the vanilla kernel you would not trip over them. And the #master in my case did have some extra fancy stuff in the Xen PCI - so I was trying to isolate whether the issue you were tripping over was the fault of the new code or something that has been in there since 2.6.37. It was the latter. Besides that - in the past we had a backlog of patches to make Xen work nicely - but almost all (except the #stable/vga.support) are in the upstream kernel. So it is more of "stable" (vanilla) vs "development" (our #master or #devel/next-3.0 branches).> > > > > There are some cleanups in there. Try this patch instead: > > > ----snip---- > > Sweet! The patch works perfectly and I''ve upgraded to 3.0 and theGreat. Is it OK if I stick ''Tested-by:'' on the patch?> latest xen. PCI passthrough on windows HVM is very stable too (used > to > crash every few hours, and sound goes crazy after a while), up for > almost 12 hours with no issues. > > Thanks! =)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Liwei
2011-Jun-29 15:20 UTC
Re: [Xen-devel] Re: "ACPI: Unable to start the ACPI Interpreter"
On 29 June 2011 22:23, Konrad Wilk <konrad.wilk@oracle.com> wrote:> > ----- xieliwei@gmail.com wrote: > >> Hmm, I''ve always wondered, which would be a better choice for a Dom0 >> kernel? I''ve always thought Jeremy''s and yours would be better since >> they have xen specific patches/bug fixes. Is there a reason to favour > > We have "earlier" patches. Meaning the #master branches has patches > that are going to be in proposed for 3.1. So you get the extra fancy stuff before it is > integrated in the vanilla. > >> the vanilla kernels? > > Mostly just separation of patches. The "extra fancy stuff" could bring in > bugs so if you use the vanilla kernel you would not trip over them. > And the #master in my case did have some extra fancy stuff in the Xen PCI - so > I was trying to isolate whether the issue you were tripping over was the fault > of the new code or something that has been in there since 2.6.37. It was the latter. > > Besides that - in the past we had a backlog of patches to make Xen work nicely - > but almost all (except the #stable/vga.support) are in the upstream kernel. > > So it is more of "stable" (vanilla) vs "development" (our #master or #devel/next-3.0 > branches).Alright, understood. Thanks for explaining!>> Sweet! The patch works perfectly and I''ve upgraded to 3.0 and the > > Great. Is it OK if I stick ''Tested-by:'' on the patch? >I have only two systems to test on and didn''t really do any complicated testing other than load testing and verifying that the correct IRQ number for SCI is used, but the patch is a simple and straightforward one, so I guess if you''re okay with it, I''m okay too. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel