From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Sent: Thursday, July 3, 2025 2:22 PM > > On Thu, Jul 03 2025 at 20:15, Michael Kelley wrote: > > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Sent: Thursday, July 3, 2025 1:00 PM > >> Does it conflict against the PCI tree? > > > > There's no conflict in the "next" or "for-linus" tags in > > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/ > > > > The conflict is with Patch 2 of this series: > > > > https://lore.kernel.org/linux-hyperv/1749650984-9193-1-git-send-email-shradhagupta@xxxxxxxxxxxxxxxxxxx/ > > > > which is in netdev/net-next. > > That's a trivial one. There are two ways to handle it: > > 1) Take it through the PCI tree and provide a conflict resolution for > linux-next and later for Linus as reference. > > 2) Route it through the net-next tree with an updated patch. > > As there are no further dependencies (aside of the missing export which > is needed anyway) it's obvious to pick #2 as it creates the least > headaches. Assumed that the PCI folks have no objections. > > Michael, as you have resolved the conflict already, can you please > either take care of it yourself or provide the resolution here as > reference for Nam? I haven't resolved the conflict. As a shortcut for testing I just removed the conflicting patch since it is for a Microsoft custom NIC ("MANA") that's not in the configuration I'm testing with. I'll have to look more closely to figure out the resolution. Separately, this patch (the switch to misc_create_parent_irq_domain) isn't working for Linux VMs on Hyper-V on ARM64. The initial symptom is that interrupts from the NVMe controller aren't getting handled and everything hangs. Here's the dmesg output: [ 84.463419] hv_vmbus: registering driver hv_pci [ 84.463875] hv_pci abee639e-0b9d-49b7-9a07-c54ba8cd5734: PCI VMBus probing: Using version 0x10004 [ 84.464518] hv_pci abee639e-0b9d-49b7-9a07-c54ba8cd5734: PCI host bridge to bus 0b9d:00 [ 84.464529] pci_bus 0b9d:00: root bus resource [mem 0xfc0000000-0xfc00fffff window] [ 84.464531] pci_bus 0b9d:00: No busn resource found for root bus, will use [bus 00-ff] [ 84.465211] pci 0b9d:00:00.0: [1414:b111] type 00 class 0x010802 PCIe Endpoint [ 84.466657] pci 0b9d:00:00.0: BAR 0 [mem 0xfc0000000-0xfc00fffff 64bit] [ 84.481923] pci_bus 0b9d:00: busn_res: [bus 00-ff] end is updated to 00 [ 84.481936] pci 0b9d:00:00.0: BAR 0 [mem 0xfc0000000-0xfc00fffff 64bit]: assigned [ 84.482413] nvme nvme0: pci function 0b9d:00:00.0 [ 84.482513] nvme 0b9d:00:00.0: enabling device (0000 -> 0002) [ 84.556871] irq 17, desc: 00000000e8529819, depth: 0, count: 0, unhandled: 0 [ 84.556883] ->handle_irq(): 0000000062fa78bc, handle_bad_irq+0x0/0x270 [ 84.556892] ->irq_data.chip(): 00000000ba07832f, 0xffff00011469dc30 [ 84.556895] ->action(): 0000000069f160b3 [ 84.556896] ->action->handler(): 00000000e15d8191, nvme_irq+0x0/0x3e8 [ 172.307920] watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [kworker/6:1H:195] Everything looks normal up to the "irq 17" line. Meanwhile, the device probe path is waiting with this stack trace, which I suspect is the first Interaction with the NVMe controller: [<0>] blk_execute_rq+0x1ec/0x348 [<0>] nvme_execute_rq+0x20/0x68 [<0>] __nvme_submit_sync_cmd+0xc8/0x170 [<0>] nvme_identify_ctrl.isra.0+0x90/0xf0 [<0>] nvme_init_identify+0x44/0xee0 [<0>] nvme_init_ctrl_finish+0x84/0x370 [<0>] nvme_probe+0x668/0x7d8 [<0>] local_pci_probe+0x48/0xd0 [<0>] pci_device_probe+0xd0/0x248 [<0>] really_probe+0xd4/0x388 [<0>] __driver_probe_device+0x90/0x1a8 [<0>] driver_probe_device+0x48/0x150 [<0>] __device_attach_driver+0xe0/0x1b8 [<0>] bus_for_each_drv+0x8c/0xf8 [<0>] __device_attach+0x104/0x1e8 [<0>] device_attach+0x1c/0x30 [<0>] pci_bus_add_device+0xe0/0x188 [<0>] pci_bus_add_devices+0x40/0x98 [<0>] hv_pci_probe+0x4b0/0x690 [pci_hyperv] [<0>] vmbus_probe+0x4c/0xb0 [hv_vmbus] [<0>] really_probe+0xd4/0x388 [<0>] __driver_probe_device+0x90/0x1a8 [<0>] driver_probe_device+0x48/0x150 [<0>] __driver_attach+0xe8/0x1c8 [<0>] bus_for_each_dev+0x80/0xf0 [<0>] driver_attach+0x2c/0x40 [<0>] bus_add_driver+0x118/0x260 [<0>] driver_register+0x68/0x138 [<0>] __vmbus_driver_register+0x70/0x98 [hv_vmbus] [<0>] init_hv_pci_drv+0x1b8/0xfff8 [pci_hyperv] [<0>] do_one_initcall+0x4c/0x2c8 [<0>] do_init_module+0x60/0x280 [<0>] load_module+0x2318/0x2448 [<0>] init_module_from_file+0x94/0xe0 [<0>] __arm64_sys_finit_module+0x228/0x3e8 [<0>] invoke_syscall+0x6c/0xf8 [<0>] el0_svc_common.constprop.0+0xc8/0xf0 [<0>] do_el0_svc+0x24/0x38 [<0>] el0_svc+0x40/0x1a0 [<0>] el0t_64_sync_handler+0xd0/0xe8 [<0>] el0t_64_sync+0x1b0/0x1b8 I'll try to figure out what's going wrong. Michael
