[{"id":3675774,"web_url":"http://patchwork.ozlabs.org/comment/3675774/","msgid":"","list_archive_url":null,"date":"2026-04-10T10:09:00","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Thu, 9 Apr 2026, Geramy Loveless wrote:\n\n> When pbus_reassign_bridge_resources() walks up the bridge hierarchy\n> to expand a window (e.g. for resizable BAR), it refuses to release\n> any bridge window that has children. This prevents BAR resize on\n> devices behind multi-port PCIe switches (such as Thunderbolt docks)\n> where empty sibling downstream ports hold small reservations that\n> block the parent bridge window from being freed and re-sized.\n> \n> Add pci_bus_subtree_empty() to check whether a bus subtree contains\n> any assigned device BARs, and pci_bus_release_empty_bridges() to\n> release bridge window resources of empty sibling bridges, saving\n> them to the rollback list so failures can be properly unwound.\n> \n> In pbus_reassign_bridge_resources(), call pci_bus_release_empty_bridges()\n> before checking res->child, so empty sibling windows are cleared first\n> and the parent window can then be released and grown.\n> \n> Uses PCI bus/device iterators rather than walking the raw resource\n> tree, which avoids issues with stale sibling pointers after resource\n> release.\n\nThis paragraph can be dropped. And it's not exactly correct either as \nthe pointers are only stale for resource entries that reside outside of \nthe resource tree (after they've been released in a specific way) so if \nyou start from a resource tree entry, you should never encounter a stale \npointer.\n\n> Suggested-by: Ilpo Järvinen \n> Signed-off-by: Geramy Loveless \n> ---\n> drivers/pci/setup-bus.c | 99 ++++++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 97 insertions(+), 2 deletions(-)\n> \n> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> index 4cf120ebe5a..7a182cd7e4d 100644\n> --- a/drivers/pci/setup-bus.c\n> +++ b/drivers/pci/setup-bus.c\n> @@ -2292,6 +2292,94 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)\n> }\n> EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> \n> +/*\n> + * pci_bus_subtree_empty - Check whether a bus subtree has any assigned\n> + * non-bridge device resources.\n> + * @bus: PCI bus to check\n> + *\n> + * Returns true if no device on @bus or its descendant buses has any\n> + * assigned BARs (bridge window resources are not considered).\n> + */\n> +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> +{\n> +\tstruct pci_dev *dev;\n> +\n> +\tlist_for_each_entry(dev, &bus->devices, bus_list) {\n> +\t\tstruct resource *r;\n> +\t\tunsigned int i;\n> +\n> +\t\tpci_dev_for_each_resource(dev, r, i) {\n> +\t\t\tif (i >= PCI_BRIDGE_RESOURCES)\n> +\t\t\t\tbreak;\n> +\t\t\tif (resource_assigned(r))\n> +\t\t\t\treturn false;\n> +\t\t}\n> +\n> +\t\tif (dev->subordinate &&\n> +\t\t !pci_bus_subtree_empty(dev->subordinate))\n> +\t\t\treturn false;\n> +\t}\n> +\n> +\treturn true;\n> +}\n> +\n> +/*\n> + * pci_bus_release_empty_bridges - Release bridge window resources of\n> + * empty sibling bridges so the parent window can be freed and re-sized.\n> + * @bus: PCI bus whose child bridges to scan\n> + * @b_win: Parent bridge window resource; only children of this window\n> + * are released\n> + * @saved: List to save released resources for rollback\n> + *\n> + * For each PCI-to-PCI bridge on @bus whose subtree is empty (no assigned\n> + * device BARs), releases bridge window resources that are children of\n> + * @b_win, saving them for rollback via @saved.\n> + *\n> + * Returns 0 on success, negative errno on failure.\n> + */\n> +static int pci_bus_release_empty_bridges(struct pci_bus *bus,\n> +\t\t\t\t\t struct resource *b_win,\n> +\t\t\t\t\t struct list_head *saved)\n> +{\n> +\tstruct pci_dev *dev;\n> +\n> +\tlist_for_each_entry(dev, &bus->devices, bus_list) {\n> +\t\tstruct resource *r;\n> +\t\tunsigned int i;\n> +\n> +\t\tif (!dev->subordinate)\n> +\t\t\tcontinue;\n> +\n> +\t\tif ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)\n> +\t\t\tcontinue;\n\nI suppose dev->subordinate check is enough for what we're doing so this \nlooks redundant.\n\n> +\n> +\t\tif (!pci_bus_subtree_empty(dev->subordinate))\n> +\t\t\tcontinue;\n> +\n> +\t\tpci_dev_for_each_resource(dev, r, i) {\n> +\t\t\tint ret;\n> +\n> +\t\t\tif (!pci_resource_is_bridge_win(i))\n> +\t\t\t\tcontinue;\n> +\n> +\t\t\tif (!resource_assigned(r))\n> +\t\t\t\tcontinue;\n> +\n> +\t\t\tif (r->parent != b_win)\n> +\t\t\t\tcontinue;\n> +\n> +\t\t\tret = pci_dev_res_add_to_list(saved, dev, r, 0, 0);\n> +\t\t\tif (ret)\n> +\t\t\t\treturn ret;\n> +\n> +\t\t\trelease_child_resources(r);\n\nUnfortunately you cannot call this low-level function because it \nrecursively frees child resources which means you won't be able to \nrollback them as they were not added to the saved list.\n\nI think the release algorithm should basically do this:\n\n- Recurse to the subordinate buses\n- Loop through bridge window resources of this bus\n\t- Skip resources that are not assigned or are not parented by b_win\n\t- If the resource still has childs, leave the resource alone\n\t (+ log it for easier troubleshooting these cases; any failure\n\t will also cascade to upstream so it may be possible to \n\t shortcut something but it will also make the algorithm more\n\t complicated)\n\t- Save and free the resource\n\nIt might be better to move some of the code from \npbus_reassign_bridge_resources() here as there's overlap with the sketched \nalgorithm (but I'm not sure until I see the updated version but keep this \nin mind).\n\nDoing pci_bus_subtree_empty() before any removal is fine with me, but I \nsee it just an optimization.\n\n> +\t\t\tpci_release_resource(dev, i);\n> +\t\t}\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +\n> /*\n> * Walk to the root bus, find the bridge window relevant for @res and\n> * release it when possible. If the bridge window contains assigned\n> @@ -2316,7 +2404,14 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> \n> \t\ti = pci_resource_num(bridge, res);\n> \n> -\t\t/* Ignore BARs which are still in use */\n\nI don't know why you removed this comment (I admit though \"BARs\" could \nhave been worded better as it's bridge windows we're dealing here).\n\n> +\t\t/* Release empty sibling bridge windows first */\n> +\t\tif (bridge->subordinate) {\n> +\t\t\tret = pci_bus_release_empty_bridges(\n> +\t\t\t\t\tbridge->subordinate, res, saved);\n\nFirst arg fits to the previous line.\n\nAlign the second line to (.\n\nBut consider also rearranging code as I mentioned above.\n\n> +\t\t\tif (ret)\n> +\t\t\t\treturn ret;\n\nConsider proceeding with the resize even if something failed as there are \ncases where the bridge windows are large enough (admittedly, you seem to \nonly bail out in case of alloc error).\n\nIn to the same vein, there seems to be one existing goto restore (that was \nadded by me), which could also probably do continue instead (but changing \nit would be worth another patch).\n\n> +\t\t}\n> +\n> \t\tif (!res->child) {\n> \t\t\tret = pci_dev_res_add_to_list(saved, bridge, res, 0, 0);\n> \t\t\tif (ret)\n> @@ -2327,7 +2422,7 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> \t\t\tconst char *res_name = pci_resource_name(bridge, i);\n> \n> \t\t\tpci_warn(bridge,\n> -\t\t\t\t \"%s %pR: was not released (still contains assigned resources)\\n\",\n> +\t\t\t\t \"%s %pR: not released, active children present\\n\",\n> \t\t\t\t res_name, res);\n> \t\t}\n> \n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=hkMKkJmw;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52290-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"hkMKkJmw\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.11","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsXdC6CBsz1y2d\n\tfor ; Fri, 10 Apr 2026 20:11:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id AC56D300424D\n\tfor ; Fri, 10 Apr 2026 10:09:13 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 3AA10377EC1;\n\tFri, 10 Apr 2026 10:09:11 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.11])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F06D342510\n\tfor ; Fri, 10 Apr 2026 10:09:09 +0000 (UTC)","from orviesa010.jf.intel.com ([10.64.159.150])\n by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 03:09:08 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.244.118])\n by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 03:09:05 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775815751; cv=none;\n b=ANT4k3HGZDGAMbUk9LOYEGp7jbeAHdbjj/QMkkR1ZGrnaIKEb/gJtGCA7Ozwt0jgpg01ZeoPukNd/mFLrc4noraV6cPwcEdxMT1uNREDPvJ6/KBKAUPvDggghXuwCsx8PkexQdAECRYEM3UD2s4C4vT3LT2sRqdfHI6BRMdukHo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775815751; c=relaxed/simple;\n\tbh=b7pY61ZvOSbQtCy8Bvp7KRnn/GfSyA5IPs1slpsXUFU=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=bKwXYLl7omSL+232hy89+4/90RBdtbtHsM04jO06IdnN8xVwhDcYkvnVuthVv7+R9QU22Im/NGcJS8UoL0YABjrbB/YHvyGFZvAcarLEiPRGuq3TdjY/DBz3YXjo+x6U23x0WpzCxE/+2XLKXayl3O1aMCosul0Cl5P37rsXmAc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=hkMKkJmw; arc=none smtp.client-ip=192.198.163.11","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1775815749; x=1807351749;\n h=from:date:to:cc:subject:in-reply-to:message-id:\n references:mime-version;\n bh=b7pY61ZvOSbQtCy8Bvp7KRnn/GfSyA5IPs1slpsXUFU=;\n b=hkMKkJmwwEGSuUoCRgqSMCM7cQcPg/neayZo3IrvpUWRQZKW7di5npA/\n y2l3unatsEUagI8todjBlC0ZdMTwckm7kSr/ALL0VN2u682PnbEXU8AkL\n Hg7JZLRH0cqbAf4dqx2JzfJc+1yfdbP+IL3s5Lk7yqXxJtsb75c45Rj7Q\n nlbKSLzd/SKrND+XUSXKAJbtS/Qc77dI5SHxMQOzDq9qhjxW4R/shF7KM\n BVV43uHrPTf96BiuUl8dwaavD/zaicINpfIeEBNzG/mqKxvIrK3/uxPWC\n XgcJaLa67Q2rpVDeDw3qIr8Dl0hMjWfMM+dobdqJhG5DTlEL7Cvztj2ho\n w==;","X-CSE-ConnectionGUID":["8c6GPryFQBuTBvYX2zNT4g==","z6MNtYYxQu2sG9blz5X8lg=="],"X-CSE-MsgGUID":["UirCBcR3RxqwgwMXKp8Uig==","jNrmVPPRSSmtN1wpgx0Y+g=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11754\"; a=\"87461878\"","E=Sophos;i=\"6.23,171,1770624000\";\n d=\"scan'208\";a=\"87461878\"","E=Sophos;i=\"6.23,171,1770624000\";\n d=\"scan'208\";a=\"228207051\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Date":"Fri, 10 Apr 2026 13:09:00 +0300 (EEST)","To":"Geramy Loveless ","cc":"linux-pci@vger.kernel.org, cristi@ieee.org","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","In-Reply-To":"<20260410052918.5556-2-gloveless@jqluv.com>","Message-ID":"","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"8323328-1033624320-1775815741=:1195\""}},{"id":3675999,"web_url":"http://patchwork.ozlabs.org/comment/3675999/","msgid":"","list_archive_url":null,"date":"2026-04-10T17:53:12","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":93094,"url":"http://patchwork.ozlabs.org/api/people/93094/","name":"Geramy Loveless","email":"gloveless@jqluv.com"},"content":"I'm going to loop in Christian Koenig over at AMD he has been working\nwith me on resolving or attempting to figure out whats going on with\nmy gfx1201 connected to a tb5 dock to the host.\nI am currently having problems with the GPU basically loosing MMIO and\ncrashing randomly. This recent patch change I believe helped but its\nreally hard to say at this point.\nWithout this patch of course the bar size would be 256MB and cause\nhuge performance problems or feature loss. I am able to load up AI\nmodels and run workloads at nearly 100% gpu usage, i'm seeing 205W\npower draw out of the maximum 300W. But after sustained load I still\nget a crash.\n\nMaybe you would have an idea as to what is causing that crash or where\nI should be looking to find the cause?\nHere are some relevant logs, from what I can tell something is going\non with MMIO, but the config bar as i understand it is still alive.\nThis let me to believe maybe the router was getting put into suspend\nmode which wouldnt make sense for a GPU that is active and busy\nbecause the pcie tunnel would be active.\n\nAny advice or tips would be helpful thank you for the suggestions I\nwill get started on writing the patch based on those recommendations.\n\n## SMU Firmware Version\n\n```\nsmu driver if version = 0x0000002e\nsmu fw if version = 0x00000032\nsmu fw program = 0\nsmu fw version = 0x00684b00 (104.75.0)\n```\n\nNote: Driver interface version (0x2e / 46) does not match firmware\ninterface version (0x32 / 50).\n\n## PCI Topology\n\n```\n65:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84)\n66:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → NHI\n66:01.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → empty hotplug port\n66:02.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → USB\n66:03.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → dock\n93:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → dock switch\n94:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → downstream\n95:00.0 PCI bridge: AMD Navi 10 XL Upstream Port (rev 24)\n96:00.0 PCI bridge: AMD Navi 10 XL Downstream Port (rev 24)\n97:00.0 VGA: AMD [1002:7551] (rev c0) ← GPU\n97:00.1 Audio: AMD [1002:ab40]\n```\n\n## Workload\n\nGPU compute via llama.cpp (ROCm/HIP backend), running\nQwen3.5-35B-A3B-Q4_K_M.gguf model (20.49 GiB, fully offloaded to\nVRAM). Flash attention enabled, 128K context, 32 threads.\n\n## Crash Timeline\n\nAll timestamps from `dmesg -T`, kernel boot-relative times in brackets.\n\n### GPU initialization (successful)\n\n```\n[603.644s] GPU probe: IP DISCOVERY 0x1002:0x7551\n[603.653s] Detected IP block: smu_v14_0_0, gfx_v12_0_0\n[603.771s] Detected VRAM RAM=32624M, BAR=32768M, RAM width 256bits GDDR6\n[604.014s] SMU driver IF 0x2e, FW IF 0x32, FW version 104.75.0\n[604.049s] SMU is initialized successfully!\n[604.119s] Runtime PM manually disabled (amdgpu.runpm=0)\n[604.119s] Initialized amdgpu 3.64.0 for 0000:97:00.0\n```\n\n### SMU stops responding [T+4238s after init, ~70 minutes]\n\n```\n[4841.828s] SMU: No response msg_reg: 12 resp_reg: 0\n[4841.828s] [smu_v14_0_2_get_power_profile_mode] Failed to get activity monitor!\n[4849.393s] SMU: No response msg_reg: 12 resp_reg: 0\n[4849.393s] Failed to export SMU metrics table!\n```\n\n15 consecutive `SMU: No response` messages logged between [4841s] and\n[4948s], approximately every 7-8 seconds. All with `msg_reg: 12\nresp_reg: 0`. Failed operations include:\n- `smu_v14_0_2_get_power_profile_mode` — Failed to get activity monitor\n- `Failed to export SMU metrics table`\n- `Failed to get current clock freq`\n\n### Page faults begin [T+4349s after init, ~111s after first SMU failure]\n\n```\n[4948.927s] [gfxhub] page fault (src_id:0 ring:40 vmid:9 pasid:108)\nProcess llama-cli pid 35632\nGCVM_L2_PROTECTION_FAULT_STATUS: 0x00941051\nFaulty UTCL2 client ID: TCP (0x8)\nPERMISSION_FAULTS: 0x5\nWALKER_ERROR: 0x0\nMAPPING_ERROR: 0x0\nRW: 0x1 (write)\n```\n\n10 page faults logged at [4948s], all from TCP (Texture Cache Pipe),\nall PERMISSION_FAULTS=0x5, WALKER_ERROR=0x0, MAPPING_ERROR=0x0. 7\nunique faulting addresses:\n- 0x000072ce90828000\n- 0x000072ce90a88000\n- 0x000072ce90a89000\n- 0x000072ce90cde000\n- 0x000072ce90ce1000\n- 0x000072ce90f51000\n- 0x000072ce90f52000\n\n### MES failure and GPU reset [T+4349s]\n\n```\n[4952.809s] MES(0) failed to respond to msg=REMOVE_QUEUE\n[4952.809s] failed to remove hardware queue from MES, doorbell=0x1806\n[4952.809s] MES might be in unrecoverable state, issue a GPU reset\n[4952.809s] Failed to evict queue 4\n[4952.809s] Failed to evict process queues\n[4952.809s] GPU reset begin!. Source: 3\n```\n\n### GPU reset fails\n\n```\n[4953.121s] Failed to evict queue 4\n[4953.121s] Failed to suspend process pid 28552\n[4953.121s] remove_all_kfd_queues_mes: Failed to remove queue 3 for dev 62536\n```\n\n6 MES(1) REMOVE_QUEUE failures, each timing out after ~2.5 seconds:\n```\n[4955.720s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n[4958.283s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n[4960.847s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n[4963.411s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n[4965.976s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n[4968.540s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\nunmap legacy queue\n```\n\n### PSP suspend fails\n\n```\n[4971.164s] psp gfx command LOAD_IP_FW(0x6) failed and response status is (0x0)\n[4971.164s] Failed to terminate ras ta\n[4971.164s] suspend of IP block failed -22\n```\n\n### Suspend unwind fails — SMU not ready\n\n```\n[4971.164s] SMU is resuming...\n[4971.164s] SMC is not ready\n[4971.164s] SMC engine is not correctly up!\n[4971.164s] resume of IP block failed -5\n[4971.164s] amdgpu_device_ip_resume_phase2 failed during unwind: -5\n[4971.164s] GPU pre asic reset failed with err, -22 for drm dev, 0000:97:00.0\n```\n\n### MODE1 reset — SMU still dead\n\n```\n[4971.164s] MODE1 reset\n[4971.164s] GPU mode1 reset\n[4971.164s] GPU smu mode1 reset\n[4972.193s] GPU reset succeeded, trying to resume\n[4972.193s] VRAM is lost due to GPU reset!\n[4972.193s] SMU is resuming...\n[4972.193s] SMC is not ready\n[4972.193s] SMC engine is not correctly up!\n[4972.193s] resume of IP block failed -5\n[4972.193s] GPU reset end with ret = -5\n```\n\n\n\n\nOn Fri, Apr 10, 2026 at 3:09 AM Ilpo Järvinen\n wrote:\n>\n> On Thu, 9 Apr 2026, Geramy Loveless wrote:\n>\n> > When pbus_reassign_bridge_resources() walks up the bridge hierarchy\n> > to expand a window (e.g. for resizable BAR), it refuses to release\n> > any bridge window that has children. This prevents BAR resize on\n> > devices behind multi-port PCIe switches (such as Thunderbolt docks)\n> > where empty sibling downstream ports hold small reservations that\n> > block the parent bridge window from being freed and re-sized.\n> >\n> > Add pci_bus_subtree_empty() to check whether a bus subtree contains\n> > any assigned device BARs, and pci_bus_release_empty_bridges() to\n> > release bridge window resources of empty sibling bridges, saving\n> > them to the rollback list so failures can be properly unwound.\n> >\n> > In pbus_reassign_bridge_resources(), call pci_bus_release_empty_bridges()\n> > before checking res->child, so empty sibling windows are cleared first\n> > and the parent window can then be released and grown.\n> >\n> > Uses PCI bus/device iterators rather than walking the raw resource\n> > tree, which avoids issues with stale sibling pointers after resource\n> > release.\n>\n> This paragraph can be dropped. And it's not exactly correct either as\n> the pointers are only stale for resource entries that reside outside of\n> the resource tree (after they've been released in a specific way) so if\n> you start from a resource tree entry, you should never encounter a stale\n> pointer.\n>\n> > Suggested-by: Ilpo Järvinen \n> > Signed-off-by: Geramy Loveless \n> > ---\n> > drivers/pci/setup-bus.c | 99 ++++++++++++++++++++++++++++++++++++++++-\n> > 1 file changed, 97 insertions(+), 2 deletions(-)\n> >\n> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> > index 4cf120ebe5a..7a182cd7e4d 100644\n> > --- a/drivers/pci/setup-bus.c\n> > +++ b/drivers/pci/setup-bus.c\n> > @@ -2292,6 +2292,94 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)\n> > }\n> > EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> >\n> > +/*\n> > + * pci_bus_subtree_empty - Check whether a bus subtree has any assigned\n> > + * non-bridge device resources.\n> > + * @bus: PCI bus to check\n> > + *\n> > + * Returns true if no device on @bus or its descendant buses has any\n> > + * assigned BARs (bridge window resources are not considered).\n> > + */\n> > +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> > +{\n> > + struct pci_dev *dev;\n> > +\n> > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > + struct resource *r;\n> > + unsigned int i;\n> > +\n> > + pci_dev_for_each_resource(dev, r, i) {\n> > + if (i >= PCI_BRIDGE_RESOURCES)\n> > + break;\n> > + if (resource_assigned(r))\n> > + return false;\n> > + }\n> > +\n> > + if (dev->subordinate &&\n> > + !pci_bus_subtree_empty(dev->subordinate))\n> > + return false;\n> > + }\n> > +\n> > + return true;\n> > +}\n> > +\n> > +/*\n> > + * pci_bus_release_empty_bridges - Release bridge window resources of\n> > + * empty sibling bridges so the parent window can be freed and re-sized.\n> > + * @bus: PCI bus whose child bridges to scan\n> > + * @b_win: Parent bridge window resource; only children of this window\n> > + * are released\n> > + * @saved: List to save released resources for rollback\n> > + *\n> > + * For each PCI-to-PCI bridge on @bus whose subtree is empty (no assigned\n> > + * device BARs), releases bridge window resources that are children of\n> > + * @b_win, saving them for rollback via @saved.\n> > + *\n> > + * Returns 0 on success, negative errno on failure.\n> > + */\n> > +static int pci_bus_release_empty_bridges(struct pci_bus *bus,\n> > + struct resource *b_win,\n> > + struct list_head *saved)\n> > +{\n> > + struct pci_dev *dev;\n> > +\n> > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > + struct resource *r;\n> > + unsigned int i;\n> > +\n> > + if (!dev->subordinate)\n> > + continue;\n> > +\n> > + if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)\n> > + continue;\n>\n> I suppose dev->subordinate check is enough for what we're doing so this\n> looks redundant.\n>\n> > +\n> > + if (!pci_bus_subtree_empty(dev->subordinate))\n> > + continue;\n> > +\n> > + pci_dev_for_each_resource(dev, r, i) {\n> > + int ret;\n> > +\n> > + if (!pci_resource_is_bridge_win(i))\n> > + continue;\n> > +\n> > + if (!resource_assigned(r))\n> > + continue;\n> > +\n> > + if (r->parent != b_win)\n> > + continue;\n> > +\n> > + ret = pci_dev_res_add_to_list(saved, dev, r, 0, 0);\n> > + if (ret)\n> > + return ret;\n> > +\n> > + release_child_resources(r);\n>\n> Unfortunately you cannot call this low-level function because it\n> recursively frees child resources which means you won't be able to\n> rollback them as they were not added to the saved list.\n>\n> I think the release algorithm should basically do this:\n>\n> - Recurse to the subordinate buses\n> - Loop through bridge window resources of this bus\n> - Skip resources that are not assigned or are not parented by b_win\n> - If the resource still has childs, leave the resource alone\n> (+ log it for easier troubleshooting these cases; any failure\n> will also cascade to upstream so it may be possible to\n> shortcut something but it will also make the algorithm more\n> complicated)\n> - Save and free the resource\n>\n> It might be better to move some of the code from\n> pbus_reassign_bridge_resources() here as there's overlap with the sketched\n> algorithm (but I'm not sure until I see the updated version but keep this\n> in mind).\n>\n> Doing pci_bus_subtree_empty() before any removal is fine with me, but I\n> see it just an optimization.\n>\n> > + pci_release_resource(dev, i);\n> > + }\n> > + }\n> > +\n> > + return 0;\n> > +}\n> > +\n> > /*\n> > * Walk to the root bus, find the bridge window relevant for @res and\n> > * release it when possible. If the bridge window contains assigned\n> > @@ -2316,7 +2404,14 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> >\n> > i = pci_resource_num(bridge, res);\n> >\n> > - /* Ignore BARs which are still in use */\n>\n> I don't know why you removed this comment (I admit though \"BARs\" could\n> have been worded better as it's bridge windows we're dealing here).\n>\n> > + /* Release empty sibling bridge windows first */\n> > + if (bridge->subordinate) {\n> > + ret = pci_bus_release_empty_bridges(\n> > + bridge->subordinate, res, saved);\n>\n> First arg fits to the previous line.\n>\n> Align the second line to (.\n>\n> But consider also rearranging code as I mentioned above.\n>\n> > + if (ret)\n> > + return ret;\n>\n> Consider proceeding with the resize even if something failed as there are\n> cases where the bridge windows are large enough (admittedly, you seem to\n> only bail out in case of alloc error).\n>\n> In to the same vein, there seems to be one existing goto restore (that was\n> added by me), which could also probably do continue instead (but changing\n> it would be worth another patch).\n>\n> > + }\n> > +\n> > if (!res->child) {\n> > ret = pci_dev_res_add_to_list(saved, bridge, res, 0, 0);\n> > if (ret)\n> > @@ -2327,7 +2422,7 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> > const char *res_name = pci_resource_name(bridge, i);\n> >\n> > pci_warn(bridge,\n> > - \"%s %pR: was not released (still contains assigned resources)\\n\",\n> > + \"%s %pR: not released, active children present\\n\",\n> > res_name, res);\n> > }\n> >\n> >\n>\n> --\n> i.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.a=rsa-sha256\n header.s=20251104 header.b=s18zhJCI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52343-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=\"s18zhJCI\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.219.44","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=jqluv.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsl0c0QMlz1y2d\n\tfor ; Sat, 11 Apr 2026 03:58:40 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 28A213002125\n\tfor ; Fri, 10 Apr 2026 17:53:31 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 682303E275C;\n\tFri, 10 Apr 2026 17:53:30 +0000 (UTC)","from mail-qv1-f44.google.com (mail-qv1-f44.google.com\n [209.85.219.44])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 356993E3164\n\tfor ; Fri, 10 Apr 2026 17:53:26 +0000 (UTC)","by mail-qv1-f44.google.com with SMTP id\n 6a1803df08f44-8a016799d2cso28730576d6.1\n for ; Fri, 10 Apr 2026 10:53:26 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775843610; cv=pass;\n b=j9TUUkH23JKIPppDBC52+w9BDpF3eYBckY2JYyR15JsIDUNZj4SRbmvizUmZgT4L8QkemaOLNZUNbBOUIyZ2WSIBU1Lx8vpPAN9u1E3Uj6loRKWcbxEkw8l+wg7ks0frs100pTTMkW9FrYWdfhzS4rQjRuOKyIg8c9lMY5sfAlQ=","i=1; a=rsa-sha256; t=1775843606; cv=none;\n d=google.com; s=arc-20240605;\n b=IlJAHpbmyVdg7eQkaiAi1zDW+avtWsi4mAzrszqle9aYTPAnTS/59isEUkoekEEilT\n fMGRDdfDtkmUshZwppPB7vXGOEORwTTB070ViHlSLFyekG4iIGq8sjsmH++JjDNgSJWr\n eICwfEVEFNdhFnrREgZB+WAU4PtJjjxAfG83S6kvRmj7HTgf6NjcgIvRn+Q8x/u7KAu1\n z7BvAOSKnrZyRZDaE4FJywoJJEYT2PTi6RLcgbdSrbpA6kSDhfg5adBxycdxrRp8TSGq\n mcVbv36zWPlgdnZVoTOK0U9Gkxp2GrW433oNGb2jQXNbB3lxxrIL4DOtA5KsVN4vfwPO\n 0zTA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775843610; c=relaxed/simple;\n\tbh=xvn/2D2X78UvrqfCXlqh5WzmnEeMyqH7byZYfOfrvwM=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=gKFyiNJHIaLFMqCk2abaPTzt0he0tuerMmHaWil6nraNCXCqRXbNWlYUuK4qIIipuyY91YTSfzUX+ubTt6RZz5OqMaV+ukXnOwFxgiGUgAgtLn23fhSrXQqQ8SoKOQTPXzltKJDdHemugzSMEgilL/CD9T89bM0Kxqb3ePOF8s8=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=hl5xKOuFFhafw6wEcq/usOHKXuFNfkm/WFnlhz3i0tw=;\n fh=vUQDxDnB4ySgPRF470iwOaZOqOi4hHdTxXgEq8j6N3Q=;\n b=DitiP8bU1zj8QA5FaX0VJSxXBQF4hyRBX5wd8p8fNZ4R0wxjhh48NoyqG82s56E9w7\n Jgr+MmhmDDqv5uaxfC4+w1QGlIo3cAyVRxCGzLRv59w4Pof1fX105nf95IEPnTKjGpfu\n N5hzhio1cySkSE6NauGvvx7IpbZ2hd6dwWOyNpNIW17vCkJRUnDXTllsJJBckU4/JVRM\n 3HKWAVBu0ZcYxIefCOYI3erZ09REWoCE18BxZyPSGFN+ifQ4Qyv0CRPRZMUghkTamFQC\n 97rpWrL1rKu6AGVbD26YimGyI7+ike1xcA/ty9wTB6lRgAENEESHQSXivrUdim2+vfi6\n 4Qzg==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com;\n spf=none smtp.mailfrom=jqluv.com;\n dkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=s18zhJCI;\n arc=pass smtp.client-ip=209.85.219.44","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=jqluv-com.20251104.gappssmtp.com; s=20251104; t=1775843606;\n x=1776448406; darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=hl5xKOuFFhafw6wEcq/usOHKXuFNfkm/WFnlhz3i0tw=;\n b=s18zhJCILcdtmUc+jNJ+qQzZnPzlhlf0FA7uhy19XTz8unjMgPXEOmX6M0omhbJiQ8\n XqBZ2qV22CUmWD+0YVT0/0WWO8kESq3Gnx+qIZ/KKctwqZ2SFcGqF7kjGrImmctnzbaz\n e99j1qzb12zF2GiQYzAyDeefy3ejr3zoGPKj+dGeZNJsM6mbCU1gvsxkWJJE0523lzPO\n R7t6WLNqxMyJHSu0Raotdv2iug6xs/YWRUwV16WbxV9UBTrfFZ+Jr5Y57Z30AIrJaYK3\n lri6y0PEj8KD3Y+iwnUokeNaQYspqKO5fTeoMsTqxEawoVED8GsmHt9xbsp7kyJYEk3M\n PReQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775843606; x=1776448406;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=hl5xKOuFFhafw6wEcq/usOHKXuFNfkm/WFnlhz3i0tw=;\n b=slzIXudBDQJtZTrCh8VV6wS8lhBPLf2q6taxRn+rNfNXRjOHU9WqEhIZQ+C0C/ed5g\n Gkt7uI+IuVvWLzt3UqPt5LlK/tTg4BimkLK7WaSpMaRGA/G1qu++0618i4HgO9Y7kNIU\n ACO0xywP6hGpPdDb9nhpfCwqRdQPlV1dp4ftCJaPtrnQMOJuKOIm91mX+jsFHKKlUdL0\n lea8ZBa8R9pM2fRQqXvycbRcGGN5vpGnwOItX06j3noRSvJ4+QQiiDO/+OEla+7ew4Cz\n CcGnz6skQQrSoROKKb2+E6SxIngiUPBMjFkAIYJkKXFnjg8jhIWNd8JL+/NTnwpIGKmA\n hPCw==","X-Gm-Message-State":"AOJu0YwlQyXzHaLTAq8Eag/fDb/tQcgMretf3oFUOSva4cZScpxpC4ag\n\trMxgbCUmoDoSXVDLZltIqE6Pv4bBbfBAEZmcr5QSuUkdJhcZfRj4/ii+KKGX9UCuxqDREffSHwr\n\tUAjl+o8QI0y907pIkadWBqthgCFn7KONI5lgLqDWLdg==","X-Gm-Gg":"AeBDietHLzcsWxJcqJV+nsoxsyhOMv6EyR3Shl7YHaJaMpe7M+cpf35AOIVZwHzt+An\n\t26tHPwwFVIrBuULU4MkMSgatVdtY61LLhzBRmNM2C0L68f7vWI9T2qCDDDA/hqsyimcocNnwF9G\n\t0zCajzgjTXpQNn67Cwtbb7LgNnJssSZhC9UMpDkpqMSfgjWS5Z3Gec/TI2P2wCqneeVcggaohts\n\tHSsqfH/C5tpMwWetWVRCOy0ELnPSoioRlkLh8p+rQ/fyOcU1bchjuyJObZmgXWgyy0LWLlpxMp3\n\tF6Hw","X-Received":"by 2002:a05:6214:4a03:b0:89a:666:ad2b with SMTP id\n 6a1803df08f44-8ac8628d489mr68556556d6.27.1775843605835; Fri, 10 Apr 2026\n 10:53:25 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n ","In-Reply-To":"","From":"Geramy Loveless ","Date":"Fri, 10 Apr 2026 10:53:12 -0700","X-Gm-Features":"AQROBzBOiyCqHqzRhkHVYr7Roen-LRmUaag8BeJJ_CbQCjGi1zxTXWJgpKRqWPo","Message-ID":"\n ","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","To":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Cc":"linux-pci@vger.kernel.org, cristi@ieee.org, =?utf-8?q?Christian_K=C3=B6n?=\n\t=?utf-8?q?ig?= ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3676022,"web_url":"http://patchwork.ozlabs.org/comment/3676022/","msgid":"","list_archive_url":null,"date":"2026-04-10T18:58:50","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","submitter":{"id":93107,"url":"http://patchwork.ozlabs.org/api/people/93107/","name":"Cristian Cocos","email":"cristi@ieee.org"},"content":"My experience with my 9060XT Thunderbolt eGPU is that the current\namdgpu driver is full of bugs, and this *specifically* in a Thunderbolt\neGPU configuration. I have attempted to document some of these bugs\nhere:\nhttps://pcforum.amd.com/s/question/0D5Pd00001S3Av9KAF/linux-9060xt-egpuoverthunderbolt-bugs-galore\n\nApologies for posting this here, as most of these may not be relevant\nto ReBAR, yet an AMD representative may still benefit from this\nmultiple bug report.\n\nC\n\nOn Fri, 2026-04-10 at 10:53 -0700, Geramy Loveless wrote:\n>  I'm going to loop in Christian Koenig over at AMD he has been\n> working\n> with me on resolving or attempting to figure out whats going on with\n> my gfx1201 connected to a tb5 dock to the host.\n> I am currently having problems with the GPU basically loosing MMIO\n> and\n> crashing randomly. This recent patch change I believe helped but its\n> really hard to say at this point.\n> Without this patch of course the bar size would be 256MB and cause\n> huge performance problems or feature loss. I am able to load up AI\n> models and run workloads at nearly 100% gpu usage, i'm seeing 205W\n> power draw out of the maximum 300W. But after sustained load I still\n> get a crash.\n> \n> Maybe you would have an idea as to what is causing that crash or\n> where\n> I should be looking to find the cause?\n> Here are some relevant logs, from what I can tell something is going\n> on with MMIO, but the config bar as i understand it is still alive.\n> This let me to believe maybe the router was getting put into suspend\n> mode which wouldnt make sense for a GPU that is active and busy\n> because the pcie tunnel would be active.\n> \n> Any advice or tips would be helpful thank you for the suggestions I\n> will get started on writing the patch based on those recommendations.\n> \n> ## SMU Firmware Version\n> \n> ```\n> smu driver if version = 0x0000002e\n> smu fw if version = 0x00000032\n> smu fw program = 0\n> smu fw version = 0x00684b00 (104.75.0)\n> ```\n> \n> Note: Driver interface version (0x2e / 46) does not match firmware\n> interface version (0x32 / 50).\n> \n> ## PCI Topology\n> \n> ```\n> 65:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84)\n> 66:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → NHI\n> 66:01.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → empty\n> hotplug port\n> 66:02.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → USB\n> 66:03.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → dock\n> 93:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → dock switch\n> 94:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → downstream\n> 95:00.0 PCI bridge: AMD Navi 10 XL Upstream Port (rev 24)\n> 96:00.0 PCI bridge: AMD Navi 10 XL Downstream Port (rev 24)\n> 97:00.0 VGA: AMD [1002:7551] (rev c0) ← GPU\n> 97:00.1 Audio: AMD [1002:ab40]\n> ```\n> \n> ## Workload\n> \n> GPU compute via llama.cpp (ROCm/HIP backend), running\n> Qwen3.5-35B-A3B-Q4_K_M.gguf model (20.49 GiB, fully offloaded to\n> VRAM). Flash attention enabled, 128K context, 32 threads.\n> \n> ## Crash Timeline\n> \n> All timestamps from `dmesg -T`, kernel boot-relative times in\n> brackets.\n> \n> ### GPU initialization (successful)\n> \n> ```\n> [603.644s] GPU probe: IP DISCOVERY 0x1002:0x7551\n> [603.653s] Detected IP block: smu_v14_0_0, gfx_v12_0_0\n> [603.771s] Detected VRAM RAM=32624M, BAR=32768M, RAM width 256bits\n> GDDR6\n> [604.014s] SMU driver IF 0x2e, FW IF 0x32, FW version 104.75.0\n> [604.049s] SMU is initialized successfully!\n> [604.119s] Runtime PM manually disabled (amdgpu.runpm=0)\n> [604.119s] Initialized amdgpu 3.64.0 for 0000:97:00.0\n> ```\n> \n> ### SMU stops responding [T+4238s after init, ~70 minutes]\n> \n> ```\n> [4841.828s] SMU: No response msg_reg: 12 resp_reg: 0\n> [4841.828s] [smu_v14_0_2_get_power_profile_mode] Failed to get\n> activity monitor!\n> [4849.393s] SMU: No response msg_reg: 12 resp_reg: 0\n> [4849.393s] Failed to export SMU metrics table!\n> ```\n> \n> 15 consecutive `SMU: No response` messages logged between [4841s] and\n> [4948s], approximately every 7-8 seconds. All with `msg_reg: 12\n> resp_reg: 0`. Failed operations include:\n> - `smu_v14_0_2_get_power_profile_mode` — Failed to get activity\n> monitor\n> - `Failed to export SMU metrics table`\n> - `Failed to get current clock freq`\n> \n> ### Page faults begin [T+4349s after init, ~111s after first SMU\n> failure]\n> \n> ```\n> [4948.927s] [gfxhub] page fault (src_id:0 ring:40 vmid:9 pasid:108)\n> Process llama-cli pid 35632\n> GCVM_L2_PROTECTION_FAULT_STATUS: 0x00941051\n> Faulty UTCL2 client ID: TCP (0x8)\n> PERMISSION_FAULTS: 0x5\n> WALKER_ERROR: 0x0\n> MAPPING_ERROR: 0x0\n> RW: 0x1 (write)\n> ```\n> \n> 10 page faults logged at [4948s], all from TCP (Texture Cache Pipe),\n> all PERMISSION_FAULTS=0x5, WALKER_ERROR=0x0, MAPPING_ERROR=0x0. 7\n> unique faulting addresses:\n> - 0x000072ce90828000\n> - 0x000072ce90a88000\n> - 0x000072ce90a89000\n> - 0x000072ce90cde000\n> - 0x000072ce90ce1000\n> - 0x000072ce90f51000\n> - 0x000072ce90f52000\n> \n> ### MES failure and GPU reset [T+4349s]\n> \n> ```\n> [4952.809s] MES(0) failed to respond to msg=REMOVE_QUEUE\n> [4952.809s] failed to remove hardware queue from MES, doorbell=0x1806\n> [4952.809s] MES might be in unrecoverable state, issue a GPU reset\n> [4952.809s] Failed to evict queue 4\n> [4952.809s] Failed to evict process queues\n> [4952.809s] GPU reset begin!. Source: 3\n> ```\n> \n> ### GPU reset fails\n> \n> ```\n> [4953.121s] Failed to evict queue 4\n> [4953.121s] Failed to suspend process pid 28552\n> [4953.121s] remove_all_kfd_queues_mes: Failed to remove queue 3 for\n> dev 62536\n> ```\n> \n> 6 MES(1) REMOVE_QUEUE failures, each timing out after ~2.5 seconds:\n> ```\n> [4955.720s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> [4958.283s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> [4960.847s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> [4963.411s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> [4965.976s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> [4968.540s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> unmap legacy queue\n> ```\n> \n> ### PSP suspend fails\n> \n> ```\n> [4971.164s] psp gfx command LOAD_IP_FW(0x6) failed and response\n> status is (0x0)\n> [4971.164s] Failed to terminate ras ta\n> [4971.164s] suspend of IP block failed -22\n> ```\n> \n> ### Suspend unwind fails — SMU not ready\n> \n> ```\n> [4971.164s] SMU is resuming...\n> [4971.164s] SMC is not ready\n> [4971.164s] SMC engine is not correctly up!\n> [4971.164s] resume of IP block failed -5\n> [4971.164s] amdgpu_device_ip_resume_phase2 failed during unwind: -5\n> [4971.164s] GPU pre asic reset failed with err, -22 for drm dev,\n> 0000:97:00.0\n> ```\n> \n> ### MODE1 reset — SMU still dead\n> \n> ```\n> [4971.164s] MODE1 reset\n> [4971.164s] GPU mode1 reset\n> [4971.164s] GPU smu mode1 reset\n> [4972.193s] GPU reset succeeded, trying to resume\n> [4972.193s] VRAM is lost due to GPU reset!\n> [4972.193s] SMU is resuming...\n> [4972.193s] SMC is not ready\n> [4972.193s] SMC engine is not correctly up!\n> [4972.193s] resume of IP block failed -5\n> [4972.193s] GPU reset end with ret = -5\n> ```\n> \n> \n> \n> \n> On Fri, Apr 10, 2026 at 3:09 AM Ilpo Järvinen\n> wrote:\n> > \n> > On Thu, 9 Apr 2026, Geramy Loveless wrote:\n> > \n> > > When pbus_reassign_bridge_resources() walks up the bridge\n> > > hierarchy\n> > > to expand a window (e.g. for resizable BAR), it refuses to\n> > > release\n> > > any bridge window that has children.  This prevents BAR resize on\n> > > devices behind multi-port PCIe switches (such as Thunderbolt\n> > > docks)\n> > > where empty sibling downstream ports hold small reservations that\n> > > block the parent bridge window from being freed and re-sized.\n> > > \n> > > Add pci_bus_subtree_empty() to check whether a bus subtree\n> > > contains\n> > > any assigned device BARs, and pci_bus_release_empty_bridges() to\n> > > release bridge window resources of empty sibling bridges, saving\n> > > them to the rollback list so failures can be properly unwound.\n> > > \n> > > In pbus_reassign_bridge_resources(), call\n> > > pci_bus_release_empty_bridges()\n> > > before checking res->child, so empty sibling windows are cleared\n> > > first\n> > > and the parent window can then be released and grown.\n> > > \n> > > Uses PCI bus/device iterators rather than walking the raw\n> > > resource\n> > > tree, which avoids issues with stale sibling pointers after\n> > > resource\n> > > release.\n> > \n> > This paragraph can be dropped. And it's not exactly correct either\n> > as\n> > the pointers are only stale for resource entries that reside\n> > outside of\n> > the resource tree (after they've been released in a specific way)\n> > so if\n> > you start from a resource tree entry, you should never encounter a\n> > stale\n> > pointer.\n> > \n> > > Suggested-by: Ilpo Järvinen \n> > > Signed-off-by: Geramy Loveless \n> > > ---\n> > >  drivers/pci/setup-bus.c | 99\n> > > ++++++++++++++++++++++++++++++++++++++++-\n> > >  1 file changed, 97 insertions(+), 2 deletions(-)\n> > > \n> > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> > > index 4cf120ebe5a..7a182cd7e4d 100644\n> > > --- a/drivers/pci/setup-bus.c\n> > > +++ b/drivers/pci/setup-bus.c\n> > > @@ -2292,6 +2292,94 @@ void\n> > > pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)\n> > >  }\n> > >  EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> > > \n> > > +/*\n> > > + * pci_bus_subtree_empty - Check whether a bus subtree has any\n> > > assigned\n> > > + * non-bridge device resources.\n> > > + * @bus: PCI bus to check\n> > > + *\n> > > + * Returns true if no device on @bus or its descendant buses has\n> > > any\n> > > + * assigned BARs (bridge window resources are not considered).\n> > > + */\n> > > +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> > > +{\n> > > +     struct pci_dev *dev;\n> > > +\n> > > +     list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > +             struct resource *r;\n> > > +             unsigned int i;\n> > > +\n> > > +             pci_dev_for_each_resource(dev, r, i) {\n> > > +                     if (i >= PCI_BRIDGE_RESOURCES)\n> > > +                             break;\n> > > +                     if (resource_assigned(r))\n> > > +                             return false;\n> > > +             }\n> > > +\n> > > +             if (dev->subordinate &&\n> > > +                 !pci_bus_subtree_empty(dev->subordinate))\n> > > +                     return false;\n> > > +     }\n> > > +\n> > > +     return true;\n> > > +}\n> > > +\n> > > +/*\n> > > + * pci_bus_release_empty_bridges - Release bridge window\n> > > resources of\n> > > + * empty sibling bridges so the parent window can be freed and\n> > > re-sized.\n> > > + * @bus: PCI bus whose child bridges to scan\n> > > + * @b_win: Parent bridge window resource; only children of this\n> > > window\n> > > + *         are released\n> > > + * @saved: List to save released resources for rollback\n> > > + *\n> > > + * For each PCI-to-PCI bridge on @bus whose subtree is empty (no\n> > > assigned\n> > > + * device BARs), releases bridge window resources that are\n> > > children of\n> > > + * @b_win, saving them for rollback via @saved.\n> > > + *\n> > > + * Returns 0 on success, negative errno on failure.\n> > > + */\n> > > +static int pci_bus_release_empty_bridges(struct pci_bus *bus,\n> > > +                                      struct resource *b_win,\n> > > +                                      struct list_head *saved)\n> > > +{\n> > > +     struct pci_dev *dev;\n> > > +\n> > > +     list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > +             struct resource *r;\n> > > +             unsigned int i;\n> > > +\n> > > +             if (!dev->subordinate)\n> > > +                     continue;\n> > > +\n> > > +             if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)\n> > > +                     continue;\n> > \n> > I suppose dev->subordinate check is enough for what we're doing so\n> > this\n> > looks redundant.\n> > \n> > > +\n> > > +             if (!pci_bus_subtree_empty(dev->subordinate))\n> > > +                     continue;\n> > > +\n> > > +             pci_dev_for_each_resource(dev, r, i) {\n> > > +                     int ret;\n> > > +\n> > > +                     if (!pci_resource_is_bridge_win(i))\n> > > +                             continue;\n> > > +\n> > > +                     if (!resource_assigned(r))\n> > > +                             continue;\n> > > +\n> > > +                     if (r->parent != b_win)\n> > > +                             continue;\n> > > +\n> > > +                     ret = pci_dev_res_add_to_list(saved, dev,\n> > > r, 0, 0);\n> > > +                     if (ret)\n> > > +                             return ret;\n> > > +\n> > > +                     release_child_resources(r);\n> > \n> > Unfortunately you cannot call this low-level function because it\n> > recursively frees child resources which means you won't be able to\n> > rollback them as they were not added to the saved list.\n> > \n> > I think the release algorithm should basically do this:\n> > \n> > - Recurse to the subordinate buses\n> > - Loop through bridge window resources of this bus\n> >         - Skip resources that are not assigned or are not parented\n> > by b_win\n> >         - If the resource still has childs, leave the resource\n> > alone\n> >           (+ log it for easier troubleshooting these cases; any\n> > failure\n> >              will also cascade to upstream so it may be possible to\n> >              shortcut something but it will also make the algorithm\n> > more\n> >              complicated)\n> >         - Save and free the resource\n> > \n> > It might be better to move some of the code from\n> > pbus_reassign_bridge_resources() here as there's overlap with the\n> > sketched\n> > algorithm (but I'm not sure until I see the updated version but\n> > keep this\n> > in mind).\n> > \n> > Doing pci_bus_subtree_empty() before any removal is fine with me,\n> > but I\n> > see it just an optimization.\n> > \n> > > +                     pci_release_resource(dev, i);\n> > > +             }\n> > > +     }\n> > > +\n> > > +     return 0;\n> > > +}\n> > > +\n> > >  /*\n> > >   * Walk to the root bus, find the bridge window relevant for\n> > > @res and\n> > >   * release it when possible. If the bridge window contains\n> > > assigned\n> > > @@ -2316,7 +2404,14 @@ static int\n> > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > resource *\n> > > \n> > >               i = pci_resource_num(bridge, res);\n> > > \n> > > -             /* Ignore BARs which are still in use */\n> > \n> > I don't know why you removed this comment (I admit though \"BARs\"\n> > could\n> > have been worded better as it's bridge windows we're dealing here).\n> > \n> > > +             /* Release empty sibling bridge windows first */\n> > > +             if (bridge->subordinate) {\n> > > +                     ret = pci_bus_release_empty_bridges(\n> > > +                                     bridge->subordinate, res,\n> > > saved);\n> > \n> > First arg fits to the previous line.\n> > \n> > Align the second line to (.\n> > \n> > But consider also rearranging code as I mentioned above.\n> > \n> > > +                     if (ret)\n> > > +                             return ret;\n> > \n> > Consider proceeding with the resize even if something failed as\n> > there are\n> > cases where the bridge windows are large enough (admittedly, you\n> > seem to\n> > only bail out in case of alloc error).\n> > \n> > In to the same vein, there seems to be one existing goto restore\n> > (that was\n> > added by me), which could also probably do continue instead (but\n> > changing\n> > it would be worth another patch).\n> > \n> > > +             }\n> > > +\n> > >               if (!res->child) {\n> > >                       ret = pci_dev_res_add_to_list(saved,\n> > > bridge, res, 0, 0);\n> > >                       if (ret)\n> > > @@ -2327,7 +2422,7 @@ static int\n> > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > resource *\n> > >                       const char *res_name =\n> > > pci_resource_name(bridge, i);\n> > > \n> > >                       pci_warn(bridge,\n> > > -                              \"%s %pR: was not released (still\n> > > contains assigned resources)\\n\",\n> > > +                              \"%s %pR: not released, active\n> > > children present\\n\",\n> > >                                res_name, res);\n> > >               }\n> > > \n> > > \n> > \n> > --\n> >  i.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ieee.org header.i=@ieee.org header.a=rsa-sha256\n header.s=google header.b=d+aNelL8;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52348-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org\n header.b=\"d+aNelL8\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.160.181","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ieee.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=ieee.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsmSn0gfKz1yGS\n\tfor ; Sat, 11 Apr 2026 05:04:41 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 66279303D724\n\tfor ; Fri, 10 Apr 2026 18:58:57 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id EAC192D3EC1;\n\tFri, 10 Apr 2026 18:58:55 +0000 (UTC)","from mail-qt1-f181.google.com (mail-qt1-f181.google.com\n [209.85.160.181])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E9B12FE56A\n\tfor ; Fri, 10 Apr 2026 18:58:52 +0000 (UTC)","by mail-qt1-f181.google.com with SMTP id\n d75a77b69052e-506a6cf8242so17447061cf.1\n for ; Fri, 10 Apr 2026 11:58:52 -0700 (PDT)","from [192.168.153.215] ([73.29.38.247])\n by smtp.gmail.com with ESMTPSA id\n d75a77b69052e-50dd90087f3sm21231321cf.8.2026.04.10.11.58.49\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Fri, 10 Apr 2026 11:58:50 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775847535; cv=none;\n b=j8aN6eEIYzbYNBc4p3tf/TgOm/XfEwYOmHFYGJVRdSgXO6GQQwG7gsMlJwK/jGni37H/Y2FYmMqvj796g1e1My/rl8ewvu6qphfLYqi9cWFShZ0oRuux48GDzHnEw1NxobsexCLoIUHtXoJVJd/ybfjHODcWU0lTeyqDLP534Qg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775847535; c=relaxed/simple;\n\tbh=pxXFSj/ujtA3WZ6H7URx4fHCg/LutJ5JDNuYH/7W9GE=;\n\th=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:\n\t Content-Type:MIME-Version;\n b=EfdfzonxK0u0GgiLirW37VxeHEOyxY/I7kwspulXAeXqQGYTiUACxVYr2dey8NW+y6Q4Llvt+JA/MYohSb3HkQaYB5h25ZgAieY3/mcI5yeKqdqwozoDNR9YJEFLiZwhwppDXQzyrGiiuUF+gaEztDDz79ac1FTzYuCMMBEE8uw=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ieee.org;\n spf=pass smtp.mailfrom=ieee.org;\n dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org\n header.b=d+aNelL8; arc=none smtp.client-ip=209.85.160.181","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ieee.org; s=google; t=1775847531; x=1776452331;\n darn=vger.kernel.org;\n h=mime-version:user-agent:content-transfer-encoding:references\n :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n :date:message-id:reply-to;\n bh=pxXFSj/ujtA3WZ6H7URx4fHCg/LutJ5JDNuYH/7W9GE=;\n b=d+aNelL86+3d5QHt+twQgf2jmjsCuGZaFA8Rbhezz4LKwfOJuoVPosnnK3nHbsxfpG\n q/ONUV0mrLUPenkBfAoUhZx8tmv/V52KOhodhC5dVT3n1iXSsp1u4eTsBacCybKtdlP9\n Z3wP5UpXJ/Jt334tEEO2jBE5A/GAaJGZIdtQg=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775847531; x=1776452331;\n h=mime-version:user-agent:content-transfer-encoding:references\n :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=pxXFSj/ujtA3WZ6H7URx4fHCg/LutJ5JDNuYH/7W9GE=;\n b=D0kqUM/Af7L0WGJlJXK3rLT8piuVg0Lecbcoimfw0uwE9qRGlFNkaC0PRHdP2UEpv2\n 94PI313BsiYibh8knFDEnub8C9Uts1vfDgz8ACplwOXh+ecjry+CupZTH4NPj7eJy8ph\n sthQ+Ld3NUmaEFtlb1xSslEW8bpoLnyz4b+j+7kiHLDu9ZHX6lgtPLBtrKqdnhaceoxn\n bDZ73J6xryZwtOEko5LIgA4LIprzW0Z3Mz2d5NTZKVNQZIdiQbinxJiauYR7CNbQlbhW\n 0KORLQNit8b/FtGuA8xfOgcbXQ0oT3omv2BKoOxCepwyGOPyOfwb50QEPEm/xs0P52nw\n RypQ==","X-Gm-Message-State":"AOJu0YwubhnFwuwQw/P1OlAb0X7myy1BIiPql5zURvYx/XAPHarAnq4M\n\tkBlYg9jBH4iizS/Ga/23AO9csgxi/9IRNBtPdYwsP8bNZw9Oowch4tvDMcQVYK3D1BqmGgiTBiK\n\t9oqxVCKIO","X-Gm-Gg":"AeBDiettQp5Fbs6106oH2A7q5trzZWKu9lyArS5sahGJHvPgye+2mQRDidb8pg3Y4dY\n\t2RmWjgbLMrPuqyY+wCPnjX6HOlW4Q0mIJE93dYJFP8DM3XpSpjdnotQ0HUgeG8pGWHjZ7mIqUdg\n\tGEiQWi8g67d/1Elv5qAVqz3KhVhhw1I8v/XJgpzVy9kYI+BdGf14atLv3Mjy8d87M7hFJ10Z4LT\n\tY1pEfggqohXN3eKJTX80oBgjN5i65GWRutOfr2fXhnzBOxKyum8P86QCXa6yGoLkG5/+YQ17GyX\n\tzplYZxRZZk9D9/bU/7hUGeYjhPVi6Y8RUXD2JzJCLiBFpXBcF2XGzFAdbU3MBrwOHi2kK7Y4wuA\n\t8kIsychH3slzyA0sq23CzbGyCajZtA31OY8T1TKaGmu5BomKna3NKpsAa1JVjDCHJnHEeSZKZDJ\n\tovKBRD0cMt9psK1Q1mMIigJ4Y=","X-Received":"by 2002:a05:622a:241:b0:50d:857d:7ad5 with SMTP id\n d75a77b69052e-50dd5c4345emr68716771cf.59.1775847530902;\n Fri, 10 Apr 2026 11:58:50 -0700 (PDT)","Message-ID":"","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","From":"Cristian Cocos ","To":"Geramy Loveless ,\n Ilpo =?iso-8859-1?q?J=E4rvinen?= ","Cc":"linux-pci@vger.kernel.org,\n Christian =?iso-8859-1?q?K=F6nig?= ","Date":"Fri, 10 Apr 2026 14:58:50 -0400","In-Reply-To":"\n ","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n\t <20260410052918.5556-2-gloveless@jqluv.com>\n\t \n\t ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.60.0 (by Flathub.org) ","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0"}},{"id":3676027,"web_url":"http://patchwork.ozlabs.org/comment/3676027/","msgid":"","list_archive_url":null,"date":"2026-04-10T19:14:40","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":93094,"url":"http://patchwork.ozlabs.org/api/people/93094/","name":"Geramy Loveless","email":"gloveless@jqluv.com"},"content":"Oh wow, would you mind me adding you to my existing bug ticket with AMD?\nI am having the exact same problem, they are working on some fixes for\nsome of the bugs I ran across. I ended adding in some device active\nand alive checks basically to stop the driver from crashing the\nkernel. But I could add you in there so we can get both of our logs\nwhich are the same problem I believe in the same \"ticket\" if you will.\nIt might also help having two views of the same issue. We have the\nsame dock.\n\n\n\n\nGeramy L. Loveless\nFounder & Chief Innovation Officer\n\nJQluv.net, Inc.\nSite: JQluv.com\nMobile: 559.999.1557\nOffice: 1 (877) 44 JQluv\n\n\n\n\nOn Fri, Apr 10, 2026 at 11:58 AM Cristian Cocos wrote:\n>\n> My experience with my 9060XT Thunderbolt eGPU is that the current\n> amdgpu driver is full of bugs, and this *specifically* in a Thunderbolt\n> eGPU configuration. I have attempted to document some of these bugs\n> here:\n> https://pcforum.amd.com/s/question/0D5Pd00001S3Av9KAF/linux-9060xt-egpuoverthunderbolt-bugs-galore\n>\n> Apologies for posting this here, as most of these may not be relevant\n> to ReBAR, yet an AMD representative may still benefit from this\n> multiple bug report.\n>\n> C\n>\n> On Fri, 2026-04-10 at 10:53 -0700, Geramy Loveless wrote:\n> > I'm going to loop in Christian Koenig over at AMD he has been\n> > working\n> > with me on resolving or attempting to figure out whats going on with\n> > my gfx1201 connected to a tb5 dock to the host.\n> > I am currently having problems with the GPU basically loosing MMIO\n> > and\n> > crashing randomly. This recent patch change I believe helped but its\n> > really hard to say at this point.\n> > Without this patch of course the bar size would be 256MB and cause\n> > huge performance problems or feature loss. I am able to load up AI\n> > models and run workloads at nearly 100% gpu usage, i'm seeing 205W\n> > power draw out of the maximum 300W. But after sustained load I still\n> > get a crash.\n> >\n> > Maybe you would have an idea as to what is causing that crash or\n> > where\n> > I should be looking to find the cause?\n> > Here are some relevant logs, from what I can tell something is going\n> > on with MMIO, but the config bar as i understand it is still alive.\n> > This let me to believe maybe the router was getting put into suspend\n> > mode which wouldnt make sense for a GPU that is active and busy\n> > because the pcie tunnel would be active.\n> >\n> > Any advice or tips would be helpful thank you for the suggestions I\n> > will get started on writing the patch based on those recommendations.\n> >\n> > ## SMU Firmware Version\n> >\n> > ```\n> > smu driver if version = 0x0000002e\n> > smu fw if version = 0x00000032\n> > smu fw program = 0\n> > smu fw version = 0x00684b00 (104.75.0)\n> > ```\n> >\n> > Note: Driver interface version (0x2e / 46) does not match firmware\n> > interface version (0x32 / 50).\n> >\n> > ## PCI Topology\n> >\n> > ```\n> > 65:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84)\n> > 66:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → NHI\n> > 66:01.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → empty\n> > hotplug port\n> > 66:02.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → USB\n> > 66:03.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → dock\n> > 93:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → dock switch\n> > 94:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → downstream\n> > 95:00.0 PCI bridge: AMD Navi 10 XL Upstream Port (rev 24)\n> > 96:00.0 PCI bridge: AMD Navi 10 XL Downstream Port (rev 24)\n> > 97:00.0 VGA: AMD [1002:7551] (rev c0) ← GPU\n> > 97:00.1 Audio: AMD [1002:ab40]\n> > ```\n> >\n> > ## Workload\n> >\n> > GPU compute via llama.cpp (ROCm/HIP backend), running\n> > Qwen3.5-35B-A3B-Q4_K_M.gguf model (20.49 GiB, fully offloaded to\n> > VRAM). Flash attention enabled, 128K context, 32 threads.\n> >\n> > ## Crash Timeline\n> >\n> > All timestamps from `dmesg -T`, kernel boot-relative times in\n> > brackets.\n> >\n> > ### GPU initialization (successful)\n> >\n> > ```\n> > [603.644s] GPU probe: IP DISCOVERY 0x1002:0x7551\n> > [603.653s] Detected IP block: smu_v14_0_0, gfx_v12_0_0\n> > [603.771s] Detected VRAM RAM=32624M, BAR=32768M, RAM width 256bits\n> > GDDR6\n> > [604.014s] SMU driver IF 0x2e, FW IF 0x32, FW version 104.75.0\n> > [604.049s] SMU is initialized successfully!\n> > [604.119s] Runtime PM manually disabled (amdgpu.runpm=0)\n> > [604.119s] Initialized amdgpu 3.64.0 for 0000:97:00.0\n> > ```\n> >\n> > ### SMU stops responding [T+4238s after init, ~70 minutes]\n> >\n> > ```\n> > [4841.828s] SMU: No response msg_reg: 12 resp_reg: 0\n> > [4841.828s] [smu_v14_0_2_get_power_profile_mode] Failed to get\n> > activity monitor!\n> > [4849.393s] SMU: No response msg_reg: 12 resp_reg: 0\n> > [4849.393s] Failed to export SMU metrics table!\n> > ```\n> >\n> > 15 consecutive `SMU: No response` messages logged between [4841s] and\n> > [4948s], approximately every 7-8 seconds. All with `msg_reg: 12\n> > resp_reg: 0`. Failed operations include:\n> > - `smu_v14_0_2_get_power_profile_mode` — Failed to get activity\n> > monitor\n> > - `Failed to export SMU metrics table`\n> > - `Failed to get current clock freq`\n> >\n> > ### Page faults begin [T+4349s after init, ~111s after first SMU\n> > failure]\n> >\n> > ```\n> > [4948.927s] [gfxhub] page fault (src_id:0 ring:40 vmid:9 pasid:108)\n> > Process llama-cli pid 35632\n> > GCVM_L2_PROTECTION_FAULT_STATUS: 0x00941051\n> > Faulty UTCL2 client ID: TCP (0x8)\n> > PERMISSION_FAULTS: 0x5\n> > WALKER_ERROR: 0x0\n> > MAPPING_ERROR: 0x0\n> > RW: 0x1 (write)\n> > ```\n> >\n> > 10 page faults logged at [4948s], all from TCP (Texture Cache Pipe),\n> > all PERMISSION_FAULTS=0x5, WALKER_ERROR=0x0, MAPPING_ERROR=0x0. 7\n> > unique faulting addresses:\n> > - 0x000072ce90828000\n> > - 0x000072ce90a88000\n> > - 0x000072ce90a89000\n> > - 0x000072ce90cde000\n> > - 0x000072ce90ce1000\n> > - 0x000072ce90f51000\n> > - 0x000072ce90f52000\n> >\n> > ### MES failure and GPU reset [T+4349s]\n> >\n> > ```\n> > [4952.809s] MES(0) failed to respond to msg=REMOVE_QUEUE\n> > [4952.809s] failed to remove hardware queue from MES, doorbell=0x1806\n> > [4952.809s] MES might be in unrecoverable state, issue a GPU reset\n> > [4952.809s] Failed to evict queue 4\n> > [4952.809s] Failed to evict process queues\n> > [4952.809s] GPU reset begin!. Source: 3\n> > ```\n> >\n> > ### GPU reset fails\n> >\n> > ```\n> > [4953.121s] Failed to evict queue 4\n> > [4953.121s] Failed to suspend process pid 28552\n> > [4953.121s] remove_all_kfd_queues_mes: Failed to remove queue 3 for\n> > dev 62536\n> > ```\n> >\n> > 6 MES(1) REMOVE_QUEUE failures, each timing out after ~2.5 seconds:\n> > ```\n> > [4955.720s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > [4958.283s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > [4960.847s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > [4963.411s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > [4965.976s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > [4968.540s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > unmap legacy queue\n> > ```\n> >\n> > ### PSP suspend fails\n> >\n> > ```\n> > [4971.164s] psp gfx command LOAD_IP_FW(0x6) failed and response\n> > status is (0x0)\n> > [4971.164s] Failed to terminate ras ta\n> > [4971.164s] suspend of IP block failed -22\n> > ```\n> >\n> > ### Suspend unwind fails — SMU not ready\n> >\n> > ```\n> > [4971.164s] SMU is resuming...\n> > [4971.164s] SMC is not ready\n> > [4971.164s] SMC engine is not correctly up!\n> > [4971.164s] resume of IP block failed -5\n> > [4971.164s] amdgpu_device_ip_resume_phase2 failed during unwind: -5\n> > [4971.164s] GPU pre asic reset failed with err, -22 for drm dev,\n> > 0000:97:00.0\n> > ```\n> >\n> > ### MODE1 reset — SMU still dead\n> >\n> > ```\n> > [4971.164s] MODE1 reset\n> > [4971.164s] GPU mode1 reset\n> > [4971.164s] GPU smu mode1 reset\n> > [4972.193s] GPU reset succeeded, trying to resume\n> > [4972.193s] VRAM is lost due to GPU reset!\n> > [4972.193s] SMU is resuming...\n> > [4972.193s] SMC is not ready\n> > [4972.193s] SMC engine is not correctly up!\n> > [4972.193s] resume of IP block failed -5\n> > [4972.193s] GPU reset end with ret = -5\n> > ```\n> >\n> >\n> >\n> >\n> > On Fri, Apr 10, 2026 at 3:09 AM Ilpo Järvinen\n> > wrote:\n> > >\n> > > On Thu, 9 Apr 2026, Geramy Loveless wrote:\n> > >\n> > > > When pbus_reassign_bridge_resources() walks up the bridge\n> > > > hierarchy\n> > > > to expand a window (e.g. for resizable BAR), it refuses to\n> > > > release\n> > > > any bridge window that has children. This prevents BAR resize on\n> > > > devices behind multi-port PCIe switches (such as Thunderbolt\n> > > > docks)\n> > > > where empty sibling downstream ports hold small reservations that\n> > > > block the parent bridge window from being freed and re-sized.\n> > > >\n> > > > Add pci_bus_subtree_empty() to check whether a bus subtree\n> > > > contains\n> > > > any assigned device BARs, and pci_bus_release_empty_bridges() to\n> > > > release bridge window resources of empty sibling bridges, saving\n> > > > them to the rollback list so failures can be properly unwound.\n> > > >\n> > > > In pbus_reassign_bridge_resources(), call\n> > > > pci_bus_release_empty_bridges()\n> > > > before checking res->child, so empty sibling windows are cleared\n> > > > first\n> > > > and the parent window can then be released and grown.\n> > > >\n> > > > Uses PCI bus/device iterators rather than walking the raw\n> > > > resource\n> > > > tree, which avoids issues with stale sibling pointers after\n> > > > resource\n> > > > release.\n> > >\n> > > This paragraph can be dropped. And it's not exactly correct either\n> > > as\n> > > the pointers are only stale for resource entries that reside\n> > > outside of\n> > > the resource tree (after they've been released in a specific way)\n> > > so if\n> > > you start from a resource tree entry, you should never encounter a\n> > > stale\n> > > pointer.\n> > >\n> > > > Suggested-by: Ilpo Järvinen \n> > > > Signed-off-by: Geramy Loveless \n> > > > ---\n> > > > drivers/pci/setup-bus.c | 99\n> > > > ++++++++++++++++++++++++++++++++++++++++-\n> > > > 1 file changed, 97 insertions(+), 2 deletions(-)\n> > > >\n> > > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> > > > index 4cf120ebe5a..7a182cd7e4d 100644\n> > > > --- a/drivers/pci/setup-bus.c\n> > > > +++ b/drivers/pci/setup-bus.c\n> > > > @@ -2292,6 +2292,94 @@ void\n> > > > pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)\n> > > > }\n> > > > EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> > > >\n> > > > +/*\n> > > > + * pci_bus_subtree_empty - Check whether a bus subtree has any\n> > > > assigned\n> > > > + * non-bridge device resources.\n> > > > + * @bus: PCI bus to check\n> > > > + *\n> > > > + * Returns true if no device on @bus or its descendant buses has\n> > > > any\n> > > > + * assigned BARs (bridge window resources are not considered).\n> > > > + */\n> > > > +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> > > > +{\n> > > > + struct pci_dev *dev;\n> > > > +\n> > > > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > + struct resource *r;\n> > > > + unsigned int i;\n> > > > +\n> > > > + pci_dev_for_each_resource(dev, r, i) {\n> > > > + if (i >= PCI_BRIDGE_RESOURCES)\n> > > > + break;\n> > > > + if (resource_assigned(r))\n> > > > + return false;\n> > > > + }\n> > > > +\n> > > > + if (dev->subordinate &&\n> > > > + !pci_bus_subtree_empty(dev->subordinate))\n> > > > + return false;\n> > > > + }\n> > > > +\n> > > > + return true;\n> > > > +}\n> > > > +\n> > > > +/*\n> > > > + * pci_bus_release_empty_bridges - Release bridge window\n> > > > resources of\n> > > > + * empty sibling bridges so the parent window can be freed and\n> > > > re-sized.\n> > > > + * @bus: PCI bus whose child bridges to scan\n> > > > + * @b_win: Parent bridge window resource; only children of this\n> > > > window\n> > > > + * are released\n> > > > + * @saved: List to save released resources for rollback\n> > > > + *\n> > > > + * For each PCI-to-PCI bridge on @bus whose subtree is empty (no\n> > > > assigned\n> > > > + * device BARs), releases bridge window resources that are\n> > > > children of\n> > > > + * @b_win, saving them for rollback via @saved.\n> > > > + *\n> > > > + * Returns 0 on success, negative errno on failure.\n> > > > + */\n> > > > +static int pci_bus_release_empty_bridges(struct pci_bus *bus,\n> > > > + struct resource *b_win,\n> > > > + struct list_head *saved)\n> > > > +{\n> > > > + struct pci_dev *dev;\n> > > > +\n> > > > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > + struct resource *r;\n> > > > + unsigned int i;\n> > > > +\n> > > > + if (!dev->subordinate)\n> > > > + continue;\n> > > > +\n> > > > + if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)\n> > > > + continue;\n> > >\n> > > I suppose dev->subordinate check is enough for what we're doing so\n> > > this\n> > > looks redundant.\n> > >\n> > > > +\n> > > > + if (!pci_bus_subtree_empty(dev->subordinate))\n> > > > + continue;\n> > > > +\n> > > > + pci_dev_for_each_resource(dev, r, i) {\n> > > > + int ret;\n> > > > +\n> > > > + if (!pci_resource_is_bridge_win(i))\n> > > > + continue;\n> > > > +\n> > > > + if (!resource_assigned(r))\n> > > > + continue;\n> > > > +\n> > > > + if (r->parent != b_win)\n> > > > + continue;\n> > > > +\n> > > > + ret = pci_dev_res_add_to_list(saved, dev,\n> > > > r, 0, 0);\n> > > > + if (ret)\n> > > > + return ret;\n> > > > +\n> > > > + release_child_resources(r);\n> > >\n> > > Unfortunately you cannot call this low-level function because it\n> > > recursively frees child resources which means you won't be able to\n> > > rollback them as they were not added to the saved list.\n> > >\n> > > I think the release algorithm should basically do this:\n> > >\n> > > - Recurse to the subordinate buses\n> > > - Loop through bridge window resources of this bus\n> > > - Skip resources that are not assigned or are not parented\n> > > by b_win\n> > > - If the resource still has childs, leave the resource\n> > > alone\n> > > (+ log it for easier troubleshooting these cases; any\n> > > failure\n> > > will also cascade to upstream so it may be possible to\n> > > shortcut something but it will also make the algorithm\n> > > more\n> > > complicated)\n> > > - Save and free the resource\n> > >\n> > > It might be better to move some of the code from\n> > > pbus_reassign_bridge_resources() here as there's overlap with the\n> > > sketched\n> > > algorithm (but I'm not sure until I see the updated version but\n> > > keep this\n> > > in mind).\n> > >\n> > > Doing pci_bus_subtree_empty() before any removal is fine with me,\n> > > but I\n> > > see it just an optimization.\n> > >\n> > > > + pci_release_resource(dev, i);\n> > > > + }\n> > > > + }\n> > > > +\n> > > > + return 0;\n> > > > +}\n> > > > +\n> > > > /*\n> > > > * Walk to the root bus, find the bridge window relevant for\n> > > > @res and\n> > > > * release it when possible. If the bridge window contains\n> > > > assigned\n> > > > @@ -2316,7 +2404,14 @@ static int\n> > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > resource *\n> > > >\n> > > > i = pci_resource_num(bridge, res);\n> > > >\n> > > > - /* Ignore BARs which are still in use */\n> > >\n> > > I don't know why you removed this comment (I admit though \"BARs\"\n> > > could\n> > > have been worded better as it's bridge windows we're dealing here).\n> > >\n> > > > + /* Release empty sibling bridge windows first */\n> > > > + if (bridge->subordinate) {\n> > > > + ret = pci_bus_release_empty_bridges(\n> > > > + bridge->subordinate, res,\n> > > > saved);\n> > >\n> > > First arg fits to the previous line.\n> > >\n> > > Align the second line to (.\n> > >\n> > > But consider also rearranging code as I mentioned above.\n> > >\n> > > > + if (ret)\n> > > > + return ret;\n> > >\n> > > Consider proceeding with the resize even if something failed as\n> > > there are\n> > > cases where the bridge windows are large enough (admittedly, you\n> > > seem to\n> > > only bail out in case of alloc error).\n> > >\n> > > In to the same vein, there seems to be one existing goto restore\n> > > (that was\n> > > added by me), which could also probably do continue instead (but\n> > > changing\n> > > it would be worth another patch).\n> > >\n> > > > + }\n> > > > +\n> > > > if (!res->child) {\n> > > > ret = pci_dev_res_add_to_list(saved,\n> > > > bridge, res, 0, 0);\n> > > > if (ret)\n> > > > @@ -2327,7 +2422,7 @@ static int\n> > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > resource *\n> > > > const char *res_name =\n> > > > pci_resource_name(bridge, i);\n> > > >\n> > > > pci_warn(bridge,\n> > > > - \"%s %pR: was not released (still\n> > > > contains assigned resources)\\n\",\n> > > > + \"%s %pR: not released, active\n> > > > children present\\n\",\n> > > > res_name, res);\n> > > > }\n> > > >\n> > > >\n> > >\n> > > --\n> > > i.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.a=rsa-sha256\n header.s=20251104 header.b=FKdYUU14;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52350-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=\"FKdYUU14\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.160.169","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=jqluv.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsmnD24Q8z1yGS\n\tfor ; Sat, 11 Apr 2026 05:18:56 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id E8F6F3002776\n\tfor ; Fri, 10 Apr 2026 19:14:55 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 1D008344D8D;\n\tFri, 10 Apr 2026 19:14:55 +0000 (UTC)","from mail-qt1-f169.google.com (mail-qt1-f169.google.com\n [209.85.160.169])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id E050D191\n\tfor ; Fri, 10 Apr 2026 19:14:52 +0000 (UTC)","by mail-qt1-f169.google.com with SMTP id\n d75a77b69052e-506bcb23a78so17794051cf.3\n for ; Fri, 10 Apr 2026 12:14:52 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775848495; cv=pass;\n b=rm3BZO+kfRumPDb6DdNHdsh5YsMm97Nvt6FahjUCzq/LiP+0UNKANjnNjJjp3Z/VNLJImddeelSukTC/4SvUPT6LPuVfgvNpx1Am3THzxpfDr17BBOIYt3NoTFgFZpgyY/wMLWD+kpJEk4NIn6T3yqGl7cK/EOAw6quJ+jb89cU=","i=1; a=rsa-sha256; t=1775848492; cv=none;\n d=google.com; s=arc-20240605;\n b=BJNZYqFX6AZuxKY3CQIXpHT/s3hccZ16Sojjvyuj5gd3cXEwkPaF6WVaC8u+DcQEiC\n q8JJXVncJJ9t+djm83t7hwLsA2AjBwgG+eAfv6jkM5UdJjnXoF9EAUjb0Hy9L4yFuFBJ\n 25jc/61/560vjt9tXWjxC5oUTa3NlStggPpgHpvbKEy3ZVf/k6lVe5qn9DITxJVew0r1\n wSlElYZbvvXXfXrZHHH7YppF88C16ELK95Wu1agPWUrM3jr9CysuRNXE1Cnop4qV6VRh\n 1ny45ZlKte9Xg283PNxCyhqOldwrRAX26pBEchtXck99Iz/0MS2aXeR33GTzNAcxHLj9\n 4K3g=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775848495; c=relaxed/simple;\n\tbh=rAzJeJmTS6BTZbQx07zXtuI5eGVhj0AKmnP+jW+ODpQ=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=HETz66xK8UACVx1gPftX4bHr9O0/Gfnt1JFml8+IbnFeXxuJwCgQaHS1boyIDgJYcU4pn/OegDEjKEDuNvUyvXuMMqFsshYIwc/St2YB15mgjQqQw+kFOzQ0N2WkRRgbbr0qdMU7PKyGUeQQxy7UDRdQYWLuI5Ab8B3nQ6scZjo=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=8dsU3r+BBYmMw1ZRC+4lWJ4V99FBV/a/pcFeOIP/090=;\n fh=cALOpDJUajKh6B7SN9J0B0g2HwvS4P+83njGPYk5oFE=;\n b=CxPuRvWqyeW3NBG6sfO8sr0HzTQDmku454ye3jn1C/AM5NTtBR6+Jr108Wykk5qz15\n qCZE2d+Lj3blvbthY9tKBFO1S29LjT+ZD5QQUcE6e/HhJSSS+Pd5LY/dOyl9O75VkaQh\n EfVIn+bYVvJM2uJwogo3YG6UyG+nGV9idVQXbCnnGmS36wrXPlipB28zk5flaF8TyDnd\n EDh9XqrFf3sFpmYVOPtFvggmFTP8q/tjsOCL/qjP561LFh7YnnpHGPuOha7K+cf206/3\n vsY5LaEJIZhJyTboXW+1frg/bMhLDYJfVJxO95UdChFWTAjYX3Z2x7Yy/B44LIb/kkVY\n riGA==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com;\n spf=none smtp.mailfrom=jqluv.com;\n dkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=FKdYUU14;\n arc=pass smtp.client-ip=209.85.160.169","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=jqluv-com.20251104.gappssmtp.com; s=20251104; t=1775848492;\n x=1776453292; darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=8dsU3r+BBYmMw1ZRC+4lWJ4V99FBV/a/pcFeOIP/090=;\n b=FKdYUU14BAiQ1zl1rbyGDDOL47M98/FlByGJo4HVHVpeOLWi5VPCzinw7m/WGKAB0l\n kDfxPNKNTjNQ1klDobvzyMdtoBZJ0omeTFd9+ovOw1jY4xtXriAL/OIas+E+7aS4wNz+\n AChWZdiDi3eocBB9GXCWQHGfF8ZCDiRKF0vkA9On5P9e9M2AZV97tzLw7MUIln4Ch0zs\n mRNEDIa4PHmX4GNLUlz5tXQDKcgx46pYvtbdCMeM+AUZMLEOBAugiQQ/1EgcOwkxpq93\n LBvy9wZLCfZHXoWhOZaXGW6jycnC+G+DQ0LROiN6zhwQDCoV8AmmrSqs9SGkrZdM9WtN\n JPfw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775848492; x=1776453292;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=8dsU3r+BBYmMw1ZRC+4lWJ4V99FBV/a/pcFeOIP/090=;\n b=eG5lZdRlN3vMaUH8LxntQZhE9AgAz1S1srvGZy77rT8e14+BeGK5JMAUyma/JCARFD\n tIMYFk5Gsxsde4tn7IpD8UO2hycnKKtuNfqsQfxq4uLw2eZSNgAOrx9Vh4rBQQoI6gxW\n xuh4zLzS3OPvlRmfhbCJWxINFE+HbHug4XzBoQOaiRljobtwJrzQCb6yaqsjwVNE4+27\n nYiAdlG4nzk5rZ+WumIF4nIYCYi5QXXTpcMV0Y1GUMYN3Z2f/ugxhg1w3E3LpohJa4oQ\n 0Q+8mXTi/vinXmQdjPZTPvSzQemLI76EpJ/Kua+IKCaQrMtaJW7rKBC6OtOHxeKcPsDs\n Hf0w==","X-Forwarded-Encrypted":"i=1;\n AJvYcCVidBShzspjCRh2wmRYcvbBP6hif0EELGntGYxZTeNt+iBc6ryX7KOxRUzggzuzhd9uTlUU+nii9W8=@vger.kernel.org","X-Gm-Message-State":"AOJu0YwqVVyV5uvWtpjkVSYi6qN68qmQTHXs5+V5PBcYLRlJ8upMTLV1\n\tpQ3Jv9EBL2oDtpUawjeZG8bG5JlS7j90g6OVO4wkmNqKdU2cpVQFJ0PaqOTBIsKjz6FQkkTY++p\n\tB4D7hACrfkITbbZ36NH+hUZ+xn9rZiLIQ4lPF4Xf42w==","X-Gm-Gg":"AeBDiesSS5gs4ukvqFH1VSD1WXdgO6HsQEUJvupAEAmxsMpBxqCqY4Bb98TLLG1X71e\n\ta9L/hIWdCB34e0Ilk8mRP+3FIStPccy9JO2CrkamsDz1A73FsA1vGoo9AkAIH4tkNsP0nOWUAVa\n\tQc3JP+NwuJpuN7a+32LzjkofXMwF7Y43gW90rfVkgLqtlLWM932p3jueWm8XbR3b8rNUApw1TdS\n\tlQGhvIrF4FhMQgRzzZlJoQj0QJgH5C9mRuCaNk9A5hz93MF9LC4uLNb9DtvalPNoR36Tazjihq8\n\t+aAh","X-Received":"by 2002:ac8:5fc6:0:b0:50d:2828:1a98 with SMTP id\n d75a77b69052e-50dd574fc29mr73362141cf.0.1775848491447; Fri, 10 Apr 2026\n 12:14:51 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n \n \n ","In-Reply-To":"","From":"Geramy Loveless ","Date":"Fri, 10 Apr 2026 12:14:40 -0700","X-Gm-Features":"AQROBzCVu3LbUzrcEfeTStypVmydaEGtgPl1X91P724ly2-uZVnDrtzzo6ZtEJM","Message-ID":"\n ","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","To":"Cristian Cocos ","Cc":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n linux-pci@vger.kernel.org,\n =?utf-8?q?Christian_K=C3=B6nig?= ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3676081,"web_url":"http://patchwork.ozlabs.org/comment/3676081/","msgid":"","list_archive_url":null,"date":"2026-04-10T23:01:11","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":93094,"url":"http://patchwork.ozlabs.org/api/people/93094/","name":"Geramy Loveless","email":"gloveless@jqluv.com"},"content":"So after a while of doing investigations I keep thinking, gpus have\nsupported hotplug or so i would believe for a while ever since at\nleast thunderbolt 4 and possibly older styles too of hotplug as well\nas dual gpu machines like laptops that have a dedicated and\nintegrated. I would think all of these problems we are seeing is most\nlikely due to something very specific to thunderbolt 5. So here is a\ntheory.\n\nRoot port ACPI device: \\_SB_.PCI0.GP10 at address 0x00030002 = PCI 00:03.2\nIts _DSD (Device-Specific Data) contains only:\n\"FundamentalDeviceResetTriggeredOnD3ToD0\" = 1\n\nNo ExternalFacingPort property. The firmware gives it a D3-to-D0 reset\nhint but never declares it as external-facing.\nFor comparison, a properly configured system would have:\n\nPackage {\"ExternalFacingPort\", 1},\nPackage {\"DmaProperty\", 1},\n\nThe complete proof chain:\n\nDSDT (/tmp/dsdt.dsl:4194-4205): GP10 (00:03.2) _DSD has no ExternalFacingPort\npci_acpi_set_external_facing() (pci-acpi.c:1422):\ndevice_property_read_u8(\"ExternalFacingPort\") fails → external_facing\nstays 0\npci_set_removable() (probe.c:1780): parent not removable → falls through\narch_pci_dev_is_removable() (arch/x86/pci/acpi.c:353):\n!root->external_facing → returns false\nResult: dev->removable never set to DEVICE_REMOVABLE on any device in the chain\n\nSysfs proof:\n 00:03.2: removable=N/A, external_facing=N/A\n 65:00.0: removable=N/A\n 66:03.0: removable=N/A (TB bridge with HotPlug+ Surprise+)\n 93:00.0: removable=N/A\n 97:00.0: removable=N/A (eGPU — dev_is_removable() returns false)\n\nI'm not sure its correct so much but I have patched up the amdgpu\ndriver myself to use what its using now and \"||\npci_is_thunderbolt_attached\"\nThis might be entirely completely wrong :D but I figured I would see\nwhat happens.\n\nOn Fri, Apr 10, 2026 at 12:14 PM Geramy Loveless wrote:\n>\n> Oh wow, would you mind me adding you to my existing bug ticket with AMD?\n> I am having the exact same problem, they are working on some fixes for\n> some of the bugs I ran across. I ended adding in some device active\n> and alive checks basically to stop the driver from crashing the\n> kernel. But I could add you in there so we can get both of our logs\n> which are the same problem I believe in the same \"ticket\" if you will.\n> It might also help having two views of the same issue. We have the\n> same dock.\n>\n>\n>\n>\n>\n>\n>\n>\n> On Fri, Apr 10, 2026 at 11:58 AM Cristian Cocos wrote:\n> >\n> > My experience with my 9060XT Thunderbolt eGPU is that the current\n> > amdgpu driver is full of bugs, and this *specifically* in a Thunderbolt\n> > eGPU configuration. I have attempted to document some of these bugs\n> > here:\n> > https://pcforum.amd.com/s/question/0D5Pd00001S3Av9KAF/linux-9060xt-egpuoverthunderbolt-bugs-galore\n> >\n> > Apologies for posting this here, as most of these may not be relevant\n> > to ReBAR, yet an AMD representative may still benefit from this\n> > multiple bug report.\n> >\n> > C\n> >\n> > On Fri, 2026-04-10 at 10:53 -0700, Geramy Loveless wrote:\n> > > I'm going to loop in Christian Koenig over at AMD he has been\n> > > working\n> > > with me on resolving or attempting to figure out whats going on with\n> > > my gfx1201 connected to a tb5 dock to the host.\n> > > I am currently having problems with the GPU basically loosing MMIO\n> > > and\n> > > crashing randomly. This recent patch change I believe helped but its\n> > > really hard to say at this point.\n> > > Without this patch of course the bar size would be 256MB and cause\n> > > huge performance problems or feature loss. I am able to load up AI\n> > > models and run workloads at nearly 100% gpu usage, i'm seeing 205W\n> > > power draw out of the maximum 300W. But after sustained load I still\n> > > get a crash.\n> > >\n> > > Maybe you would have an idea as to what is causing that crash or\n> > > where\n> > > I should be looking to find the cause?\n> > > Here are some relevant logs, from what I can tell something is going\n> > > on with MMIO, but the config bar as i understand it is still alive.\n> > > This let me to believe maybe the router was getting put into suspend\n> > > mode which wouldnt make sense for a GPU that is active and busy\n> > > because the pcie tunnel would be active.\n> > >\n> > > Any advice or tips would be helpful thank you for the suggestions I\n> > > will get started on writing the patch based on those recommendations.\n> > >\n> > > ## SMU Firmware Version\n> > >\n> > > ```\n> > > smu driver if version = 0x0000002e\n> > > smu fw if version = 0x00000032\n> > > smu fw program = 0\n> > > smu fw version = 0x00684b00 (104.75.0)\n> > > ```\n> > >\n> > > Note: Driver interface version (0x2e / 46) does not match firmware\n> > > interface version (0x32 / 50).\n> > >\n> > > ## PCI Topology\n> > >\n> > > ```\n> > > 65:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84)\n> > > 66:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → NHI\n> > > 66:01.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → empty\n> > > hotplug port\n> > > 66:02.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → USB\n> > > 66:03.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → dock\n> > > 93:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → dock switch\n> > > 94:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → downstream\n> > > 95:00.0 PCI bridge: AMD Navi 10 XL Upstream Port (rev 24)\n> > > 96:00.0 PCI bridge: AMD Navi 10 XL Downstream Port (rev 24)\n> > > 97:00.0 VGA: AMD [1002:7551] (rev c0) ← GPU\n> > > 97:00.1 Audio: AMD [1002:ab40]\n> > > ```\n> > >\n> > > ## Workload\n> > >\n> > > GPU compute via llama.cpp (ROCm/HIP backend), running\n> > > Qwen3.5-35B-A3B-Q4_K_M.gguf model (20.49 GiB, fully offloaded to\n> > > VRAM). Flash attention enabled, 128K context, 32 threads.\n> > >\n> > > ## Crash Timeline\n> > >\n> > > All timestamps from `dmesg -T`, kernel boot-relative times in\n> > > brackets.\n> > >\n> > > ### GPU initialization (successful)\n> > >\n> > > ```\n> > > [603.644s] GPU probe: IP DISCOVERY 0x1002:0x7551\n> > > [603.653s] Detected IP block: smu_v14_0_0, gfx_v12_0_0\n> > > [603.771s] Detected VRAM RAM=32624M, BAR=32768M, RAM width 256bits\n> > > GDDR6\n> > > [604.014s] SMU driver IF 0x2e, FW IF 0x32, FW version 104.75.0\n> > > [604.049s] SMU is initialized successfully!\n> > > [604.119s] Runtime PM manually disabled (amdgpu.runpm=0)\n> > > [604.119s] Initialized amdgpu 3.64.0 for 0000:97:00.0\n> > > ```\n> > >\n> > > ### SMU stops responding [T+4238s after init, ~70 minutes]\n> > >\n> > > ```\n> > > [4841.828s] SMU: No response msg_reg: 12 resp_reg: 0\n> > > [4841.828s] [smu_v14_0_2_get_power_profile_mode] Failed to get\n> > > activity monitor!\n> > > [4849.393s] SMU: No response msg_reg: 12 resp_reg: 0\n> > > [4849.393s] Failed to export SMU metrics table!\n> > > ```\n> > >\n> > > 15 consecutive `SMU: No response` messages logged between [4841s] and\n> > > [4948s], approximately every 7-8 seconds. All with `msg_reg: 12\n> > > resp_reg: 0`. Failed operations include:\n> > > - `smu_v14_0_2_get_power_profile_mode` — Failed to get activity\n> > > monitor\n> > > - `Failed to export SMU metrics table`\n> > > - `Failed to get current clock freq`\n> > >\n> > > ### Page faults begin [T+4349s after init, ~111s after first SMU\n> > > failure]\n> > >\n> > > ```\n> > > [4948.927s] [gfxhub] page fault (src_id:0 ring:40 vmid:9 pasid:108)\n> > > Process llama-cli pid 35632\n> > > GCVM_L2_PROTECTION_FAULT_STATUS: 0x00941051\n> > > Faulty UTCL2 client ID: TCP (0x8)\n> > > PERMISSION_FAULTS: 0x5\n> > > WALKER_ERROR: 0x0\n> > > MAPPING_ERROR: 0x0\n> > > RW: 0x1 (write)\n> > > ```\n> > >\n> > > 10 page faults logged at [4948s], all from TCP (Texture Cache Pipe),\n> > > all PERMISSION_FAULTS=0x5, WALKER_ERROR=0x0, MAPPING_ERROR=0x0. 7\n> > > unique faulting addresses:\n> > > - 0x000072ce90828000\n> > > - 0x000072ce90a88000\n> > > - 0x000072ce90a89000\n> > > - 0x000072ce90cde000\n> > > - 0x000072ce90ce1000\n> > > - 0x000072ce90f51000\n> > > - 0x000072ce90f52000\n> > >\n> > > ### MES failure and GPU reset [T+4349s]\n> > >\n> > > ```\n> > > [4952.809s] MES(0) failed to respond to msg=REMOVE_QUEUE\n> > > [4952.809s] failed to remove hardware queue from MES, doorbell=0x1806\n> > > [4952.809s] MES might be in unrecoverable state, issue a GPU reset\n> > > [4952.809s] Failed to evict queue 4\n> > > [4952.809s] Failed to evict process queues\n> > > [4952.809s] GPU reset begin!. Source: 3\n> > > ```\n> > >\n> > > ### GPU reset fails\n> > >\n> > > ```\n> > > [4953.121s] Failed to evict queue 4\n> > > [4953.121s] Failed to suspend process pid 28552\n> > > [4953.121s] remove_all_kfd_queues_mes: Failed to remove queue 3 for\n> > > dev 62536\n> > > ```\n> > >\n> > > 6 MES(1) REMOVE_QUEUE failures, each timing out after ~2.5 seconds:\n> > > ```\n> > > [4955.720s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > [4958.283s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > [4960.847s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > [4963.411s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > [4965.976s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > [4968.540s] MES(1) failed to respond to msg=REMOVE_QUEUE → failed to\n> > > unmap legacy queue\n> > > ```\n> > >\n> > > ### PSP suspend fails\n> > >\n> > > ```\n> > > [4971.164s] psp gfx command LOAD_IP_FW(0x6) failed and response\n> > > status is (0x0)\n> > > [4971.164s] Failed to terminate ras ta\n> > > [4971.164s] suspend of IP block failed -22\n> > > ```\n> > >\n> > > ### Suspend unwind fails — SMU not ready\n> > >\n> > > ```\n> > > [4971.164s] SMU is resuming...\n> > > [4971.164s] SMC is not ready\n> > > [4971.164s] SMC engine is not correctly up!\n> > > [4971.164s] resume of IP block failed -5\n> > > [4971.164s] amdgpu_device_ip_resume_phase2 failed during unwind: -5\n> > > [4971.164s] GPU pre asic reset failed with err, -22 for drm dev,\n> > > 0000:97:00.0\n> > > ```\n> > >\n> > > ### MODE1 reset — SMU still dead\n> > >\n> > > ```\n> > > [4971.164s] MODE1 reset\n> > > [4971.164s] GPU mode1 reset\n> > > [4971.164s] GPU smu mode1 reset\n> > > [4972.193s] GPU reset succeeded, trying to resume\n> > > [4972.193s] VRAM is lost due to GPU reset!\n> > > [4972.193s] SMU is resuming...\n> > > [4972.193s] SMC is not ready\n> > > [4972.193s] SMC engine is not correctly up!\n> > > [4972.193s] resume of IP block failed -5\n> > > [4972.193s] GPU reset end with ret = -5\n> > > ```\n> > >\n> > >\n> > >\n> > >\n> > > On Fri, Apr 10, 2026 at 3:09 AM Ilpo Järvinen\n> > > wrote:\n> > > >\n> > > > On Thu, 9 Apr 2026, Geramy Loveless wrote:\n> > > >\n> > > > > When pbus_reassign_bridge_resources() walks up the bridge\n> > > > > hierarchy\n> > > > > to expand a window (e.g. for resizable BAR), it refuses to\n> > > > > release\n> > > > > any bridge window that has children. This prevents BAR resize on\n> > > > > devices behind multi-port PCIe switches (such as Thunderbolt\n> > > > > docks)\n> > > > > where empty sibling downstream ports hold small reservations that\n> > > > > block the parent bridge window from being freed and re-sized.\n> > > > >\n> > > > > Add pci_bus_subtree_empty() to check whether a bus subtree\n> > > > > contains\n> > > > > any assigned device BARs, and pci_bus_release_empty_bridges() to\n> > > > > release bridge window resources of empty sibling bridges, saving\n> > > > > them to the rollback list so failures can be properly unwound.\n> > > > >\n> > > > > In pbus_reassign_bridge_resources(), call\n> > > > > pci_bus_release_empty_bridges()\n> > > > > before checking res->child, so empty sibling windows are cleared\n> > > > > first\n> > > > > and the parent window can then be released and grown.\n> > > > >\n> > > > > Uses PCI bus/device iterators rather than walking the raw\n> > > > > resource\n> > > > > tree, which avoids issues with stale sibling pointers after\n> > > > > resource\n> > > > > release.\n> > > >\n> > > > This paragraph can be dropped. And it's not exactly correct either\n> > > > as\n> > > > the pointers are only stale for resource entries that reside\n> > > > outside of\n> > > > the resource tree (after they've been released in a specific way)\n> > > > so if\n> > > > you start from a resource tree entry, you should never encounter a\n> > > > stale\n> > > > pointer.\n> > > >\n> > > > > Suggested-by: Ilpo Järvinen \n> > > > > Signed-off-by: Geramy Loveless \n> > > > > ---\n> > > > > drivers/pci/setup-bus.c | 99\n> > > > > ++++++++++++++++++++++++++++++++++++++++-\n> > > > > 1 file changed, 97 insertions(+), 2 deletions(-)\n> > > > >\n> > > > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> > > > > index 4cf120ebe5a..7a182cd7e4d 100644\n> > > > > --- a/drivers/pci/setup-bus.c\n> > > > > +++ b/drivers/pci/setup-bus.c\n> > > > > @@ -2292,6 +2292,94 @@ void\n> > > > > pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)\n> > > > > }\n> > > > > EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> > > > >\n> > > > > +/*\n> > > > > + * pci_bus_subtree_empty - Check whether a bus subtree has any\n> > > > > assigned\n> > > > > + * non-bridge device resources.\n> > > > > + * @bus: PCI bus to check\n> > > > > + *\n> > > > > + * Returns true if no device on @bus or its descendant buses has\n> > > > > any\n> > > > > + * assigned BARs (bridge window resources are not considered).\n> > > > > + */\n> > > > > +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> > > > > +{\n> > > > > + struct pci_dev *dev;\n> > > > > +\n> > > > > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > > + struct resource *r;\n> > > > > + unsigned int i;\n> > > > > +\n> > > > > + pci_dev_for_each_resource(dev, r, i) {\n> > > > > + if (i >= PCI_BRIDGE_RESOURCES)\n> > > > > + break;\n> > > > > + if (resource_assigned(r))\n> > > > > + return false;\n> > > > > + }\n> > > > > +\n> > > > > + if (dev->subordinate &&\n> > > > > + !pci_bus_subtree_empty(dev->subordinate))\n> > > > > + return false;\n> > > > > + }\n> > > > > +\n> > > > > + return true;\n> > > > > +}\n> > > > > +\n> > > > > +/*\n> > > > > + * pci_bus_release_empty_bridges - Release bridge window\n> > > > > resources of\n> > > > > + * empty sibling bridges so the parent window can be freed and\n> > > > > re-sized.\n> > > > > + * @bus: PCI bus whose child bridges to scan\n> > > > > + * @b_win: Parent bridge window resource; only children of this\n> > > > > window\n> > > > > + * are released\n> > > > > + * @saved: List to save released resources for rollback\n> > > > > + *\n> > > > > + * For each PCI-to-PCI bridge on @bus whose subtree is empty (no\n> > > > > assigned\n> > > > > + * device BARs), releases bridge window resources that are\n> > > > > children of\n> > > > > + * @b_win, saving them for rollback via @saved.\n> > > > > + *\n> > > > > + * Returns 0 on success, negative errno on failure.\n> > > > > + */\n> > > > > +static int pci_bus_release_empty_bridges(struct pci_bus *bus,\n> > > > > + struct resource *b_win,\n> > > > > + struct list_head *saved)\n> > > > > +{\n> > > > > + struct pci_dev *dev;\n> > > > > +\n> > > > > + list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > > + struct resource *r;\n> > > > > + unsigned int i;\n> > > > > +\n> > > > > + if (!dev->subordinate)\n> > > > > + continue;\n> > > > > +\n> > > > > + if ((dev->class >> 8) != PCI_CLASS_BRIDGE_PCI)\n> > > > > + continue;\n> > > >\n> > > > I suppose dev->subordinate check is enough for what we're doing so\n> > > > this\n> > > > looks redundant.\n> > > >\n> > > > > +\n> > > > > + if (!pci_bus_subtree_empty(dev->subordinate))\n> > > > > + continue;\n> > > > > +\n> > > > > + pci_dev_for_each_resource(dev, r, i) {\n> > > > > + int ret;\n> > > > > +\n> > > > > + if (!pci_resource_is_bridge_win(i))\n> > > > > + continue;\n> > > > > +\n> > > > > + if (!resource_assigned(r))\n> > > > > + continue;\n> > > > > +\n> > > > > + if (r->parent != b_win)\n> > > > > + continue;\n> > > > > +\n> > > > > + ret = pci_dev_res_add_to_list(saved, dev,\n> > > > > r, 0, 0);\n> > > > > + if (ret)\n> > > > > + return ret;\n> > > > > +\n> > > > > + release_child_resources(r);\n> > > >\n> > > > Unfortunately you cannot call this low-level function because it\n> > > > recursively frees child resources which means you won't be able to\n> > > > rollback them as they were not added to the saved list.\n> > > >\n> > > > I think the release algorithm should basically do this:\n> > > >\n> > > > - Recurse to the subordinate buses\n> > > > - Loop through bridge window resources of this bus\n> > > > - Skip resources that are not assigned or are not parented\n> > > > by b_win\n> > > > - If the resource still has childs, leave the resource\n> > > > alone\n> > > > (+ log it for easier troubleshooting these cases; any\n> > > > failure\n> > > > will also cascade to upstream so it may be possible to\n> > > > shortcut something but it will also make the algorithm\n> > > > more\n> > > > complicated)\n> > > > - Save and free the resource\n> > > >\n> > > > It might be better to move some of the code from\n> > > > pbus_reassign_bridge_resources() here as there's overlap with the\n> > > > sketched\n> > > > algorithm (but I'm not sure until I see the updated version but\n> > > > keep this\n> > > > in mind).\n> > > >\n> > > > Doing pci_bus_subtree_empty() before any removal is fine with me,\n> > > > but I\n> > > > see it just an optimization.\n> > > >\n> > > > > + pci_release_resource(dev, i);\n> > > > > + }\n> > > > > + }\n> > > > > +\n> > > > > + return 0;\n> > > > > +}\n> > > > > +\n> > > > > /*\n> > > > > * Walk to the root bus, find the bridge window relevant for\n> > > > > @res and\n> > > > > * release it when possible. If the bridge window contains\n> > > > > assigned\n> > > > > @@ -2316,7 +2404,14 @@ static int\n> > > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > > resource *\n> > > > >\n> > > > > i = pci_resource_num(bridge, res);\n> > > > >\n> > > > > - /* Ignore BARs which are still in use */\n> > > >\n> > > > I don't know why you removed this comment (I admit though \"BARs\"\n> > > > could\n> > > > have been worded better as it's bridge windows we're dealing here).\n> > > >\n> > > > > + /* Release empty sibling bridge windows first */\n> > > > > + if (bridge->subordinate) {\n> > > > > + ret = pci_bus_release_empty_bridges(\n> > > > > + bridge->subordinate, res,\n> > > > > saved);\n> > > >\n> > > > First arg fits to the previous line.\n> > > >\n> > > > Align the second line to (.\n> > > >\n> > > > But consider also rearranging code as I mentioned above.\n> > > >\n> > > > > + if (ret)\n> > > > > + return ret;\n> > > >\n> > > > Consider proceeding with the resize even if something failed as\n> > > > there are\n> > > > cases where the bridge windows are large enough (admittedly, you\n> > > > seem to\n> > > > only bail out in case of alloc error).\n> > > >\n> > > > In to the same vein, there seems to be one existing goto restore\n> > > > (that was\n> > > > added by me), which could also probably do continue instead (but\n> > > > changing\n> > > > it would be worth another patch).\n> > > >\n> > > > > + }\n> > > > > +\n> > > > > if (!res->child) {\n> > > > > ret = pci_dev_res_add_to_list(saved,\n> > > > > bridge, res, 0, 0);\n> > > > > if (ret)\n> > > > > @@ -2327,7 +2422,7 @@ static int\n> > > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > > resource *\n> > > > > const char *res_name =\n> > > > > pci_resource_name(bridge, i);\n> > > > >\n> > > > > pci_warn(bridge,\n> > > > > - \"%s %pR: was not released (still\n> > > > > contains assigned resources)\\n\",\n> > > > > + \"%s %pR: not released, active\n> > > > > children present\\n\",\n> > > > > res_name, res);\n> > > > > }\n> > > > >\n> > > > >\n> > > >\n> > > > --\n> > > > i.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.a=rsa-sha256\n header.s=20251104 header.b=KD9g0nJh;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52355-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=\"KD9g0nJh\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.160.176","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=jqluv.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fssk22F7fz1yCx\n\tfor ; Sat, 11 Apr 2026 09:01:30 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 8408B301224F\n\tfor ; Fri, 10 Apr 2026 23:01:27 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DFA2C27FB05;\n\tFri, 10 Apr 2026 23:01:26 +0000 (UTC)","from mail-qt1-f176.google.com (mail-qt1-f176.google.com\n [209.85.160.176])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 6827E2741B6\n\tfor ; Fri, 10 Apr 2026 23:01:24 +0000 (UTC)","by mail-qt1-f176.google.com with SMTP id\n d75a77b69052e-506a747448dso21124331cf.0\n for ; Fri, 10 Apr 2026 16:01:24 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775862086; cv=pass;\n b=jwUGkQxzSOurXYq80etDcOrQ9KPeaAEL2FAXVdCY5Q3BKDmpnOSNTEEUIZdcstllqECs3l+KCGlms1e/Ar/d8ETvGs6m0nLzYPLyVm1g2JUGqmv/PPxPwvH5tePMM0iH3pQVZU4XrXEvRAElffXRi0cPZ98/YuAEkLgpsDhL7Xg=","i=1; a=rsa-sha256; t=1775862083; cv=none;\n d=google.com; s=arc-20240605;\n b=lKsmDzJyq0R/YV5BhKIkLT48Tg0pSiVwc6HQauuiYbuJen51/lIvWTxEnwLI1THpCM\n 7RIGpKDEwCJdDrrWjN8vnFfCYb/Q46W9Zq9LOxLgW/J8nCjwR2+xg3gx7VVHNB3UTXrG\n 73oM1hRSLOh9KlKoK1pQWVFhToGqQxW4ekAJTfls43VAdelvLdJZXo0B5WxPt25MAn8r\n A2lATgZ1Es+Il8j3KoOKWsoovuMG/+z+fRd1+8IZWavh56Oh/Q9GU7T1/7LJTB7B2bxe\n 0appRju2oGuye4s3VXODnue1XM9kSBR1nTHb8SkgRGsawuvAwkusBoFrjCUzgCxv8EUf\n lIuA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775862086; c=relaxed/simple;\n\tbh=iUwdqFwywmlYEPivlt57QUkYHbzFZBPbnIdMsHJE26U=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=K78fRcBnqopUK4kZ+QC+Xm8SmvM740+6G5Jr7B3nERWwyGsLA2H5wpgrZLoZKutUogwu9eJpeRH+TJHC0xPxlMH0ghv3DLN2YaiBT7QkdwelOGTr1siWP+J5Pc1FYqkN5d9rzMUslIfPAuUp6APujrEsRGlbEFUDCyaYERciSf8=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=MAAA5gSBQCg4uIjIi9tZrNw/rlgf4TmLnq3JBlYU6RA=;\n fh=AulswRom1kUpnrAnPb4uKESS0LWYI1G8jysFKqoeMS4=;\n b=Hz6tUgy+zBJ6isWqV9oUOHCThYCGfjlb1BCtC9Tv3zOHGonioSLwtwLcGAtHokZSqQ\n AIFy9LJA704nz+sxgRXPDKBbhDi6N4/++fz/k9jncN+zyVXm1DBsD9GXrfWqzDo2ajAJ\n Cu2KoI5CWbNTVQGMjGccq1CpZ8vHN85fAvecZZX8yzAJ3Yl3M6huAQdz2wdlGL+3mDg+\n GKdPWi0QSlQQM0irpD76sBQJogeW+VDF1nYRG3Zb6QWSU31AXfhLI9FqCdc2rPTiNfpv\n kg/nZKRV3wy23px4r3BEjqMIp7nTI7CnVj20iY5oi4Viga8sCZXQXEMeSv2215EulpqH\n q+og==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com;\n spf=none smtp.mailfrom=jqluv.com;\n dkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=KD9g0nJh;\n arc=pass smtp.client-ip=209.85.160.176","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=jqluv-com.20251104.gappssmtp.com; s=20251104; t=1775862083;\n x=1776466883; darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=MAAA5gSBQCg4uIjIi9tZrNw/rlgf4TmLnq3JBlYU6RA=;\n b=KD9g0nJhsDKP7SZDv4V01wh4mIt0/qmuUCb21GNXIKotJ2qP3W0F6A6MYzUElYMsMr\n 1A7+6eTJr1IpyROkZFcokYMzRc66aLF2nqMPMJhxrd4nYmIk2WAMDoi47LfRwBThpF4r\n pwE2Z9mtJLLeUWcsXxlHiSO/gsQC5Hbus6gCYYCEfGLasLDBpu1WPqYUmCZg4EEufcKk\n V5/UNxwuACyIamYVR/rHMZLK75jm0bzBDpWL+IYQBlW+U63MfvF4mMukd27FS4ooqinF\n aBL76pYW97H2VI0izb4LC1PrdCCBt+wUGcmQJQPRrQ0OaGfzBAPAPTDIdyFJXbOS9W0F\n w3QA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775862083; x=1776466883;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=MAAA5gSBQCg4uIjIi9tZrNw/rlgf4TmLnq3JBlYU6RA=;\n b=aDHLZOSHqO2Cl0UJ1cw8aP1I+WjtJfLMnJtSMeir2GmPSCppHm2YoTQKy99om1CSPQ\n gx1n/M3RuXmx+pyQNDnNe6vbUGQgHZgAyFQl7q+TvFGLnCdcI8YaDw60fPI0qXqI6Koz\n bGoCtSlwMFijZgFBbfhSkql2rD3b6Pa5Bo5MyPxoN3mL+6FreYMXPp4BdtxU0zGl4Ban\n hoMT28bmVeNbLV+N8eB9D7hmFLIQs1aB5SKnr+u4cJVlAZhi9DK/dMiE+5ZwFZiV/WD5\n vPLvnp1KMXLpLL3JoF7x3bkOzfXfCn02e7idIzlkHlpfjYAgJ7/km7BuVP4CtrvShXkE\n 31zA==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWsKPo/xnUxP4OUUh+w6d2YwyMoC2/92IlWrIqnUUFU0Fu70RdsqLhK3ybZZKSOaEch283uFU1ux28=@vger.kernel.org","X-Gm-Message-State":"AOJu0YwSnP+3Gfo7PPEY2/gKKJdaMHPzNq006uUFtnXTJ3QFeVKINYU4\n\tFjWh86N4Mjd5GKhRJchQ3CY+dQ0e0vObrWR+mqTQYUvb7iKi/TVtmXVImPHu0cPBi2+BhWirnwn\n\t8cSLBtWGB5Y7334I0eWY+T+aXtl+Ikl14ETmE7rorKg==","X-Gm-Gg":"AeBDieui3oNIWK7B3D0fGnqzKFbMlPRxOQEn2NDCbM5iBtvyUkxfGffkx7VtEulsOBX\n\twPuFatiL8Tsk/avpXI9Df0nrQ6ZfcYOiRidtf4D0F6ckYWf6Sc4x6zVxwO3cG6GAveeoWNu5RrS\n\ts8rPr6ZdIjZsKpW/r8Qyk3KGz9fjmO3b58oU/0f5Ex++ANIjgQX9UUizQxOQ3g6kCka4yXHKTJQ\n\tIe2y6TKBUiG3/avm7i16XE6yCAr00456VPCSs7ZkLFY6eBIbd50DaoOVdw0uVCF5PYBTVH6y/bi\n\t269f","X-Received":"by 2002:a05:622a:4a8d:b0:50d:9dd1:f259 with SMTP id\n d75a77b69052e-50dd5c2eae3mr81763371cf.61.1775862083022; Fri, 10 Apr 2026\n 16:01:23 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n \n \n \n ","In-Reply-To":"\n ","From":"Geramy Loveless ","Date":"Fri, 10 Apr 2026 16:01:11 -0700","X-Gm-Features":"AQROBzA4TUGNz5v7T1bWOjhGdtsckEozmDzSNf8vatJ5iqdhmUeV1JfRa8yQcFA","Message-ID":"\n ","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","To":"Cristian Cocos ","Cc":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n linux-pci@vger.kernel.org,\n =?utf-8?q?Christian_K=C3=B6nig?= ,\n Mario Limonciello ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3676088,"web_url":"http://patchwork.ozlabs.org/comment/3676088/","msgid":"<58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>","list_archive_url":null,"date":"2026-04-10T23:21:33","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","submitter":{"id":93107,"url":"http://patchwork.ozlabs.org/api/people/93107/","name":"Cristian Cocos","email":"cristi@ieee.org"},"content":"In *Windows*, yes, GPUs have indeed been supported in eGPU\nconfiguration, though not so much in Linux(!). The troubles we are\ncurrently experiencing, esp. concerning hot-plugging, have not been\nreported simply because eGPUs in Linux has, so far, been a very niche,\nlimited application. In other words, it's not that these issues have\nnot been around, it's just that they have not been REPORTED due to a\nvery limited pool of users running Linux in eGPU configuration. GPU\nmanufacturers have thus focused on patching up bugs in Windows, while\nhot-plugging-Thunderbolt-eGPUs-in-Linux has fallen onto the back burner\ndue to its small market share. As such, I doubt that TB5 has anything\nto do with all this.\n\nOn Fri, 2026-04-10 at 16:01 -0700, Geramy Loveless wrote:\n> So after a while of doing investigations I keep thinking, gpus have\n> supported hotplug or so i would believe for a while ever since at\n> least thunderbolt 4 and possibly older styles too of hotplug as well\n> as dual gpu machines like laptops that have a dedicated and\n> integrated. I would think all of these problems we are seeing is most\n> likely due to something very specific to thunderbolt 5. So here is a\n> theory.\n> \n> Root port ACPI device: \\_SB_.PCI0.GP10 at address 0x00030002 = PCI\n> 00:03.2\n> Its _DSD (Device-Specific Data) contains only:\n> \"FundamentalDeviceResetTriggeredOnD3ToD0\" = 1\n> \n> No ExternalFacingPort property. The firmware gives it a D3-to-D0\n> reset\n> hint but never declares it as external-facing.\n> For comparison, a properly configured system would have:\n> \n> Package {\"ExternalFacingPort\", 1},\n> Package {\"DmaProperty\", 1},\n> \n> The complete proof chain:\n> \n> DSDT (/tmp/dsdt.dsl:4194-4205): GP10 (00:03.2) _DSD has no\n> ExternalFacingPort\n> pci_acpi_set_external_facing() (pci-acpi.c:1422):\n> device_property_read_u8(\"ExternalFacingPort\") fails → external_facing\n> stays 0\n> pci_set_removable() (probe.c:1780): parent not removable → falls\n> through\n> arch_pci_dev_is_removable() (arch/x86/pci/acpi.c:353):\n> !root->external_facing → returns false\n> Result: dev->removable never set to DEVICE_REMOVABLE on any device in\n> the chain\n> \n> Sysfs proof:\n>   00:03.2: removable=N/A, external_facing=N/A\n>   65:00.0: removable=N/A\n>   66:03.0: removable=N/A  (TB bridge with HotPlug+ Surprise+)\n>   93:00.0: removable=N/A\n>   97:00.0: removable=N/A  (eGPU — dev_is_removable() returns false)\n> \n> I'm not sure its correct so much but I have patched up the amdgpu\n> driver myself to use what its using now and \"||\n> pci_is_thunderbolt_attached\"\n> This might be entirely completely wrong :D but I figured I would see\n> what happens.\n> \n> On Fri, Apr 10, 2026 at 12:14 PM Geramy Loveless\n> wrote:\n> > \n> > Oh wow, would you mind me adding you to my existing bug ticket with\n> > AMD?\n> > I am having the exact same problem, they are working on some fixes\n> > for\n> > some of the bugs I ran across. I ended adding in some device active\n> > and alive checks basically to stop the driver from crashing the\n> > kernel. But I could add you in there so we can get both of our logs\n> > which are the same problem I believe in the same \"ticket\" if you\n> > will.\n> > It might also help having two views of the same issue. We have the\n> > same dock.\n> > \n> > \n> > \n> > \n> > \n> > \n> > \n> > \n> > On Fri, Apr 10, 2026 at 11:58 AM Cristian Cocos \n> > wrote:\n> > > \n> > > My experience with my 9060XT Thunderbolt eGPU is that the current\n> > > amdgpu driver is full of bugs, and this *specifically* in a\n> > > Thunderbolt\n> > > eGPU configuration. I have attempted to document some of these\n> > > bugs\n> > > here:\n> > > https://pcforum.amd.com/s/question/0D5Pd00001S3Av9KAF/linux-\n> > > 9060xt-egpuoverthunderbolt-bugs-galore\n> > > \n> > > Apologies for posting this here, as most of these may not be\n> > > relevant\n> > > to ReBAR, yet an AMD representative may still benefit from this\n> > > multiple bug report.\n> > > \n> > > C\n> > > \n> > > On Fri, 2026-04-10 at 10:53 -0700, Geramy Loveless wrote:\n> > > >  I'm going to loop in Christian Koenig over at AMD he has been\n> > > > working\n> > > > with me on resolving or attempting to figure out whats going on\n> > > > with\n> > > > my gfx1201 connected to a tb5 dock to the host.\n> > > > I am currently having problems with the GPU basically loosing\n> > > > MMIO\n> > > > and\n> > > > crashing randomly. This recent patch change I believe helped\n> > > > but its\n> > > > really hard to say at this point.\n> > > > Without this patch of course the bar size would be 256MB and\n> > > > cause\n> > > > huge performance problems or feature loss. I am able to load up\n> > > > AI\n> > > > models and run workloads at nearly 100% gpu usage, i'm seeing\n> > > > 205W\n> > > > power draw out of the maximum 300W. But after sustained load I\n> > > > still\n> > > > get a crash.\n> > > > \n> > > > Maybe you would have an idea as to what is causing that crash\n> > > > or\n> > > > where\n> > > > I should be looking to find the cause?\n> > > > Here are some relevant logs, from what I can tell something is\n> > > > going\n> > > > on with MMIO, but the config bar as i understand it is still\n> > > > alive.\n> > > > This let me to believe maybe the router was getting put into\n> > > > suspend\n> > > > mode which wouldnt make sense for a GPU that is active and busy\n> > > > because the pcie tunnel would be active.\n> > > > \n> > > > Any advice or tips would be helpful thank you for the\n> > > > suggestions I\n> > > > will get started on writing the patch based on those\n> > > > recommendations.\n> > > > \n> > > > ## SMU Firmware Version\n> > > > \n> > > > ```\n> > > > smu driver if version = 0x0000002e\n> > > > smu fw if version = 0x00000032\n> > > > smu fw program = 0\n> > > > smu fw version = 0x00684b00 (104.75.0)\n> > > > ```\n> > > > \n> > > > Note: Driver interface version (0x2e / 46) does not match\n> > > > firmware\n> > > > interface version (0x32 / 50).\n> > > > \n> > > > ## PCI Topology\n> > > > \n> > > > ```\n> > > > 65:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84)\n> > > > 66:00.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → NHI\n> > > > 66:01.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) →\n> > > > empty\n> > > > hotplug port\n> > > > 66:02.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → USB\n> > > > 66:03.0 PCI bridge: Intel Barlow Ridge Host 80G (rev 84) → dock\n> > > > 93:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) → dock\n> > > > switch\n> > > > 94:00.0 PCI bridge: Intel Barlow Ridge Hub 80G (rev 85) →\n> > > > downstream\n> > > > 95:00.0 PCI bridge: AMD Navi 10 XL Upstream Port (rev 24)\n> > > > 96:00.0 PCI bridge: AMD Navi 10 XL Downstream Port (rev 24)\n> > > > 97:00.0 VGA: AMD [1002:7551] (rev c0) ← GPU\n> > > > 97:00.1 Audio: AMD [1002:ab40]\n> > > > ```\n> > > > \n> > > > ## Workload\n> > > > \n> > > > GPU compute via llama.cpp (ROCm/HIP backend), running\n> > > > Qwen3.5-35B-A3B-Q4_K_M.gguf model (20.49 GiB, fully offloaded\n> > > > to\n> > > > VRAM). Flash attention enabled, 128K context, 32 threads.\n> > > > \n> > > > ## Crash Timeline\n> > > > \n> > > > All timestamps from `dmesg -T`, kernel boot-relative times in\n> > > > brackets.\n> > > > \n> > > > ### GPU initialization (successful)\n> > > > \n> > > > ```\n> > > > [603.644s] GPU probe: IP DISCOVERY 0x1002:0x7551\n> > > > [603.653s] Detected IP block: smu_v14_0_0, gfx_v12_0_0\n> > > > [603.771s] Detected VRAM RAM=32624M, BAR=32768M, RAM width\n> > > > 256bits\n> > > > GDDR6\n> > > > [604.014s] SMU driver IF 0x2e, FW IF 0x32, FW version 104.75.0\n> > > > [604.049s] SMU is initialized successfully!\n> > > > [604.119s] Runtime PM manually disabled (amdgpu.runpm=0)\n> > > > [604.119s] Initialized amdgpu 3.64.0 for 0000:97:00.0\n> > > > ```\n> > > > \n> > > > ### SMU stops responding [T+4238s after init, ~70 minutes]\n> > > > \n> > > > ```\n> > > > [4841.828s] SMU: No response msg_reg: 12 resp_reg: 0\n> > > > [4841.828s] [smu_v14_0_2_get_power_profile_mode] Failed to get\n> > > > activity monitor!\n> > > > [4849.393s] SMU: No response msg_reg: 12 resp_reg: 0\n> > > > [4849.393s] Failed to export SMU metrics table!\n> > > > ```\n> > > > \n> > > > 15 consecutive `SMU: No response` messages logged between\n> > > > [4841s] and\n> > > > [4948s], approximately every 7-8 seconds. All with `msg_reg: 12\n> > > > resp_reg: 0`. Failed operations include:\n> > > > - `smu_v14_0_2_get_power_profile_mode` — Failed to get activity\n> > > > monitor\n> > > > - `Failed to export SMU metrics table`\n> > > > - `Failed to get current clock freq`\n> > > > \n> > > > ### Page faults begin [T+4349s after init, ~111s after first\n> > > > SMU\n> > > > failure]\n> > > > \n> > > > ```\n> > > > [4948.927s] [gfxhub] page fault (src_id:0 ring:40 vmid:9\n> > > > pasid:108)\n> > > > Process llama-cli pid 35632\n> > > > GCVM_L2_PROTECTION_FAULT_STATUS: 0x00941051\n> > > > Faulty UTCL2 client ID: TCP (0x8)\n> > > > PERMISSION_FAULTS: 0x5\n> > > > WALKER_ERROR: 0x0\n> > > > MAPPING_ERROR: 0x0\n> > > > RW: 0x1 (write)\n> > > > ```\n> > > > \n> > > > 10 page faults logged at [4948s], all from TCP (Texture Cache\n> > > > Pipe),\n> > > > all PERMISSION_FAULTS=0x5, WALKER_ERROR=0x0, MAPPING_ERROR=0x0.\n> > > > 7\n> > > > unique faulting addresses:\n> > > > - 0x000072ce90828000\n> > > > - 0x000072ce90a88000\n> > > > - 0x000072ce90a89000\n> > > > - 0x000072ce90cde000\n> > > > - 0x000072ce90ce1000\n> > > > - 0x000072ce90f51000\n> > > > - 0x000072ce90f52000\n> > > > \n> > > > ### MES failure and GPU reset [T+4349s]\n> > > > \n> > > > ```\n> > > > [4952.809s] MES(0) failed to respond to msg=REMOVE_QUEUE\n> > > > [4952.809s] failed to remove hardware queue from MES,\n> > > > doorbell=0x1806\n> > > > [4952.809s] MES might be in unrecoverable state, issue a GPU\n> > > > reset\n> > > > [4952.809s] Failed to evict queue 4\n> > > > [4952.809s] Failed to evict process queues\n> > > > [4952.809s] GPU reset begin!. Source: 3\n> > > > ```\n> > > > \n> > > > ### GPU reset fails\n> > > > \n> > > > ```\n> > > > [4953.121s] Failed to evict queue 4\n> > > > [4953.121s] Failed to suspend process pid 28552\n> > > > [4953.121s] remove_all_kfd_queues_mes: Failed to remove queue 3\n> > > > for\n> > > > dev 62536\n> > > > ```\n> > > > \n> > > > 6 MES(1) REMOVE_QUEUE failures, each timing out after ~2.5\n> > > > seconds:\n> > > > ```\n> > > > [4955.720s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > [4958.283s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > [4960.847s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > [4963.411s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > [4965.976s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > [4968.540s] MES(1) failed to respond to msg=REMOVE_QUEUE →\n> > > > failed to\n> > > > unmap legacy queue\n> > > > ```\n> > > > \n> > > > ### PSP suspend fails\n> > > > \n> > > > ```\n> > > > [4971.164s] psp gfx command LOAD_IP_FW(0x6) failed and response\n> > > > status is (0x0)\n> > > > [4971.164s] Failed to terminate ras ta\n> > > > [4971.164s] suspend of IP block failed -22\n> > > > ```\n> > > > \n> > > > ### Suspend unwind fails — SMU not ready\n> > > > \n> > > > ```\n> > > > [4971.164s] SMU is resuming...\n> > > > [4971.164s] SMC is not ready\n> > > > [4971.164s] SMC engine is not correctly up!\n> > > > [4971.164s] resume of IP block failed -5\n> > > > [4971.164s] amdgpu_device_ip_resume_phase2 failed during\n> > > > unwind: -5\n> > > > [4971.164s] GPU pre asic reset failed with err, -22 for drm\n> > > > dev,\n> > > > 0000:97:00.0\n> > > > ```\n> > > > \n> > > > ### MODE1 reset — SMU still dead\n> > > > \n> > > > ```\n> > > > [4971.164s] MODE1 reset\n> > > > [4971.164s] GPU mode1 reset\n> > > > [4971.164s] GPU smu mode1 reset\n> > > > [4972.193s] GPU reset succeeded, trying to resume\n> > > > [4972.193s] VRAM is lost due to GPU reset!\n> > > > [4972.193s] SMU is resuming...\n> > > > [4972.193s] SMC is not ready\n> > > > [4972.193s] SMC engine is not correctly up!\n> > > > [4972.193s] resume of IP block failed -5\n> > > > [4972.193s] GPU reset end with ret = -5\n> > > > ```\n> > > > \n> > > > \n> > > > \n> > > > \n> > > > On Fri, Apr 10, 2026 at 3:09 AM Ilpo Järvinen\n> > > > wrote:\n> > > > > \n> > > > > On Thu, 9 Apr 2026, Geramy Loveless wrote:\n> > > > > \n> > > > > > When pbus_reassign_bridge_resources() walks up the bridge\n> > > > > > hierarchy\n> > > > > > to expand a window (e.g. for resizable BAR), it refuses to\n> > > > > > release\n> > > > > > any bridge window that has children.  This prevents BAR\n> > > > > > resize on\n> > > > > > devices behind multi-port PCIe switches (such as\n> > > > > > Thunderbolt\n> > > > > > docks)\n> > > > > > where empty sibling downstream ports hold small\n> > > > > > reservations that\n> > > > > > block the parent bridge window from being freed and re-\n> > > > > > sized.\n> > > > > > \n> > > > > > Add pci_bus_subtree_empty() to check whether a bus subtree\n> > > > > > contains\n> > > > > > any assigned device BARs, and\n> > > > > > pci_bus_release_empty_bridges() to\n> > > > > > release bridge window resources of empty sibling bridges,\n> > > > > > saving\n> > > > > > them to the rollback list so failures can be properly\n> > > > > > unwound.\n> > > > > > \n> > > > > > In pbus_reassign_bridge_resources(), call\n> > > > > > pci_bus_release_empty_bridges()\n> > > > > > before checking res->child, so empty sibling windows are\n> > > > > > cleared\n> > > > > > first\n> > > > > > and the parent window can then be released and grown.\n> > > > > > \n> > > > > > Uses PCI bus/device iterators rather than walking the raw\n> > > > > > resource\n> > > > > > tree, which avoids issues with stale sibling pointers after\n> > > > > > resource\n> > > > > > release.\n> > > > > \n> > > > > This paragraph can be dropped. And it's not exactly correct\n> > > > > either\n> > > > > as\n> > > > > the pointers are only stale for resource entries that reside\n> > > > > outside of\n> > > > > the resource tree (after they've been released in a specific\n> > > > > way)\n> > > > > so if\n> > > > > you start from a resource tree entry, you should never\n> > > > > encounter a\n> > > > > stale\n> > > > > pointer.\n> > > > > \n> > > > > > Suggested-by: Ilpo Järvinen \n> > > > > > Signed-off-by: Geramy Loveless \n> > > > > > ---\n> > > > > >  drivers/pci/setup-bus.c | 99\n> > > > > > ++++++++++++++++++++++++++++++++++++++++-\n> > > > > >  1 file changed, 97 insertions(+), 2 deletions(-)\n> > > > > > \n> > > > > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-\n> > > > > > bus.c\n> > > > > > index 4cf120ebe5a..7a182cd7e4d 100644\n> > > > > > --- a/drivers/pci/setup-bus.c\n> > > > > > +++ b/drivers/pci/setup-bus.c\n> > > > > > @@ -2292,6 +2292,94 @@ void\n> > > > > > pci_assign_unassigned_bridge_resources(struct pci_dev\n> > > > > > *bridge)\n> > > > > >  }\n> > > > > >  EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);\n> > > > > > \n> > > > > > +/*\n> > > > > > + * pci_bus_subtree_empty - Check whether a bus subtree has\n> > > > > > any\n> > > > > > assigned\n> > > > > > + * non-bridge device resources.\n> > > > > > + * @bus: PCI bus to check\n> > > > > > + *\n> > > > > > + * Returns true if no device on @bus or its descendant\n> > > > > > buses has\n> > > > > > any\n> > > > > > + * assigned BARs (bridge window resources are not\n> > > > > > considered).\n> > > > > > + */\n> > > > > > +static bool pci_bus_subtree_empty(struct pci_bus *bus)\n> > > > > > +{\n> > > > > > +     struct pci_dev *dev;\n> > > > > > +\n> > > > > > +     list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > > > +             struct resource *r;\n> > > > > > +             unsigned int i;\n> > > > > > +\n> > > > > > +             pci_dev_for_each_resource(dev, r, i) {\n> > > > > > +                     if (i >= PCI_BRIDGE_RESOURCES)\n> > > > > > +                             break;\n> > > > > > +                     if (resource_assigned(r))\n> > > > > > +                             return false;\n> > > > > > +             }\n> > > > > > +\n> > > > > > +             if (dev->subordinate &&\n> > > > > > +                 !pci_bus_subtree_empty(dev->subordinate))\n> > > > > > +                     return false;\n> > > > > > +     }\n> > > > > > +\n> > > > > > +     return true;\n> > > > > > +}\n> > > > > > +\n> > > > > > +/*\n> > > > > > + * pci_bus_release_empty_bridges - Release bridge window\n> > > > > > resources of\n> > > > > > + * empty sibling bridges so the parent window can be freed\n> > > > > > and\n> > > > > > re-sized.\n> > > > > > + * @bus: PCI bus whose child bridges to scan\n> > > > > > + * @b_win: Parent bridge window resource; only children of\n> > > > > > this\n> > > > > > window\n> > > > > > + *         are released\n> > > > > > + * @saved: List to save released resources for rollback\n> > > > > > + *\n> > > > > > + * For each PCI-to-PCI bridge on @bus whose subtree is\n> > > > > > empty (no\n> > > > > > assigned\n> > > > > > + * device BARs), releases bridge window resources that are\n> > > > > > children of\n> > > > > > + * @b_win, saving them for rollback via @saved.\n> > > > > > + *\n> > > > > > + * Returns 0 on success, negative errno on failure.\n> > > > > > + */\n> > > > > > +static int pci_bus_release_empty_bridges(struct pci_bus\n> > > > > > *bus,\n> > > > > > +                                      struct resource\n> > > > > > *b_win,\n> > > > > > +                                      struct list_head\n> > > > > > *saved)\n> > > > > > +{\n> > > > > > +     struct pci_dev *dev;\n> > > > > > +\n> > > > > > +     list_for_each_entry(dev, &bus->devices, bus_list) {\n> > > > > > +             struct resource *r;\n> > > > > > +             unsigned int i;\n> > > > > > +\n> > > > > > +             if (!dev->subordinate)\n> > > > > > +                     continue;\n> > > > > > +\n> > > > > > +             if ((dev->class >> 8) !=\n> > > > > > PCI_CLASS_BRIDGE_PCI)\n> > > > > > +                     continue;\n> > > > > \n> > > > > I suppose dev->subordinate check is enough for what we're\n> > > > > doing so\n> > > > > this\n> > > > > looks redundant.\n> > > > > \n> > > > > > +\n> > > > > > +             if (!pci_bus_subtree_empty(dev->subordinate))\n> > > > > > +                     continue;\n> > > > > > +\n> > > > > > +             pci_dev_for_each_resource(dev, r, i) {\n> > > > > > +                     int ret;\n> > > > > > +\n> > > > > > +                     if (!pci_resource_is_bridge_win(i))\n> > > > > > +                             continue;\n> > > > > > +\n> > > > > > +                     if (!resource_assigned(r))\n> > > > > > +                             continue;\n> > > > > > +\n> > > > > > +                     if (r->parent != b_win)\n> > > > > > +                             continue;\n> > > > > > +\n> > > > > > +                     ret = pci_dev_res_add_to_list(saved,\n> > > > > > dev,\n> > > > > > r, 0, 0);\n> > > > > > +                     if (ret)\n> > > > > > +                             return ret;\n> > > > > > +\n> > > > > > +                     release_child_resources(r);\n> > > > > \n> > > > > Unfortunately you cannot call this low-level function because\n> > > > > it\n> > > > > recursively frees child resources which means you won't be\n> > > > > able to\n> > > > > rollback them as they were not added to the saved list.\n> > > > > \n> > > > > I think the release algorithm should basically do this:\n> > > > > \n> > > > > - Recurse to the subordinate buses\n> > > > > - Loop through bridge window resources of this bus\n> > > > >         - Skip resources that are not assigned or are not\n> > > > > parented\n> > > > > by b_win\n> > > > >         - If the resource still has childs, leave the\n> > > > > resource\n> > > > > alone\n> > > > >           (+ log it for easier troubleshooting these cases;\n> > > > > any\n> > > > > failure\n> > > > >              will also cascade to upstream so it may be\n> > > > > possible to\n> > > > >              shortcut something but it will also make the\n> > > > > algorithm\n> > > > > more\n> > > > >              complicated)\n> > > > >         - Save and free the resource\n> > > > > \n> > > > > It might be better to move some of the code from\n> > > > > pbus_reassign_bridge_resources() here as there's overlap with\n> > > > > the\n> > > > > sketched\n> > > > > algorithm (but I'm not sure until I see the updated version\n> > > > > but\n> > > > > keep this\n> > > > > in mind).\n> > > > > \n> > > > > Doing pci_bus_subtree_empty() before any removal is fine with\n> > > > > me,\n> > > > > but I\n> > > > > see it just an optimization.\n> > > > > \n> > > > > > +                     pci_release_resource(dev, i);\n> > > > > > +             }\n> > > > > > +     }\n> > > > > > +\n> > > > > > +     return 0;\n> > > > > > +}\n> > > > > > +\n> > > > > >  /*\n> > > > > >   * Walk to the root bus, find the bridge window relevant\n> > > > > > for\n> > > > > > @res and\n> > > > > >   * release it when possible. If the bridge window contains\n> > > > > > assigned\n> > > > > > @@ -2316,7 +2404,14 @@ static int\n> > > > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > > > resource *\n> > > > > > \n> > > > > >               i = pci_resource_num(bridge, res);\n> > > > > > \n> > > > > > -             /* Ignore BARs which are still in use */\n> > > > > \n> > > > > I don't know why you removed this comment (I admit though\n> > > > > \"BARs\"\n> > > > > could\n> > > > > have been worded better as it's bridge windows we're dealing\n> > > > > here).\n> > > > > \n> > > > > > +             /* Release empty sibling bridge windows first\n> > > > > > */\n> > > > > > +             if (bridge->subordinate) {\n> > > > > > +                     ret = pci_bus_release_empty_bridges(\n> > > > > > +                                     bridge->subordinate,\n> > > > > > res,\n> > > > > > saved);\n> > > > > \n> > > > > First arg fits to the previous line.\n> > > > > \n> > > > > Align the second line to (.\n> > > > > \n> > > > > But consider also rearranging code as I mentioned above.\n> > > > > \n> > > > > > +                     if (ret)\n> > > > > > +                             return ret;\n> > > > > \n> > > > > Consider proceeding with the resize even if something failed\n> > > > > as\n> > > > > there are\n> > > > > cases where the bridge windows are large enough (admittedly,\n> > > > > you\n> > > > > seem to\n> > > > > only bail out in case of alloc error).\n> > > > > \n> > > > > In to the same vein, there seems to be one existing goto\n> > > > > restore\n> > > > > (that was\n> > > > > added by me), which could also probably do continue instead\n> > > > > (but\n> > > > > changing\n> > > > > it would be worth another patch).\n> > > > > \n> > > > > > +             }\n> > > > > > +\n> > > > > >               if (!res->child) {\n> > > > > >                       ret = pci_dev_res_add_to_list(saved,\n> > > > > > bridge, res, 0, 0);\n> > > > > >                       if (ret)\n> > > > > > @@ -2327,7 +2422,7 @@ static int\n> > > > > > pbus_reassign_bridge_resources(struct pci_bus *bus, struct\n> > > > > > resource *\n> > > > > >                       const char *res_name =\n> > > > > > pci_resource_name(bridge, i);\n> > > > > > \n> > > > > >                       pci_warn(bridge,\n> > > > > > -                              \"%s %pR: was not released\n> > > > > > (still\n> > > > > > contains assigned resources)\\n\",\n> > > > > > +                              \"%s %pR: not released,\n> > > > > > active\n> > > > > > children present\\n\",\n> > > > > >                                res_name, res);\n> > > > > >               }\n> > > > > > \n> > > > > > \n> > > > > \n> > > > > --\n> > > > >  i.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ieee.org header.i=@ieee.org header.a=rsa-sha256\n header.s=google header.b=QiTi1Xsg;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52359-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org\n header.b=\"QiTi1Xsg\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.160.180","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ieee.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=ieee.org"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fst9L2mzxz1yGb\n\tfor ; Sat, 11 Apr 2026 09:21:42 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id A7AA33026C96\n\tfor ; Fri, 10 Apr 2026 23:21:40 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2D890336ECF;\n\tFri, 10 Apr 2026 23:21:38 +0000 (UTC)","from mail-qt1-f180.google.com (mail-qt1-f180.google.com\n [209.85.160.180])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id B59212DA76A\n\tfor ; Fri, 10 Apr 2026 23:21:34 +0000 (UTC)","by mail-qt1-f180.google.com with SMTP id\n d75a77b69052e-50d8e11b948so26132031cf.3\n for ; Fri, 10 Apr 2026 16:21:34 -0700 (PDT)","from [192.168.153.215] ([73.29.38.247])\n by smtp.gmail.com with ESMTPSA id\n 6a1803df08f44-8ac84c9c37csm33914526d6.36.2026.04.10.16.21.32\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Fri, 10 Apr 2026 16:21:32 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775863298; cv=none;\n b=cHL0rUzr1f1SwbnDwBiWGoNmHfRL62keUlTFvz3Q6/mr9MBc/7VT62S0ufD9qRVa6HL0FktS2tmUX+yy8p8LzpSmb4CWxps3+MuebG0rWto8GQkbIC1DSKJOnuKMva2hHZtMxniS0ev74+UGcxLSvv2b9FKBAY8iZdDeGZvQMn4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775863298; c=relaxed/simple;\n\tbh=1Ij6gOA8yTxVpp0GmOObllas5PKQQD98tW7Qty1sdJc=;\n\th=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:\n\t Content-Type:MIME-Version;\n b=aCKd+JxqUWKWWydlipruzfIVZA0FMkwThTKdIjWXrZhE6ZUjWwmWtQ8LgSMXO9X6zJEvZNKTKTlUNtwJDb70yC5VjNLwNNQojFqUwKYo9AaKSvOKtiQhE2HOYtD3Xp/NiCKcWUlb8Vtgs2h9Hw8CSP3xnwkzscQPb07i068hWy0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ieee.org;\n spf=pass smtp.mailfrom=ieee.org;\n dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org\n header.b=QiTi1Xsg; arc=none smtp.client-ip=209.85.160.180","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ieee.org; s=google; t=1775863294; x=1776468094;\n darn=vger.kernel.org;\n h=mime-version:user-agent:content-transfer-encoding:references\n :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject\n :date:message-id:reply-to;\n bh=1Ij6gOA8yTxVpp0GmOObllas5PKQQD98tW7Qty1sdJc=;\n b=QiTi1Xsgt4qxOmH3oTw3ozwl9m1jDcRxVYTADE8fe5+v/6B5kz2IUdZ+HBV5oY5AwP\n 4LlJqtNtcDFEwOE9qdhs/evptRPwTPGLlJ5oiRNx2Ed5pUwBhS5kn/yItJuZEOMMUv8B\n I5vwm/tafVXkL46LhIlI5DGkoxPE+GRwZXrvM=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775863294; x=1776468094;\n h=mime-version:user-agent:content-transfer-encoding:references\n :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=1Ij6gOA8yTxVpp0GmOObllas5PKQQD98tW7Qty1sdJc=;\n b=SPvzsbUN3ufEeSNOSVrcG8MhQnaY6vHU+0Yj5KuaoMXwiXN1O+n2FH0cP5EHozm+RY\n 02vA3HDgSyV642hGoMOKgp3VItzBjlzYFT3fYHeOgN0RTaCgzmksv1jIPvxxoGNYiVG8\n sDL4ndTX9GNpmXM1BmbewIU0OgJPQuxfaMRGitMds1YBy/m/orLSg5sz0aZj3BEaO1/Z\n WefkT68DbtcDAIgoaPTdLZEh+VVd3gp9G0gzS9e+bPsufJm5uJLg6K5GH7uQwVyR4muE\n DeTyQD1c7+eZ4ehJXQVDyeGxzRYDJHlB7DS78lgUhjyVvm9z/0/CFn0kaudnYAXLEW7s\n EGvQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCXnPfKFUuNjhFCX6IF9pLoEl9Ha+a930yB87kFz9+d5RnquWfC2Txoax62EB3m3QApOA3PTT1mPp6c=@vger.kernel.org","X-Gm-Message-State":"AOJu0Yywj6lqg5849CS5+eBCKRqKRxe8dJ/jg7+uHeNrqInkeXtlvJr+\n\tQKf22bK0Yl0T1e5NFMZSFud4nvtsQXDhopy/bu9SAuViGMSAAxupH6zdgjHLfz8O+g==","X-Gm-Gg":"AeBDiev/6vN5vtF5BoFTLzfwBbYNeNAJoJleuajbwA7TaJe3+iYSYk2XHSClZSSCbQz\n\tLmM6po1QGSr12Mn+0T95EZtwU0s48UkKz6YkMG1c+G2QTljiox/4qurXF1K7yfn1pTT10bZNie7\n\tmSK8TONz+2gwnWs0xvnBQiSpcII0Gn4i022hWMVYuwmtivzBzQdh0zd7NKHgfnsvMtK7KcolQ4d\n\tzSrA3mY2YK5Gh4FsY0FvWCUGeGSY15jA5Qdt9me9AenD6LeNZ8TH+ZVL9hjcjDmltZvX3tGcb8+\n\tgSadRtyLXr9AFy+ftgpgu1SqPFXjOdwP6zttoIwrcBoQ0MzErJX16yPre15Qhs5a6vRtqGui+mG\n\tWiS7acb/4x+d75OLRIHfAvk3mdyJRLjPhg/pHLe9uvZXlgJ7KHUmkhvvsK5sNckF5Pl+LVGSdI2\n\tRkHZ8npnhxTBUzpSHn8HqWmC64y/DRVSpwcg==","X-Received":"by 2002:ac8:7c41:0:b0:50d:7f91:6bd8 with SMTP id\n d75a77b69052e-50dd5aef77emr78646071cf.28.1775863293256;\n Fri, 10 Apr 2026 16:21:33 -0700 (PDT)","Message-ID":"<58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during\n rebar expansion","From":"Cristian Cocos ","To":"Geramy Loveless ","Cc":"Ilpo =?iso-8859-1?q?J=E4rvinen?= ,\n linux-pci@vger.kernel.org,\n Christian =?iso-8859-1?q?K=F6nig?= ,\n Mario Limonciello ","Date":"Fri, 10 Apr 2026 19:21:33 -0400","In-Reply-To":"\n ","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n\t <20260410052918.5556-2-gloveless@jqluv.com>\n\t \n\t \n\t \n\t \n\t ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.60.0 (by Flathub.org) ","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0"}},{"id":3676109,"web_url":"http://patchwork.ozlabs.org/comment/3676109/","msgid":"<2fe254c2-38f2-4213-9055-43b810502ccd@amd.com>","list_archive_url":null,"date":"2026-04-11T03:28:13","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":81779,"url":"http://patchwork.ozlabs.org/api/people/81779/","name":"Mario Limonciello","email":"Mario.Limonciello@amd.com"},"content":"On 4/10/26 18:21, Cristian Cocos wrote:\n> [You don't often get email from cristi@ieee.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]\n> \n> In *Windows*, yes, GPUs have indeed been supported in eGPU\n> configuration, though not so much in Linux(!). The troubles we are\n> currently experiencing, esp. concerning hot-plugging, have not been\n> reported simply because eGPUs in Linux has, so far, been a very niche,\n> limited application. In other words, it's not that these issues have\n> not been around, it's just that they have not been REPORTED due to a\n> very limited pool of users running Linux in eGPU configuration. GPU\n> manufacturers have thus focused on patching up bugs in Windows, while\n> hot-plugging-Thunderbolt-eGPUs-in-Linux has fallen onto the back burner\n> due to its small market share. As such, I doubt that TB5 has anything\n> to do with all this.\n> \n> On Fri, 2026-04-10 at 16:01 -0700, Geramy Loveless wrote:\n>> So after a while of doing investigations I keep thinking, gpus have\n>> supported hotplug or so i would believe for a while ever since at\n>> least thunderbolt 4 and possibly older styles too of hotplug as well\n>> as dual gpu machines like laptops that have a dedicated and\n>> integrated. I would think all of these problems we are seeing is most\n>> likely due to something very specific to thunderbolt 5. So here is a\n>> theory.\n>>\n>> Root port ACPI device: \\_SB_.PCI0.GP10 at address 0x00030002 = PCI\n>> 00:03.2\n>> Its _DSD (Device-Specific Data) contains only:\n>> \"FundamentalDeviceResetTriggeredOnD3ToD0\" = 1\n>>\n>> No ExternalFacingPort property. The firmware gives it a D3-to-D0\n>> reset\n>> hint but never declares it as external-facing.\n>> For comparison, a properly configured system would have:\n>>\n>> Package {\"ExternalFacingPort\", 1},\n>> Package {\"DmaProperty\", 1},\n>>\n>> The complete proof chain:\n>>\n>> DSDT (/tmp/dsdt.dsl:4194-4205): GP10 (00:03.2) _DSD has no\n>> ExternalFacingPort\n>> pci_acpi_set_external_facing() (pci-acpi.c:1422):\n>> device_property_read_u8(\"ExternalFacingPort\") fails → external_facing\n>> stays 0\n>> pci_set_removable() (probe.c:1780): parent not removable → falls\n>> through\n>> arch_pci_dev_is_removable() (arch/x86/pci/acpi.c:353):\n>> !root->external_facing → returns false\n>> Result: dev->removable never set to DEVICE_REMOVABLE on any device in\n>> the chain\n>>\n>> Sysfs proof:\n>> 00:03.2: removable=N/A, external_facing=N/A\n>> 65:00.0: removable=N/A\n>> 66:03.0: removable=N/A (TB bridge with HotPlug+ Surprise+)\n>> 93:00.0: removable=N/A\n>> 97:00.0: removable=N/A (eGPU — dev_is_removable() returns false)\n>>\n>> I'm not sure its correct so much but I have patched up the amdgpu\n>> driver myself to use what its using now and \"||\n>> pci_is_thunderbolt_attached\"\n>> This might be entirely completely wrong :D but I figured I would see\n>> what happens.\n>>\n\nI would say it's wrong. We explicitly moved away from this because it's \nonly indicating there is an Intel VSEC:\n\ncommit 7b1c6263eaf4f (\"drm/amdgpu: don't use pci_is_thunderbolt_attached()\")\n\nIsn't what you point out a BIOS bug?\n\nIf the BIOS has an externally facing port without ExternalFacingPort or \nDmaProperty it's going to cause problems in Windows too.\n\nhttps://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports\n\nNow granted; in Linux we might be using this a little bit differently.\n\nIf we were going to do /anything/ in Linux - I would say adding \npci_is_thunderbolt_attached() as another criteria that marks devices as \nremovable is what makes sense.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256\n header.s=selector1 header.b=kpWU89Ao;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-52365-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com\n header.b=\"kpWU89Ao\"","smtp.subspace.kernel.org;\n arc=fail smtp.client-ip=52.101.43.25","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=amd.com","smtp.subspace.kernel.org;\n spf=fail smtp.mailfrom=amd.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=amd.com;"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fszf31WLmz1yCv\n\tfor ; Sat, 11 Apr 2026 13:28:27 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 31DEF30164EC\n\tfor ; Sat, 11 Apr 2026 03:28:24 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CD4442571A0;\n\tSat, 11 Apr 2026 03:28:20 +0000 (UTC)","from SJ2PR03CU001.outbound.protection.outlook.com\n (mail-westusazon11012025.outbound.protection.outlook.com [52.101.43.25])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 438E619C546\n\tfor ; Sat, 11 Apr 2026 03:28:19 +0000 (UTC)","from SA0PR12MB4557.namprd12.prod.outlook.com (2603:10b6:806:9d::10)\n by DM4PR12MB6304.namprd12.prod.outlook.com (2603:10b6:8:a2::7) with Microsoft\n SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.20.9769.46; Sat, 11 Apr 2026 03:28:16 +0000","from SA0PR12MB4557.namprd12.prod.outlook.com\n ([fe80::885a:79b3:8288:287]) by SA0PR12MB4557.namprd12.prod.outlook.com\n ([fe80::885a:79b3:8288:287%5]) with mapi id 15.20.9769.041; Sat, 11 Apr 2026\n 03:28:16 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775878100; cv=fail;\n b=ZeK1f+PRdABT2bvB2Vu0EXKe6Mx7BjkD/0PAl+lkjVMh7lpoRdx0ox0Ly6/5GwI4Lm+P5o4DrYpq9w7/+owzK1TCd4erP12bsQxH0+RHYlNOQ8RXU9mX+QgsmXzT1XiB67YSQ/e/lt9aGapU1G0wlxdMyKweLstRaew330IeciU=","i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=YhJBs34uqpkxT1k3QyeUJf4k81l7TKqWgA8aCpU/lYxaPflg7mRWId1qeDadsjGFVVVAU8XfMBnmxsAGsKB0AzhL7vjcpg0DKgp/LbrNmT1OR11GrE1vbf6H3hkW2Yb9TZAMqDNjHl7U9ziwQXWVWEYvxuBUqtlgElsAEg0R3I4XgcqUKobSPymO3IWMTcU9kKMbEYWYO7jJxDjxAScPIDX5M8gdV8sV6qBDvj5RBZ1wQih69Iu5P2/IUwSGSrBsePs7LD/LVZJYiPZOi9RfxX8Cs00eGqipmoGkmEunyNW9NHiv17WdQjqNFvAPC4Cis12THbHHLZw4ynTFMlZ9IQ=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775878100; c=relaxed/simple;\n\tbh=fPd+7SEbFDTTkEZArEDOXO6V6dZJlJcidX3+aJ6c1Ik=;\n\th=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:\n\t Content-Type:MIME-Version;\n b=S1wir1Q7CDSNlxTVZJYDqY3AhPp0JwWerszPcl2g04XxpsMDRjt5yoiKbsUK69AwkJth1PBziWO/nviHMT4b1L1lSeRt6lVlwMM6ipsiPkyLVr6Xl67ynpOY+DuZAi8kKyuPiMUAbvT/JqHUov+4iZYYPPBs4qCxJWckAJOLSSE=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=FZy5hgkh+I+kGeWmgH7gHf8WXmeLcqIaxDvMVhwTPs0=;\n b=n/KXMdCLxKdB5HSPTzKWVLqauTICy3ti0t2v2BS92atufgjz2sAeuAvkcW3qIrjDSMfYb84puSYg7609IHMU5BzuZ0XMHAX6RRROvH/jX0lVLx46nRHm2TV5ABl3CmmTCaQjHbMKeVBsNopiBJF9fDM3NphqyWBdvDW05arHP8dGKJJNMjgaDGyACIkY0m0sS2tHZTo/JkldGrbE74RMd/N/QZr0i/7V3qn0Az4ie16vE34SOD8N7Quegnk18UDpGh+e8M4J6FuQzYWSLNpplmbVnIaoOMkdyXpD27FO0P9/YubMiqOpdN5SZR4B3TDvwihvMb5EcZs1xRB11swuHg=="],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=amd.com;\n spf=fail smtp.mailfrom=amd.com;\n dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com\n header.b=kpWU89Ao; arc=fail smtp.client-ip=52.101.43.25","i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass\n header.d=amd.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=FZy5hgkh+I+kGeWmgH7gHf8WXmeLcqIaxDvMVhwTPs0=;\n b=kpWU89AosxVndDQFE193lTnINos+ilZPsPGRLmt5wb32R17Lo9h+DOq+qYOrqDxr40WkO+Ae1G3M4sbm5VkQCwQ/MT3emRYmP90Zip3gqQQ6svEVU2T/nZpZUzjmZE0h+J1N1GcPcZQYk9xLosjxL0iVgbL4GgEAhF9KjamIx6M=","Message-ID":"<2fe254c2-38f2-4213-9055-43b810502ccd@amd.com>","Date":"Fri, 10 Apr 2026 22:28:13 -0500","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","Content-Language":"en-US","To":"Cristian Cocos , Geramy Loveless ","Cc":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n linux-pci@vger.kernel.org,\n =?utf-8?q?Christian_K=C3=B6nig?= ","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n \n \n \n \n \n <58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>","From":"Mario Limonciello ","In-Reply-To":"<58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"SN7PR04CA0054.namprd04.prod.outlook.com\n (2603:10b6:806:120::29) To SA0PR12MB4557.namprd12.prod.outlook.com\n (2603:10b6:806:9d::10)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"SA0PR12MB4557:EE_|DM4PR12MB6304:EE_","X-MS-Office365-Filtering-Correlation-Id":"41115a77-d428-482e-ec07-08de977a5e56","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"\n\tBCL:0;ARA:13230040|376014|1800799024|366016|22082099003|18002099003|56012099003;","X-Microsoft-Antispam-Message-Info":"\n\t9RD0/85i6xEjSJBF3xOxp9hdo8y65AUMFnLK4lSl1dWCf1NYhF1CgWWw9IXszqCHkoTUWY5jhHVzNA5L0RxqC8lYjia6MUkqs2Gja2oikA9f0Azr8FPqQV3Rx+Q+uy9Z7Idqhd1e4UvIQdZO12voUU3EWsSA2u2g6I4N+mLU5pBfBsow2Q/wgH0FE4/LDqwYDVzoqkl422k7OIo/BkagjULlG4PLZyTTnYyzk8Be7PPQ0+HNDVgnuinmfDp1TaoN1hNuHVrFR6OKbMcK0QJqi2LBP1s7zWpAlELJ6GM37JkcWNI8sS9kht2LkJeeCKlStCitebciP3zyeq+u7DGvQUswPqpI4Evf/01B/DFUMLf0/BrldX6qqyWYAdIfkBRQkeLkzLisKEna4w7Z1VhuSJXNw3omHh4IEBRdhjq/t4G5Zy39mqn7SdAi3au0+qJnEPdY5VU9qfJTBJgzJaSmXRChU8fP9xGt20joGrcR//Fc4dsgoLq0iZ2FMrQ10I4UDKWHt0PRJlSfiFZM0ORKhh0C1/6sR0q9pTewoza+4WzYMaoO3d8Tsn+VYubaupp3muQW+ppKQnxzrqbNBxypvcWIA6wYZZy2AXDpeJpIRYPDmJABJdU/mR+Mq0ZCEGqx3ZzHo6pTLV6j1dmXwaUozr/fLxh09hVmoecTf29g4g8rCXyr7Nn4lS4vmtjXKZ/LXfr5f0i+ZQL9w/YJ8OPfgRZvZS1ZWnedCtNy1fgf0lTgaSreM5/uxz9q9yK90EfP","X-Forefront-Antispam-Report":"\n\tCIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR12MB4557.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"=?utf-8?q?a7TsMDHjjrJhNdlSqfxJiEji176k?=\n\t=?utf-8?q?BUCzFCMgqA0kolWBISD/perdiGCOMyIPGHR/Z5hm5w84ljcneEif28lAaeLHjNgty?=\n\t=?utf-8?q?13p4ds7dl4ndymlK4vK5w3MJ/044ifugu6sHzlS8zvTTv8+/p3LjviIBhKHPiw0AW?=\n\t=?utf-8?q?erX+ebr/sIDjg+vu3hMHz0FaIuubWNolLcO58ZHscU/yoOSzLOSSg47kn1RpXJc0U?=\n\t=?utf-8?q?Lq25NqN3xrd4ontKNeud+roZyMU81OvgWpNTzj4MHdSGDhIffIl/pUSKRd1EDg5Io?=\n\t=?utf-8?q?ZH/Fe/sBB2IXujk5RZ2GkGNsozgXMWeUmHwjfa4RDL4oXxZK/bkFt3qVjiifSNuEW?=\n\t=?utf-8?q?fjYhxdnRDhn4qmHM86DDSyfkvIcqeEjNPY20D/sVNNTQlANB8S8O6Q/5f7G8m1Pfe?=\n\t=?utf-8?q?Rz/Oc+MCr72T1z9XrUPLefACRZssBfdQAzpFtG38eMErtfcmHw3z/eXEVi0ad339j?=\n\t=?utf-8?q?js2MDe+Y5sTSBgHHsC+BKJGYx5chsue/xxoHLFVqcRQK8ELCe5JTWLUYkVPe9XjAR?=\n\t=?utf-8?q?otYS3ezU0nwaKzyd6lxcof9ViihghHkZtWOLB1UedV8qx0csuFVkGtVP7hMxOwnSV?=\n\t=?utf-8?q?koW65AEp1WPxYZaEuc4REu6lUeR4k4uZqW7NdBXXX9Ljtqrki/2peQOJ6jkXinGRZ?=\n\t=?utf-8?q?6L5epMkiqv+7kFaZUlNWmg3fA1c4fbiI71hlEwKikX8aYOePMW2Dm58uSGgTL+yu2?=\n\t=?utf-8?q?UQyZzU0Zs3Ja19r0HTpjFr7OwGBs7OW2l1vaz63429HCNu5HbgYc27prS84tVclsG?=\n\t=?utf-8?q?1GBJ9oZKeUF3WkwlAy1isB6d+tstuAEVVbcmb8jgPsmOM0FvhZZrgRXLHADIf5E2E?=\n\t=?utf-8?q?9D0N+hkhQWDtEpuiCdFXGTfMhpAJtI1jO9DdoWGzDx14M6qSkTEPC2GyhDYd/GZod?=\n\t=?utf-8?q?I6Amglll0QAhM+Lj1We2naIkId6XKAnnxmWizQLv2AneJxU8LEHgV5wxc9y0LocNu?=\n\t=?utf-8?q?+4j/HxbBOobP3DKhsctGYW9PcQc68kkGV/y+/8DqclRP0V92m2eCse9bzZj1SRWTP?=\n\t=?utf-8?q?ySGI3EbzeWtputyrDqXpT7uf3TR+9JZ15vLbh7WpmqbfudscJrIifIDNvzHXejXoW?=\n\t=?utf-8?q?jerbNAOuAtnhes2OkU36GuPyXdSFjlNOYPaTBTzeB54XR6NTiJbkUPehlwAPViov2?=\n\t=?utf-8?q?sfbgEVDJHnpFh0VW4Pz3iIgWi3o+7AKNXLp6WFe/sBEX9ZqzM2ndCm94ZCloK6jCc?=\n\t=?utf-8?q?X4a7W+5rOQrGF5mlq8ik/btW+Xvxn838xQJpdWOzunvbOhBcV/iSbITTlk4eEvAy/?=\n\t=?utf-8?q?exlmB5FkIZM2KdbXeSELQpda9X3xk5YxICKbGl1YcL2cHZO9n7CFH4rTi6yagcIXJ?=\n\t=?utf-8?q?tNMXiWz79xoSFtesLZ3aD4z3jyYX1Gum1LhIZ2ZB+oMxO8s+dXBEqD4uNeBKNPWsS?=\n\t=?utf-8?q?CQLVJMhllQZ0sxfakmLrYZ4QGdm4LparofSbNtI6o+/kbs+SLwzpS0QVzt7w2gXvG?=\n\t=?utf-8?q?BhtFCyW/1rGDk+DwVn7c5u6ea0OwVnc3MqqTIF/WX+6bfGXk/TrbBTilN8XRAWFZB?=\n\t=?utf-8?q?dnDJXkfT7/OcXVrw+GFlSeU4rhQH5GT1/KB/Ih2SZQ+c0A2PGL+aUaok4fNhcGLjx?=\n\t=?utf-8?q?2g+OC0bIbNHCF92qle/3sTW5lF4PiD55BD2l/JT+p2qqdm+r1pg3rmEAtv9p+7kd3?=\n\t=?utf-8?q?9La5RYkMth?=","X-OriginatorOrg":"amd.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 41115a77-d428-482e-ec07-08de977a5e56","X-MS-Exchange-CrossTenant-AuthSource":"SA0PR12MB4557.namprd12.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"11 Apr 2026 03:28:15.9537\n (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"3dd8961f-e488-4e60-8e11-a82d994e183d","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n +v3EsqSnp/jm30/OuxujlPPtrOKsXWlIYmYXNlu8P9hDNWuBwksaUcYc7Tn4Gc1pbvWLpYnwpIIjw7H654KzqA==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DM4PR12MB6304"}},{"id":3676183,"web_url":"http://patchwork.ozlabs.org/comment/3676183/","msgid":"","list_archive_url":null,"date":"2026-04-11T16:30:15","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":93094,"url":"http://patchwork.ozlabs.org/api/people/93094/","name":"Geramy Loveless","email":"gloveless@jqluv.com"},"content":"Mario,\n\nYeah I would consider this a bios bug but it seems the MS-S1 isn’t the\nonly one with it. I’m not sure how bios development goes together or\nwho standardizes the ACPI table that would be the right way to fix\nthis.\n\nI would think the faster way is to adapt the AMD driver to use the\nThunderbolt provided function in the kernel to detect if it’s on a hot\nplug table port. Which would only work on driver versions that where\nintroduced during the time the kernel had that new capability. It\ncould get backported / patched. That in my eyes would be the fastest\nresolution, correct or not. We could update the ACPI table during\nkernel load but that seems a lot more hacky then using pre-existing\nthunderbolt provided functionality for detecting if the device is on\nThunderbolt.\n\nI already patched the driver with the additional thunderbolt function\ncall, I’m not seeing any problems at all. My kernel loaded with the\ndevices connected and made it the primary display PITA but Linux has\nalways been a PITA for displays haha. :) once done what is your\nrecommendations for submitting all 8 patches I believe or should I\njust do one for adding “is thunderbolt” function call?\n\nSorry about the last reply my phone doesnt like text only mode.\n\nThanks!\n\n\n\nGeramy L. Loveless\nFounder & Chief Innovation Officer\n\nJQluv.net, Inc.\nSite: JQluv.com\nMobile: 559.999.1557\nOffice: 1 (877) 44 JQluv\n\n\n\n\nOn Fri, Apr 10, 2026 at 8:28 PM Mario Limonciello\n wrote:\n>\n>\n>\n> On 4/10/26 18:21, Cristian Cocos wrote:\n> > [You don't often get email from cristi@ieee.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]\n> >\n> > In *Windows*, yes, GPUs have indeed been supported in eGPU\n> > configuration, though not so much in Linux(!). The troubles we are\n> > currently experiencing, esp. concerning hot-plugging, have not been\n> > reported simply because eGPUs in Linux has, so far, been a very niche,\n> > limited application. In other words, it's not that these issues have\n> > not been around, it's just that they have not been REPORTED due to a\n> > very limited pool of users running Linux in eGPU configuration. GPU\n> > manufacturers have thus focused on patching up bugs in Windows, while\n> > hot-plugging-Thunderbolt-eGPUs-in-Linux has fallen onto the back burner\n> > due to its small market share. As such, I doubt that TB5 has anything\n> > to do with all this.\n> >\n> > On Fri, 2026-04-10 at 16:01 -0700, Geramy Loveless wrote:\n> >> So after a while of doing investigations I keep thinking, gpus have\n> >> supported hotplug or so i would believe for a while ever since at\n> >> least thunderbolt 4 and possibly older styles too of hotplug as well\n> >> as dual gpu machines like laptops that have a dedicated and\n> >> integrated. I would think all of these problems we are seeing is most\n> >> likely due to something very specific to thunderbolt 5. So here is a\n> >> theory.\n> >>\n> >> Root port ACPI device: \\_SB_.PCI0.GP10 at address 0x00030002 = PCI\n> >> 00:03.2\n> >> Its _DSD (Device-Specific Data) contains only:\n> >> \"FundamentalDeviceResetTriggeredOnD3ToD0\" = 1\n> >>\n> >> No ExternalFacingPort property. The firmware gives it a D3-to-D0\n> >> reset\n> >> hint but never declares it as external-facing.\n> >> For comparison, a properly configured system would have:\n> >>\n> >> Package {\"ExternalFacingPort\", 1},\n> >> Package {\"DmaProperty\", 1},\n> >>\n> >> The complete proof chain:\n> >>\n> >> DSDT (/tmp/dsdt.dsl:4194-4205): GP10 (00:03.2) _DSD has no\n> >> ExternalFacingPort\n> >> pci_acpi_set_external_facing() (pci-acpi.c:1422):\n> >> device_property_read_u8(\"ExternalFacingPort\") fails → external_facing\n> >> stays 0\n> >> pci_set_removable() (probe.c:1780): parent not removable → falls\n> >> through\n> >> arch_pci_dev_is_removable() (arch/x86/pci/acpi.c:353):\n> >> !root->external_facing → returns false\n> >> Result: dev->removable never set to DEVICE_REMOVABLE on any device in\n> >> the chain\n> >>\n> >> Sysfs proof:\n> >> 00:03.2: removable=N/A, external_facing=N/A\n> >> 65:00.0: removable=N/A\n> >> 66:03.0: removable=N/A (TB bridge with HotPlug+ Surprise+)\n> >> 93:00.0: removable=N/A\n> >> 97:00.0: removable=N/A (eGPU — dev_is_removable() returns false)\n> >>\n> >> I'm not sure its correct so much but I have patched up the amdgpu\n> >> driver myself to use what its using now and \"||\n> >> pci_is_thunderbolt_attached\"\n> >> This might be entirely completely wrong :D but I figured I would see\n> >> what happens.\n> >>\n>\n> I would say it's wrong. We explicitly moved away from this because it's\n> only indicating there is an Intel VSEC:\n>\n> commit 7b1c6263eaf4f (\"drm/amdgpu: don't use pci_is_thunderbolt_attached()\")\n>\n> Isn't what you point out a BIOS bug?\n>\n> If the BIOS has an externally facing port without ExternalFacingPort or\n> DmaProperty it's going to cause problems in Windows too.\n>\n> https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports\n>\n> Now granted; in Linux we might be using this a little bit differently.\n>\n> If we were going to do /anything/ in Linux - I would say adding\n> pci_is_thunderbolt_attached() as another criteria that marks devices as\n> removable is what makes sense.\n>\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.a=rsa-sha256\n header.s=20251104 header.b=jg3SBPsO;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52400-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=\"jg3SBPsO\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.219.47","smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=jqluv.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ftK1L117Gz1yCx\n\tfor ; Sun, 12 Apr 2026 02:31:18 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 9CD323014BF5\n\tfor ; Sat, 11 Apr 2026 16:30:29 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A7EAA391E73;\n\tSat, 11 Apr 2026 16:30:28 +0000 (UTC)","from mail-qv1-f47.google.com (mail-qv1-f47.google.com\n [209.85.219.47])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FA843563E1\n\tfor ; Sat, 11 Apr 2026 16:30:26 +0000 (UTC)","by mail-qv1-f47.google.com with SMTP id\n 6a1803df08f44-8a08fa355a1so45224666d6.0\n for ; Sat, 11 Apr 2026 09:30:26 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775925028; cv=pass;\n b=P0JKX2adHhKFqzcFwq114ddODuC457FBTaG4fVAEoXCeaakexTINHq86xExXDvc00UQdfRaF1pb5YoAwaPFaM9Uj+uJuP1ed+w1BOKVbj2HUUHy9gSg0lgbrYckJSOIatJIyLMjQbGHHgWzxsgVfh2UBkwQ6a/xYodcoqjHeR60=","i=1; a=rsa-sha256; t=1775925026; cv=none;\n d=google.com; s=arc-20240605;\n b=dVJMWMEtSw8dsJT9g1hzR6U51ZzALwxQCeWKDaInEAdISW3IG4qLWvI2ihDzuLUbn3\n Addsp/d7vAhju1DsfHRADb8qJeB68weO1TlFkOAGSvvkeUElfPuDTp1vHl0cVjknZr8H\n zrb4UPLsAyq1JJs846rSiqXEBewzDOgJXLAmzEo9pk8WQ/knLZFP5NMXL72EbiMDs80Y\n fl9A/8QC6NpniLrl1AHRAVUKpkImA5ZyRQ6Vk2YEcYAWKEvrtGC1SQq9NGB91ByG9EUE\n IsMzPUoKe3w4mGTvXABv62VcEA7VDlL9/JSwcEhVOxCqvqSYe9/Ocw1BBWmZ5Okr45U2\n zgWw=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775925028; c=relaxed/simple;\n\tbh=QtP+iFUv4BWoWROfaSmBG7+inBADppzkL3R7RVdJ3SY=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=sXMzzhaVSg9bsBSSh67i7ck05/896RQwz2lgjCmkCd485BeWqRrLvD2nz4Nc9ykUixP2IsNc3ePWOvUpPEjefnNm5Ss3CB0lLQl604azYiVBkTSYBMeiX5tUj8MXrwkMjDg72PzmAIHuq8xtz2O8wZAzzbNcjAuBm9mLXBSXaNA=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=o5PfjSuV5cfy0EpfRDJ55yvjZtX21xPbkjl0mcI/Ids=;\n fh=xrHIWUIOS9Aq540F+ioHnaRod1/NGw0Oq5BxlMFl4cA=;\n b=VZoy3b8Obl7CGw2T9NAkpBcUCcFb16KLpdZ9xbtkwmw6BrHNBoZGGHMBU4TbJkLSl0\n ZHYMdDfdwfz/Hjq9UJdI7Ju4bh863D04BZLmtBe6vy+hRUTfjpoqCJ56VJpbvuwo5OcO\n SHzXUSlulCMe3F0FUEDJpWxG4yISbvTpAeGbCVx/ZiOpdUqkc6nhFCZc3hB4YHdCsYu6\n yPjgbtD2Os3J0LVAolrcEE/8NbGWWnD53FiOuaTAAk19R33/xCtGRffDfkkYw89Z5kxL\n adJzfn/azVJn1dP3yKO2Ep2iceSU7iQFZhi7UC/CgqP/wwa1vg6dDOh0pqn4fVVvo5rw\n gMqA==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=jqluv.com;\n spf=none smtp.mailfrom=jqluv.com;\n dkim=pass (2048-bit key) header.d=jqluv-com.20251104.gappssmtp.com\n header.i=@jqluv-com.20251104.gappssmtp.com header.b=jg3SBPsO;\n arc=pass smtp.client-ip=209.85.219.47","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=jqluv-com.20251104.gappssmtp.com; s=20251104; t=1775925026;\n x=1776529826; darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=o5PfjSuV5cfy0EpfRDJ55yvjZtX21xPbkjl0mcI/Ids=;\n b=jg3SBPsOG4eijn48KWPjSXw6cWHaatHArJm99NQnEraCsv1xXaF30mQ8TyZ0s3Bdto\n 2esNFSauK1QrLVWdNWuqEaMaQxnipZniuSpfxG2bO7YrF1EirEGO+7ecZWGW7VSINNva\n uLgCFb03qSI2BgG+yHC0WL2Brq5mUhQHtxC+esAOp8QMMwsrbVCi2tnm0eInHqE+/psg\n 21gO8e2No3fIu121MZufSvUfRat9IwGtNZYnEEARA7+UpCYOrfTzmf933otxUijd3EgY\n kbjrxrfOW1wdFujhJz6UX67NZLIJf9wBZfURgUSI/rsx9xWdD2S0ecdoFAey0OfQySUL\n 4FHg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775925026; x=1776529826;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=o5PfjSuV5cfy0EpfRDJ55yvjZtX21xPbkjl0mcI/Ids=;\n b=aA0ETsk9pnMzc6WAGgVYZOfNdF6vpQ33FNB40DZBti+UYsNYGKHQJxcHwM4ChoBTqK\n RVh4gqzih28oytwyUMbpjFNywkSoel0Pfb9bM6w2ueP0CHyhXA9kdynM9c5LKtOMzxR7\n OlhPCbfmRwchJJtyC8WdFDUCGBIX1/2hH4tDnwlouPPCxmjc7pYCFJMaTd/a2HjbPso5\n AhvW1zReIz1ierHdR6Q92aPKZvzEWQI7X8JMlj5EqlCckq7HHjYarBaLWWiGsFU7EjLH\n D1+i+y1sfxX8pj04hjS39pXd84y9F2oxB8pfaSGxrpXSBERbHJkkSR2royZArXe3wlcT\n mxlw==","X-Forwarded-Encrypted":"i=1;\n AJvYcCU/88xHnymiqHPDiJPIRZVk2OfwI2kcMSHIiz45sI/PcARcIYNKV94w5EyXIXJPFRHM0GF4O/KuAOo=@vger.kernel.org","X-Gm-Message-State":"AOJu0Ywz1YwB1yuIR385mOaJY8sCCtKadnp6T25EsVs4IkSoL9knXLNS\n\tZOBXiXez27JqP60S0nix0HyBRF8QO4/pdy18+T2JHIvCwhuyqwWlmEmt8JsrOGKYadvfML7TPRM\n\tzgpDyyS2GTwa/LNxQ9C+zobqyG4Iuqb0HZRxZBM5XvQ==","X-Gm-Gg":"AeBDievi05I35fNiRwK0aQ3G/ZlQIalWQ3vFAkdOathh4z01rgX5TAKdeyEE8XMsmLD\n\tP+AHWs69aW9Jay7vU6N9m5wLSjRmMuocyX1xZrt/Pg35/bsb1yTGwIWZzmZ9bnv7nTFDaL3fHq2\n\tAGq6DFm+dEaKB5uRg6zDpiZ36k9na5KVAB0mziqKk5bSLiw1rNDLe8x+7tjLit+v9eVvpb2ruzS\n\t/mBypNSMDC1QSMiWrovKijwjWkFn4vnEcYaArec/D1n/Q0l5kIsY9wLBeywSiUdYxjQdrG4Buy8\n\tNRR0/FmSyLLtqqEmvpcF9s+/8fWWhLJTMlR/gbVq0Rz4YS4zuHY=","X-Received":"by 2002:a05:6214:29c4:b0:89c:4be3:5d6 with SMTP id\n 6a1803df08f44-8ac8628471fmr118062956d6.29.1775925025989; Sat, 11 Apr 2026\n 09:30:25 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n \n \n \n \n \n <58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>\n <2fe254c2-38f2-4213-9055-43b810502ccd@amd.com>","In-Reply-To":"<2fe254c2-38f2-4213-9055-43b810502ccd@amd.com>","From":"Geramy Loveless ","Date":"Sat, 11 Apr 2026 09:30:15 -0700","X-Gm-Features":"AQROBzBh-0-nocVIYn4NRFNNSpAlBs8_SzGCGqlrX5q9AfDD1vpJl5HS0KigoZQ","Message-ID":"\n ","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","To":"Mario Limonciello ","Cc":"Cristian Cocos ,\n =?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n linux-pci@vger.kernel.org,\n =?utf-8?q?Christian_K=C3=B6nig?= ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3676199,"web_url":"http://patchwork.ozlabs.org/comment/3676199/","msgid":"","list_archive_url":null,"date":"2026-04-11T17:42:31","subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","submitter":{"id":81779,"url":"http://patchwork.ozlabs.org/api/people/81779/","name":"Mario Limonciello","email":"Mario.Limonciello@amd.com"},"content":"On 4/11/26 11:30, Geramy Loveless wrote:\n> Mario,\n> \n> Yeah I would consider this a bios bug but it seems the MS-S1 isn’t the\n> only one with it. I’m not sure how bios development goes together or\n> who standardizes the ACPI table that would be the right way to fix\n> this.\n\nBIOS development is generally done by independent BIOS vendors (IBVs). \nThese vendors work with OEM and ODM for BIOS solutions. It's entirely \npossible the same problem happens on multiple systems, but it doesn't \nchange the fact it's a BIOS issue.\n\n> \n> I would think the faster way is to adapt the AMD driver to use the\n> Thunderbolt provided function in the kernel to detect if it’s on a hot\n> plug table port. \n > Which would only work on driver versions that where> introduced \nduring the time the kernel had that new capability. It\n> could get backported / patched. That in my eyes would be the fastest\n> resolution, correct or not.\n\nWe shouldn't choose a solution based upon how quickly it can be merged.\n\nBut in terms of a solution to this BIOS issue, what is wrong with adding\nthat it's thunderbolt connected \"to the cases\" that it was detected as\nremovable?\n\nThen it can be applied to all drivers that use a removable check; not \njust amdgpu.\n\n> We could update the ACPI table during\n> kernel load but that seems a lot more hacky then using pre-existing\n> thunderbolt provided functionality for detecting if the device is on\n> Thunderbolt.\n\nRight - we shouldn't look at ACPI table modification for a kernel \nsolution. You can try this locally to prove that things work properly \nwith what appears as a correct BIOS though.\n\n> \n> I already patched the driver with the additional thunderbolt function\n> call, I’m not seeing any problems at all. My kernel loaded with the\n> devices connected and made it the primary display PITA but Linux has\n> always been a PITA for displays haha. :) once done what is your\n> recommendations for submitting all 8 patches I believe or should I\n> just do one for adding “is thunderbolt” function call?\n> \n> Sorry about the last reply my phone doesnt like text only mode.\n> \n> Thanks!\n\nI'd say try adding it as one of the cases to removable detection and see \nhow well that works.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256\n header.s=selector1 header.b=kfqlek5/;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52401-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com\n header.b=\"kfqlek5/\"","smtp.subspace.kernel.org;\n arc=fail smtp.client-ip=40.93.198.61","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=amd.com","smtp.subspace.kernel.org;\n spf=fail smtp.mailfrom=amd.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=amd.com;"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ftLbn3J2jz1yGb\n\tfor ; Sun, 12 Apr 2026 03:42:45 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 4CF493019833\n\tfor ; Sat, 11 Apr 2026 17:42:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2928E40DFC5;\n\tSat, 11 Apr 2026 17:42:40 +0000 (UTC)","from CY7PR03CU001.outbound.protection.outlook.com\n (mail-westcentralusazon11010061.outbound.protection.outlook.com\n [40.93.198.61])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id BE9D823BD1B\n\tfor ; Sat, 11 Apr 2026 17:42:38 +0000 (UTC)","from SA0PR12MB4557.namprd12.prod.outlook.com (2603:10b6:806:9d::10)\n by MN2PR12MB4342.namprd12.prod.outlook.com (2603:10b6:208:264::7) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.46; Sat, 11 Apr\n 2026 17:42:34 +0000","from SA0PR12MB4557.namprd12.prod.outlook.com\n ([fe80::885a:79b3:8288:287]) by SA0PR12MB4557.namprd12.prod.outlook.com\n ([fe80::885a:79b3:8288:287%5]) with mapi id 15.20.9769.041; Sat, 11 Apr 2026\n 17:42:34 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775929360; cv=fail;\n b=J1gdEm5N1WwlvPp+Pim5yOuBYd49DZSF4dptp8EClEJb0bO6GmzE3SkFW85/+Tv9XIuU+l9itKP6fWU/xbi9n4l907+hXnJ25p/2qPXgdK4Rq7KIexJjX5btBRGRKz7zBweFYBRHmdZsSOSRFwpz3DohrB3MUGUfHHRf5A2ekaM=","i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=W1r5Bgrxh993jb8yQh5+zvrDHfaQIMOGcV6QmMUitSBGe5UWukDfe9KIg89uuVuUm7vhwJiYgEPESGjx+twDVmc2K7lITWuBJFI/oJtszSgP/ZYChoqX/uLYZr3ktCRb8j36nryWo8yePKdXy9PPBKDtbgB7E3iIeeVzjVbwP34yW07SimuCpS5qNVuG8BRGcfuO9H2kubEC4fzGDqxjlVaQEpaKbMXoa7ykt9UruVC71XUq0nK0Lmj6WsN9cE0HSSXEGqrPJHE5cz6/UK+hXF9vTK7Nq2wllso2QfcemSyO+y58Xhjifva6E+nzxCUvAfUTunb5PArLv+X0+dK7EA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775929360; c=relaxed/simple;\n\tbh=fUEfRwAjOYQApdXoRWZDUMZAHN3EntaD7NmKGSu2M1Q=;\n\th=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:\n\t Content-Type:MIME-Version;\n b=b9F3Vtljat56jSPqR9hKx4NyhewC7q6NNYg2VAO8cR2I2MV1olVMZIZC2NNlspQi2uhtSVQfpukKGzzGeMhs/xpwNEMFc+7WOUzDHAoML2i/gAbvlS1leqRGf+cUUS7pYEua49M9UZsUq3O67zZTOam6zsqQTCzUXZGGr7PM3u4=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=4C8hlr/FkkQJISkJEIoryFzBDDU4YlYqkSrOXk/x0i8=;\n b=rrPTdpMRnlwzJXwz8QBGyCH1Oz59xsldURmaJc+m4ir7jPEaBy12tC2rWIr01atwQ6XpyCuwEzka8q9blAjR9EeXalSWOUjCU+ZLfvUQKEzIjr4t/TzZIAMG1wfkNVWZwV+tnoDSWL0OkcmdIz82hUiWLS1Xd4ESBGNHAXH5iJNtrmx5Qn6yYgtNpFDnDq7CU5FbfReG1bSk2kM6FPqoMglFbiB+VAsBI+jaFt9QnyWoMl2K0hdKYgBkVnzMKPVmKqOssNQ7OZ45LsdxijYGe0BVJ2afzCpbZjdLRcOurS5gqqNx+BEgqt/gng/SjXzlKwDiWoipoW9oUjW1Ncusdw=="],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=amd.com;\n spf=fail smtp.mailfrom=amd.com;\n dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com\n header.b=kfqlek5/; arc=fail smtp.client-ip=40.93.198.61","i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass\n header.d=amd.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=4C8hlr/FkkQJISkJEIoryFzBDDU4YlYqkSrOXk/x0i8=;\n b=kfqlek5/7niJ9Df1o5da297d1z/IrPn5PH1VCXfA75WnxqqHZwNEYVsmhLTAiGw3u8OAdSXR8bKa1ACWvPbt5DKtzZcBqHaMZQX+Yns4bGQfgFLszUovdr0XTa1Y5jQwglmgXDRMPhm2IS7QlU/ZimZQWBMLFZ15eH/90CppnXY=","Message-ID":"","Date":"Sat, 11 Apr 2026 12:42:31 -0500","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar\n expansion","To":"Geramy Loveless ","Cc":"Cristian Cocos ,\n =?utf-8?q?Ilpo_J=C3=A4rvinen?= ,\n linux-pci@vger.kernel.org,\n =?utf-8?q?Christian_K=C3=B6nig?= ","References":"<29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org>\n <20260410052918.5556-2-gloveless@jqluv.com>\n \n \n \n \n \n <58b240e489d3a4d41e7dbbe5720b80c310700582.camel@ieee.org>\n <2fe254c2-38f2-4213-9055-43b810502ccd@amd.com>\n ","Content-Language":"en-US","From":"Mario Limonciello ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"SA9P221CA0006.NAMP221.PROD.OUTLOOK.COM\n (2603:10b6:806:25::11) To SA0PR12MB4557.namprd12.prod.outlook.com\n (2603:10b6:806:9d::10)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"SA0PR12MB4557:EE_|MN2PR12MB4342:EE_","X-MS-Office365-Filtering-Correlation-Id":"061917f7-9843-467d-329d-08de97f1b6b5","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"\n\tBCL:0;ARA:13230040|1800799024|366016|376014|18002099003|56012099003|22082099003;","X-Microsoft-Antispam-Message-Info":"\n\tVZR/zU3KLUvXVusOlkfFPH9oUbXeftmuN8N/vumrmLZU4lLgO+lbrDGc4XO9UpAgppK+mMNjry6aD8YgC7xw2oHBuy0m4UofISrz2+P8elBLqz87RyCa0iOn3OrWHrq0vQ+ffRZ56Pju0GpHkeDrFmREnZVsWDXIBf4b8NfFk1am4jCC42dVQlKvWudjWturraKlOm4dnBk8QgGCeVKOYcIDDXP0+GeqDTZV2qASoxauxYUZFkIgBNwf/xVFVZW0lA1l5LRQyJ4PHEig1iTg0jKM9HaD9GCoGC+Gky6oQYRZHkQaEnGeWSpeAQE1dqyrgYi/9nGIj6JBcDLNxefL6CyY4u+ktscIapz/Y/8SSnwRfNhZ65DOuDQOhXozM3yFHOqdeXtoGZenQLMa63AbT2+4XnzoXZ3fgRXFVXOBPaDU9LbDZFO/pYfes4DmRzx449T5OkKeFEFHOp00UVz+LwotFkQv0sQHbbshkS3iRelHIHHxIXl0uMhftfFSPQVgbuFqs03HUFG1mLccd91rx88QSB4472OcXPmMdmIluunoJFfYyoemsZgqBsVkc56blt2KKqxjdozvfLDOHsjrVsg+R6U+E3+mLRYLVtO+GA5g4EoyMW10gsSaLmAGuW3Q8LQ2KPojixI93xBLR5DUkrAUP5OsOWvQJWF92GmtEznHjqV/gn39UONJZA0yZ87CMDgjQDe9zmvTs8a3F3WQlDPQUrPsjg0YVPX8RcWRm9c=","X-Forefront-Antispam-Report":"\n\tCIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR12MB4557.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1101;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"=?utf-8?q?ZA8+/mUu7dIOY9BQryScxOp4+QAX?=\n\t=?utf-8?q?cU9GB8X7sdVJi2ajpCgLewTu6ZxCn0oWHC3hN89EzVDpmylTc9Tk7YvbIkMLJmcMO?=\n\t=?utf-8?q?a43milXFuGIfr77muApeAo08ZtKBfNkWZRuJVtgoyCJ/y45HSPGI/WJdRz11OauNK?=\n\t=?utf-8?q?JPVLSEgzjMntvukd1dgFr3qkVLSiG/nUwbtQ5EGnlD38An1g13SwwvFCPrtbFbpjC?=\n\t=?utf-8?q?kkbrmkCDxTWnI1JQJ2e5g2CiI/pxa9oQ3VpEnKuLgY32fO3f8k3oGZPGL0vUvxkPs?=\n\t=?utf-8?q?2/t+Kfg8H7de11EgYesy7KSYm5q5hqt/LSmKZ1KFTqtbjxZdJLoaXoyg6ZLo44cj3?=\n\t=?utf-8?q?SK9jqoDMnxu81YugpNxXrm6rMjtfBcCkGkPQWddG+FLQO/CdlB9rEBKGqDkwK44q5?=\n\t=?utf-8?q?3Xa/900ouUuEV/OicQkIP/BeMt0P4v3qoMcEXgl8CP4WYjoLLL+CfMwpN9DpvO5BI?=\n\t=?utf-8?q?JzKg/ljgInlscrji1Xl7euCNaYUvrYeUSAJZcnJ6b5y9BAmmr8VUmZ1XkNfGJ5Ohx?=\n\t=?utf-8?q?lLDX6ubRUtmPdO0SFWFYQi/woJcKk2OPPZNdcPxpN7wZPomRvpiSyBDkXj4gut27a?=\n\t=?utf-8?q?d1JMs8fUP12k/KtcJ+aMjqQYhEgCOB/0Zhf5c000n9AvqPlgRUPKV+7t5Rhoy8vRF?=\n\t=?utf-8?q?jQwxdNCfyH3a64uHJfg1ig1VhXy0V4QMdfYdG07gmfbznexu3PiKz1gc+OFfTtc25?=\n\t=?utf-8?q?pP6/ZlPfcCDZ9E4VZSAemcRQoijM3ZRv0zSCm+wq5+L1XaGozBwEzBEDttv0L46kb?=\n\t=?utf-8?q?yPWQ9Aua7C9bkBwXBLpa6Y1NrRe6WGs+LYesZ1H3r1PTI8oWmH9NjyMGDQdpql9iq?=\n\t=?utf-8?q?UUK+Zyb5gPLOO2inYoZBj4Bo/nHmcdIaKikCJqWqcX5sxmgUM+wY5kS8xgZMS7zqU?=\n\t=?utf-8?q?ayXG+ogJspc4YoydctjChdArVus88gKZT+rNyX1izpHD5o5jZ+wfEUmSkllv2Ppac?=\n\t=?utf-8?q?/hBoeqcLcNWCDLhxA3fbIfAvHz78EfD0K7sHEgQsL+3a8fbfDV1HalNG3FLIXusi3?=\n\t=?utf-8?q?YklMRMj3EiHNdtrEOJENmCSVrRgX1fk+7uO9nUuA4lNLzzrht+groA9rbpePrjCiA?=\n\t=?utf-8?q?pOuQg7zkOVLqvkY9U8rZSKatbZV1omcHeRFJSBewSa05dJPLpNUVST86vpm9QGM0o?=\n\t=?utf-8?q?ssp5e3le9HOrUC4cIfY4JKmTP4SGg5e5DMpY+Q8+Zd1LeWTNz989uyZ5gaC5QDoE6?=\n\t=?utf-8?q?QOsHxDDrrPwGlREQfHnJfWA4ni/PkQufA+TvzAYPKwArDD1zawVumJSd4M4dlVsWR?=\n\t=?utf-8?q?8phWmQmUas79ur6yUK8N/Wj9oSJ7ypFLKtdhjUU1mhESMYHEe4gDxVO2aeRFDPYCi?=\n\t=?utf-8?q?ZAo1BwzIWXxrZ35vHDkGRzC55wcS6gQTYKpKS9NmxgHxJ9g85pyXgZv2sNbxhQjGJ?=\n\t=?utf-8?q?ap67S5IgRYYiiQmE+7UyJSwTdNJ4RKY67rwGz3w5eAmjyIW9KeKNx2WFAdHDspal6?=\n\t=?utf-8?q?TuYe392A8SZzpCULMb1zZz5OuYgyrWNZiOCMzp2NEQXIRpdYmHo/i2nWo/DW60nVw?=\n\t=?utf-8?q?UaX6f+cQ9XAnoLf4RRgjdGhfSpLsE2qbmfzsK30WXLDcjtt3LM3Gq5XsrQK7qvI8y?=\n\t=?utf-8?q?ZiLcrz1+T+LBIjhZQWzZFgDeqWRO/jbmblKyormYkAHZ6XswGoe8nscx1zS9ExBbZ?=\n\t=?utf-8?q?fkDlFP6nFU?=","X-OriginatorOrg":"amd.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 061917f7-9843-467d-329d-08de97f1b6b5","X-MS-Exchange-CrossTenant-AuthSource":"SA0PR12MB4557.namprd12.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"11 Apr 2026 17:42:34.3408\n (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"3dd8961f-e488-4e60-8e11-a82d994e183d","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n 6ZIVmz9GtWam8FB0UqiTQn1156PHKkiknAgc0FrDRaJ7g0VZF1Mh5v1p4fYzyIH/K0JiY+dCkk0wtHiB7ZIsuQ==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MN2PR12MB4342"}}]