[SRU][R][PATCH 00/13] Export IP discovery even if amdgpu probe fails
Lin, Leo
Leo.Lin at amd.com
Tue Jul 7 06:46:36 UTC 2026
>
>
>
>________________________________________
>From: Hui Wang <hui.wang at canonical.com>
>Sent: Tuesday, July 7, 2026 10:34 AM
>To: Lin, Leo; kernel-team at lists.ubuntu.com
>Subject: Re: [SRU][R][PATCH 00/13] Export IP discovery even if amdgpu probe fails
>
>[You don't often get email from hui.wang at canonical.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
>On 7/6/26 14:43, Yo-Jung Leo Lin (AMD) via kernel-team wrote:
>> BugLink: https://bugs.launchpad.net/bugs/2158690
>>
>> [ Impact ]
>>
>> The amdgpu probing sequence can fail for any multitude of reasons (missing firmware, missing NPI support, unexpected hardware response).
>>
>> Ideally; we would have all NPI support in Ubuntu at product launch, but due to kernel schedule this isn't always feasible; particularly for dGPUs.
>>
>> For missing NPI support on dGPU specifically we want to be able to identify the system though so that we can potentially offer DKMS package from amdgpu-install script.
>>
>> To support this need there are changes introduced that will export IP discovery information to userspace even during probe failure.
>
>What does the IP discovery info look like? how is it used by dkms in
>general?
Hi Hui,
The ip_discovery/ direcory contains a bunch of directories and symlinks whose hierarchy reflects the topology IP blocks on devices intended to bind with the amdgpu driver.
You can find this in /sys/bus/pci/devices/<BDF>/ip_discovery. They look like this. (The files are read-only information for each IP-blocks).
```
ip_discovery/
└── die
└── 0
├── 1
│ └── 0
│ ├── base_addr
│ ├── harvest
│ ├── hw_id
│ ├── major
│ ├── minor
│ ├── num_base_addresses
│ ├── num_instance
│ └── revision
├── 108
│ └── 0
│ ├── base_addr
│ ├── harvest
│ ├── hw_id
│ ├── major
│ ├── minor
│ ├── num_base_addresses
│ ├── num_instance
│ └── revision
...
├── ACP -> 14
├── ATHUB -> 35
├── CLKA -> 6
├── DBGU_IO -> 45
├── DF -> 46
├── DMU -> 271
├── FCH -> 48
├── FUSE -> 5
├── GC -> 11
├── HDP -> 41
├── LSDMA -> 91
├── MMHUB -> 34
├── MP0 -> 255
├── MP1 -> 1
├── MP2 -> 2
├── NBIF -> 108
├── num_ips
├── OSSSYS -> 40
├── PCIE -> 70
├── SDMA0 -> 42
├── SMUIO -> 4
├── THM -> 3
├── UMC -> 150
├── UVD -> 12
└── VPE -> 21
```
The use case for this is not really the DKMS (I doubt if they even use it actually), but rather, the postmortems of probe failures of the in-tree amdgpu driver.
The point is that when the in-tree amdgpu driver in the stock image fails to probe, with this patchset it now leaves the result of ip_discovery/, so that we get to know on what exact hardware makes the in-tree amdgpu driver fail to probe, and decide how to fix it better.
(e.g. SRU the missing firmware, ask the user to shift to the DKMS driver temporarily etc.)
BR,
Leo
>
>Thanks.
>
>>
>> [ Fix ]
>>
>> The major patchsets are:
>>
>> 1. drm/amdgpu: Export ip_discovery sysfs on probe failure[1]: in linux-next 402e04f11ff7
>> 2. drm/amdgpu: clean up discovery and preempt sysfs entries on shutdown[2]: in linux-next 7de02fe95312
>> 3. drm/amdgpu: don't free standalone ip_discovery sysfs in sysfs_fini[3]: in linux-next 26373c719455
>>
>> And their dependent patches. See additional information.
>>
>> [ Test plan ]
>>
>> On APU/dGPU already supported by Ubuntu out-of-the-box:
>>
>> 1) Remove a GPU firmware from /lib/firmware.
>> 2) Reboot system
>> 3) Verify amdgpu shows probe error
>> 4) Verify that IP discovery info in sysfs
>> 5) Unload amdgpu
>> 6) Restore GPU firmware
>> 7) reload amdgpu
>> 8) Verify works
>>
>> On new APU/dGPU
>>
>> 1) Verify amdgpu shows probe error
>> 2) Verify that IP discovery info in sysfs
>>
>> [ Where problems could occur]
>>
>> This changes
>>
>> Bug in this likely leads to 1) handling of probe failure and 2) module unload/reload behavior and 3) internal implementation of sysfs files under ip_discovery.
>>
>> For 1), if a probe fails then the gpu drivers is already in the bad state. This at least leave more postmoterm information that we can revisit.
>>
>> For 2), use cases that need active unload/load the module when system is up and running may be impacted, which is likely rare.
>>
>> For 3), tools relying on those sysfs files may be impacted.
>>
>> [ Additional information ]
>>
>> [1] https://lore.kernel.org/amd-gfx/20260406212442.2321667-1-mario.limonciello@amd.com/
>> [2] https://lore.kernel.org/amd-gfx/20260616091444.25605-1-geoffrey.mcrae@amd.com/
>> [3] https://lore.kernel.org/amd-gfx/20260622161914.1648195-1-mario.limonciello@amd.com/
>>
>> The full patch list to support this on 7.0-based kernel:
>>
>> ```
>> drm/amdgpu: don't free standalone ip_discovery sysfs in sysfs_fini
>> drm/amdgpu: clean up discovery and preempt sysfs entries on shutdown
>> drm/amdgpu: Export ip_discovery sysfs on probe failure
>> drm/amdgpu: Fix discovery offset check under VF
>> drm/amdgpu: fix IP discovery v0 handling
>> drm/amdgpu: Add size guard before copy discovery binary
>> drm/amdgpu: use DISCOVERY_TMR_SIZE in ACPI TMR fallback
>> drm/amdgpu: Avoid NULL dereference in discovery topology coredump path v3
>> drm/amdgpu: fallback to default discovery offset/size in sriov guest
>> drm/amdgpu: New interface to get IP discovery binary v3
>> drm/amdgpu/discovery: use common function to check discovery table
>> drm/amdgpu/discovery: support new discovery binary header
>> drm/amdgpu: include ip discovery data in devcoredump
>> ```
>>
>> Feifei Xu (1):
>> drm/amdgpu: Add size guard before copy discovery binary
>>
>> Hawking Zhang (2):
>> drm/amdgpu: New interface to get IP discovery binary v3
>> drm/amdgpu: fallback to default discovery offset/size in sriov guest
>>
>> Jesse.Zhang (1):
>> drm/amdgpu: use DISCOVERY_TMR_SIZE in ACPI TMR fallback
>>
>> Lijo Lazar (1):
>> drm/amdgpu: Fix discovery offset check under VF
>>
>> Likun Gao (2):
>> drm/amdgpu/discovery: support new discovery binary header
>> drm/amdgpu/discovery: use common function to check discovery table
>>
>> Mario Limonciello (2):
>> drm/amdgpu: Export ip_discovery sysfs on probe failure
>> drm/amdgpu: don't free standalone ip_discovery sysfs in sysfs_fini
>>
>> Pierre-Eric Pelloux-Prayer (1):
>> drm/amdgpu: include ip discovery data in devcoredump
>>
>> Srinivasan Shanmugam (1):
>> drm/amdgpu: Avoid NULL dereference in discovery topology coredump path
>> v3
>>
>> filippor (1):
>> drm/amdgpu: fix IP discovery v0 handling
>>
>> geomcrae_amdeng (1):
>> drm/amdgpu: clean up discovery and preempt sysfs entries on shutdown
>>
>> .../gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 2 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 814 ++++++++++++------
>> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.h | 10 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +
>> .../gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 14 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
>> drivers/gpu/drm/amd/include/discovery.h | 13 +
>> 8 files changed, 618 insertions(+), 243 deletions(-)
>>
>
More information about the kernel-team
mailing list