Intel Arc A730M (LAPAC71H) — GPU disappeared from PCIe enumeration, unrecoverable

[oakosb]

Hello,

My LAPAC71H NUC X15 (purchased ~2023, BIOS ACADL357.0069.2025.0916.1436) has experienced a complete loss of the Intel Arc A730M dGPU. The card no longer enumerates anywhere — Device Manager, lspci, or /proc/iomem.

Timeline of failure:

• Days ago: Pre-downloaded Neverness to Everness. The launcher warned of incompatible GPU; I assumed driver issue and ignored it.
• At launch (April 29): noticed poor framerates in-game. PresentMon could not select the dGPU; Task Manager showed only the iGPU.
• Rebooted — dGPU briefly reappeared in Task Manager.
• Attempted to launch the game again — dGPU vanished and has not returned since.

Recovery steps already attempted:

• DDU + clean Intel driver reinstall
• CMOS/BIOS reset
• Deep power cycle (battery disconnected, 15 min drain)
• Clean Windows 11 reinstall
• Boot from Ubuntu Live ISO for low-level diagnostics

Diagnostic findings (Linux):

• GPU's PCI address is 03:00.0, vendor:device [8086:5691] (Arc A730M / DG2). This is from a previous working capture; the device is no longer present.
• The CPU PCIe root port hosting the GPU (likely 00:01.0) is completely absent from PCI enumeration — not present-but-empty, but suppressed at the firmware level (consistent with the ACPI PRMV flag being set after firmware fails to detect the device during POST).
• The ACPI PRES method on the PEG slot reads back VDID == 0xFFFFFFFF, confirming the GPU is not responding to PCI config-space reads.
• Other CPU PCIe controllers are fully functional (NVMe at 00:06.0 trains at Gen4 x4; Thunderbolt 4 at 00:07.0 operational), ruling out CPU-side PCIe failure.
• SMBIOS event log: empty. No AER errors. No pcieport errors in dmesg. The link never trained at last boot — distinct from "trained then crashed."
• Forced PCI rescan after kernel boot does not bring the device back.

Question: Is there any GSC firmware recovery path for an Arc A730M that has stopped responding on the PCIe bus? Or is this conclusively a hardware failure requiring board-level repair?

The system is out of warranty, but given recurring user reports of similar A730M failures with Arc Alchemist mobile parts [1, 2, 3, 4, 5], I would appreciate confirmation of root cause before pursuing repair vs. replacement.

Diagnostic logs (lspci, dmidecode, ACPI dumps) available on request.

[Jobert_Intel]

Hi oakosb,

Thank you for reaching out to the Intel Community Forum. To assist us in investigating the issue, please provide the following details:

• Can you provide current lspci output and Device Manager screenshots showing the missing Arc A730M GPU for our hardware failure analysis?

• Can you provide event viewer logs from your Windows OS?

• Can you provide screenshots of the launcher warning about GPU incompatibility?

• Have you tried flashing to an older BIOS version if available for your LAPAC71H model?

• Have you checked if your NUC X15 supports Intel's BIOS Recovery Tool and attempted to use it?

• Have you booted from FreeBSD or other BSD variants to test their different PCIe enumeration methods?

• Have you tested with older Linux kernels (like 5.15 LTS) versus newer kernel versions to rule out kernel-specific PCIe handling issues?

• Have you tried booting Windows 10 instead of Windows 11 to eliminate any OS-specific compatibility problems?

• Please help generate the SSU logs of your system. Kindly refer to the link below on how to generate the logs:

https://www.intel.com/content/www/us/en/support/articles/000057926/memory-and-storage.html

If you have any questions, please let us know. Thank you.

Best Regards,

Jobert Trillana

Intel Customer Support Technician

[oakosb]

Hi Jobert!

• Can you provide current lspci output and Device Manager screenshots showing the missing Arc A730M GPU for our hardware failure analysis?

Attached. Also dmesg, the only errors seem to be:

