> > Thanks for the report, Michael, and sorry for the inconvenience. I think
> > the patch below will fix it, but I don't think it's the right fix either
> > because it seems a little ad hoc to sprinkle "acpi_pci_disabled" tests
> > around like fairy dust. I wonder if we can set things up so ACPI methods
> > would fail gracefully like they do when ACPI is disabled at compile-time.
> >
> > I can boot with "acpi=off" on qemu just fine, and when we look up the ACPI
> > device handles, we just get NULL pointers, so everything works out even
> > without a fix like the one below.
>
> <nods>
> >
> > There must be something different about the way things get set up in that
> > domU kernel. I'll try to look into that some more, but I'm going on
> > vacation for the next week, so if you learn anything before then, let me
> > know.
>
> And I don't see where 'resume_kernel' gets called.
>
>
> And under my PV guest I see:
> # lspci
> 00:00.0 USB Controller: NEC Corporation Device 0194 (rev 04)
> 00:01.0 USB Controller: NEC Corporation Device 0194 (rev 03)
>
> when the guest boots up. Hm, what kind of cards are these?
> Could you also provide the config file and the guest config please?
It helps when I boot an proper kernel (I had booted 3.16 by mistake).
With the 4.0 kernel I see this as well:
[ 4.059387] pci 0000:00:00.0: reg 0x10: [mem 0xfbd00000-0xfbd01fff 64bit]
[ 4.114184] BUG: unable to handle kernel paging request at 0030303e
[ 4.114199] IP: [<c1379c1c>] acpi_ns_validate_handle+0x1c/0x26
[ 4.114216] *pdpt = 0000000000000000 *pde = c2c2c2c2c2c2c2c2
[ 4.114230] Oops: 0000 [#1] SMP
[ 4.114241] Modules linked in:
[ 4.114252] CPU: 0 PID: 22 Comm: xenwatch Not tainted 4.0.0-rc5upstream-00070-g3a88f16 #1
[ 4.114268] task: dd557370 ti: dd55a000 task.ti: dd55a000
[ 4.114278] EIP: e019:[<c1379c1c>] EFLAGS: 00010246 CPU: 0
[ 4.114289] EIP is at acpi_ns_validate_handle+0x1c/0x26
[ 4.114299] EAX: 00000000 EBX: 0030303a ECX: 00000000 EDX: 00000000
[ 4.114310] ESI: dd66e7c0 EDI: 0030303a EBP: dd55bcd8 ESP: dd55bcd4
[ 4.114322] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
[ 4.114334] CR0: 80050033 CR2: 0030303e CR3: 019a4000 CR4: 00042660
[ 4.114347] Stack:
[ 4.114354] c17ae853 dd55bd14 c137ae18 00000010 c1a602c0 dd55bcf0 c109ae9a dd55bcfc
[ 4.114376] c13a9c57 deadbeef dd55bd50 00000000 deadbeef 0030303a dd55bd78 dd55bdd0
[ 4.114397] dd55bd58 c1336d90 dd55bd40 0000007b 0000007b 000000d8 dd55bd94 dd55bd8c
[ 4.114419] Call Trace:
[ 4.114429] [<c137ae18>] acpi_evaluate_object+0x6f/0x366
[ 4.114443] [<c109ae9a>] ? irq_exit+0x4a/0xc0
[ 4.114456] [<c13a9c57>] ? xen_evtchn_do_upcall+0x27/0x40
[ 4.114468] [<c1336d90>] pci_get_hp_params+0x110/0x4b0
[ 4.114480] [<c1316436>] pci_device_add+0x26/0x450
[ 4.114494] [<c10409db>] ? xen_restore_fl_direct_reloc+0x4/0x4
[ 4.115132] [<c16509c6>] ? _raw_spin_unlock_irqrestore+0x16/0x40
[ 4.115132] [<c13171eb>] pci_scan_single_device+0x8b/0xb0
[ 4.115132] [<c1317253>] pci_scan_slot+0x43/0x100
[ 4.115132] [<c1317cfc>] pci_scan_child_bus+0x1c/0xa0
[ 4.115132] [<c1318254>] pci_scan_bus_parented+0x64/0x90
[ 4.115132] [<c1337730>] pcifront_scan_root+0x90/0x120
[ 4.115132] [<c164b8e5>] pcifront_backend_changed+0x475/0x63c
[ 4.115132] [<c164b200>] ? kmemleak_free+0x20/0x50
[ 4.115132] [<c119ec9d>] ? kfree+0x7d/0x100
[ 4.115132] [<c13a028d>] ? __cleanup+0xfd/0x180
[ 4.115132] [<c13ae28d>] ? xenbus_gather+0x5d/0x90
[ 4.115132] [<c13ac475>] ? xenbus_read_driver_state+0x35/0x50
[ 4.115132] [<c13af3cd>] xenbus_otherend_changed+0x7d/0x80
[ 4.115132] [<c13b0bf2>] backend_changed+0x12/0x20
[ 4.115132] [<c13adb12>] xenwatch_thread+0x72/0x120
[ 4.115132] [<c10ccc00>] ? woken_wake_function+0x20/0x20
[ 4.115132] [<c10b10bc>] kthread+0xac/0xd0
[ 4.115132] [<c13adaa0>] ? xenbus_transaction_start+0x60/0x60
[ 4.115132] [<c1650fc1>] ret_from_kernel_thread+0x21/0x30
[ 4.115132] [<c10b1010>] ? kthread_freezable_should_stop+0x60/0x60
[ 4.115132] Code: 4f b2 00 00 31 c0 83 c4 2c 5b 5e 5f 5d c3 90 55 89 e5 53 89 c3 e8 45 b0 00 00 8d 43 ff 83 f8 fd 76 07 a1 20 80 a6 c1 eb 09 31 c0 <80> 7b 04 0f 0f 44 c3 5b 5d c3 55 89 e5 53 89 c3 e8 1f b0 00 00
[ 4.115132] EIP: [<c1379c1c>] acpi_ns_validate_handle+0x1c/0x26 SS:ESP e021:dd55bcd4
[ 4.115132] CR2: 000000000030303e
[ 4.115132] ---[ end trace 21d8bfe52b77b825 ]---
[ 4.115132] Kernel panic - not syncing: Fatal exception
[ 4.115132] Kernel Offset: 0x0 from 0xc1000000 (relocation range: 0xc0000000-0xedbfdfff)
The interesting thing is that under 64-bit kernels I see this:
[ 3.304732] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]^M
[ 3.304748] pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff]^M
[ 3.304764] pci_bus 0000:00: root bus resource [bus 00-ff]^M
[ 3.305023] pci 0000:00:00.0: [1033:0194] type 00 class 0x0c0330^M
[ 3.322181] pci 0000:00:00.0: reg 0x10: [mem 0xfbd00000-0xfbd01fff 64bit]^M
[ 3.377359] ACPI Exception: AE_BAD_PARAMETER, Thread 520623344 could not acquire Mutex [0x1] (20150204/utmutex-285)^M
[ 3.377379] ACPI Exception: AE_BAD_PARAMETER, Thread 520623344 could not acquire Mutex [0x1] (20150204/utmutex-285)^M
[ 3.379202] pci 0000:00:01.0: [1033:0194] type 00 class 0x0c0330^M
[ 3.396282] pci 0000:00:01.0: reg 0x10: [mem 0xfba00000-0xfba01fff 64bit]^M
[ 3.451422] ACPI Exception: AE_BAD_PARAMETER, Thread 520623344 could not acquire Mutex [0x1] (20150204/utmutex-285)^M
[ 3.451440] ACPI Exception: AE_BAD_PARAMETER, Thread 520623344 could not acquire Mutex [0x1] (20150204/utmutex-285)^M
[ 3.456133] pcifront pci-0: claiming resource 0000:00:00.0/0^M
[ 3.456147] pcifront pci-0: claiming resource 0000:00:01.0/0^M
[ 3.456461] pci 0000:00:00.0: Xen PCI mapped GSI18 to IRQ25^M
>
> Thank you!
>
> >
> > Bjorn
> >
> >
> > commit 6678b0fb6504c890481863b4916089b41e6042bf
> > Author: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > Date: Tue Mar 24 11:12:45 2015 -0500
> >
> > PCI: Don't look for ACPI hotplug parameters if ACPI is disabled
> >
> > In a kernel with CONFIG_ACPI=y, pci_get_hp_params() evaluates ACPI methods
> > (_HPX, _HPP, etc.) to learn how to configure devices. If ACPI has been
> > disabled at runtime, e.g., with "acpi=off", this causes an oops because
> > there's no AML at all.
> >
> > Before 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration"),
> > we only used pci_get_hp_params() for hot-added devices, but after it, we
> > use it for all devices, so we're much more likely to see the oops.
> >
> > Don't bother looking for ACPI configuration information if ACPI has been
> > disabled.
> >
> > Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
> > Reported-by: Michael D Labriola <mlabriol@xxxxxxxx>
> > Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > CC: stable@xxxxxxxxxxxxxxx # v3.18+
> >
> > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> > index 489063987325..c93fbe76d281 100644
> > --- a/drivers/pci/pci-acpi.c
> > +++ b/drivers/pci/pci-acpi.c
> > @@ -248,6 +248,9 @@ int pci_get_hp_params(struct pci_dev *dev, struct hotplug_params *hpp)
> > acpi_handle handle, phandle;
> > struct pci_bus *pbus;
> >
> > + if (acpi_pci_disabled)
> > + return -ENODEV;
> > +
> > handle = NULL;
> > for (pbus = dev->bus; pbus; pbus = pbus->parent) {
> > handle = acpi_pci_get_bridge_handle(pbus);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