[ 0.844328] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.EC0.XHPP], AE_NOT_FOUND (20251212/psargs-332)

[ 0.844335] No Local Variables are initialized for Method [_TMP]

[ 0.844337] No Arguments are initialized for method [_TMP]

[ 0.844338] ACPI Error: Aborting method \_TZ.TZ00._TMP due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
[ 0.844438] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.EC0.XHPP], AE_NOT_FOUND (20251212/psargs-332)

[ 0.844442] No Local Variables are initialized for Method [_TMP]

[ 0.844443] No Arguments are initialized for method [_TMP]

[ 0.844445] ACPI Error: Aborting method \_TZ.TZ00._TMP due to previous error (AE_NOT_FOUND) (20251212/psparse-529)

Which I think might be temperature monitoring for the dGPU.

• Can you provide event viewer logs from your Windows OS?

Unfortunately, I have since done a clean install of Windows, so whatever there might have been is lost. I did see Kernel-PnP errors failing to wake 46A6, but that's Iris Xe, so I'm not sure how related that is. I did not see any WHEA or intel gfx/similar errors.

• Can you provide screenshots of the launcher warning about GPU incompatibility?

Attached.

• Have you tried flashing to an older BIOS version if available for your LAPAC71H model?

Not yet, I'll flash an older version and reply with my results to this comment.

• Have you checked if your NUC X15 supports Intel's BIOS Recovery Tool and attempted to use it?

I did flash a .cap file from ACADL357.0069.RECOVERY.zip on my device's downloads page, but that's the version I already had and I did flash it from the EFI, not recovery mode. I am not sure if there is a difference.

• Have you booted from FreeBSD or other BSD variants to test their different PCIe enumeration methods?
• Have you tested with older Linux kernels (like 5.15 LTS) versus newer kernel versions to rule out kernel-specific PCIe handling issues?
• Have you tried booting Windows 10 instead of Windows 11 to eliminate any OS-specific compatibility problems?

No, but I did since test pci enumeration from the EFI Shell, and I did not see the dGPU, so I do not believe that any OS would. Attached pci output from EFI Shell.

• Please help generate the SSU logs of your system. Kindly refer to the link below on how to generate the logs:

Attached.

[oakosb]

Intel's website appears to no longer host older bios versions for my laptop. I can find a 0068 bios on the SI's website I got this laptop from, but they do not host the recovery.cap and I am not sure if attempting to flash a standard older .cap file would be a good idea, so I have not attempted that yet.

I flashed 0069 in recovery mode (F4), but the device still appears to be missing even in EFI Shell.

Also forgot to attach dmesg to my previous post, so I attached it here.

[oakosb]

Any updates @Jobert_Intel ? My system is Ready for Intel® Arc ™  dedicated graphics

[n_scott_pearson]

I zipped up the files for final BIOS 69 (AC0069). The resulting ZIP file is too large to be posted here. You can find an downloadable copy of AC0069.ZIP in my Other Legacy Drivers share.

From my archive, I can provide files for BIOS releases 53, 55, and 58-69. Let me know which, if any, you would like to try.

Hope this helps,

...S

[oakos]

Thanks for zipping those up and offering the archive, Scott! I really appreciate the help.

Before I try flashing older versions, I'd love your opinion, given your background with the NUC and Laptop teams.

I recently did an F4 Recovery flash of 0069, but the Arc A730M is still completely missing from PCIe enumeration even in the bare-metal EFI shell (pci -b).
Since it's absent at the UEFI level, I'm leaning heavily toward a physical VRM failure or BGA fracture. In your experience with these Alder County boards, have you ever seen a firmware/ME lockup cause the dGPU to vanish entirely from the bus like this? I'm willing to try flashing back to version 53, but I'm hesitant to risk a rollback brick if this sounds like dead hardware to you.

[Jobert_Intel]

Hi oakosb,

Thank you for providing the requested information. I will now further investigate this and will get back to you once a resolution is available.

I appreciate your patience and understanding.

Best Regards,

Jobert T.

Intel Customer Support Technician