Status: On Hold / Active Investigation
Category: GPU Repair / Board-Level Diagnostics
Device: Gigabyte AORUS GTX 1080 Xtreme Gaming
Intake & Initial Inspection
Every repair starts the same way: before touching a multimeter, look.
The card showed no obvious signs of abuse or previous repair attempts. No missing components, no burnt areas, no cracked inductors, no damaged PCIe connector and no visible liquid damage.
A visual inspection revealed nothing suspicious.
Even more interestingly, the card appeared alive.
Upon power-up:
- RGB lighting initialized normally.
- Fans spun up as expected.
- No abnormal sounds were present.
- No immediate thermal hotspots were detected.
At first glance, the board looked perfectly functional.
Unfortunately, appearances can be deceiving.
The Test Rig
For initial diagnostics, the card was installed into a dedicated hardware test platform rather than a daily-use workstation.
The goal wasn’t performance testing. The purpose of the rig was simple:
- Verify PCIe detection.
- Observe power sequencing.
- Run low-level diagnostics.
- Avoid risking a production system with unknown hardware.
This allows potentially faulty hardware to be examined safely while providing direct access to measurement points and diagnostic tools.
The First Red Flag
The operating system booted normally.
The problem appeared when checking PCIe enumeration.
Linux detected only the integrated graphics adapter.
lspci
showed no NVIDIA device whatsoever.
Not as an unknown device.
Not as a VGA controller.
Not even as a generic PCIe endpoint.
The GPU simply did not exist from the perspective of the system.
The card was also tested in multiple PCIe slots and additional systems with identical results.
Power Rail Verification
The next step was confirming that the board was actually powering up.
Measurements confirmed:
| Rail | Status |
|---|---|
| 12V | OK |
| 5V | OK |
| 3.3V | OK |
| 1.8V | OK |
| PLL Supply | OK |
| Memory Voltage | OK |
| GPU Core Voltage | ~0.81V |
The presence of GPU core voltage was particularly important.
Many dead GPUs never reach this stage of initialization.
This card did.
PCIe Initialization Checks
When a graphics card fails to appear on the PCIe bus, several common causes immediately come to mind:
- Missing reset signal
- Missing reference clock
- Corrupted firmware
- PCIe communication failure
PERST#
PCIe reset was captured during power-up using an oscilloscope.
The signal transitioned correctly from LOW to HIGH and remained asserted throughout operation.
This confirmed that the motherboard was releasing the GPU from reset correctly.
REFCLK
Using both a 50MHz and later a 100MHz oscilloscope, PCIe reference clock activity was observed directly on the clock lines.
Although the equipment was not capable of fully resolving a 100MHz differential PCIe clock, the waveform appeared active, stable and consistent with a valid reference clock source.
At this point there was no indication that the GPU was missing REFCLK.
Firmware Investigation
Attention then shifted toward firmware.
The board contains two Winbond SPI flash devices connected through additional switching logic, suggesting a dual-BIOS implementation.
One flash device exhibited activity immediately after power-up.
Observed behaviour included:
- Clock bursts during startup.
- Multiple access attempts.
- Followed by periods of inactivity.
This strongly suggested that the GPU was actively attempting to read firmware.
The primary device was identified as:
Winbond W25Q40EW
A 1.8V SPI flash commonly used for GPU firmware storage.
Programmer Adventures
The firmware chip was removed for external analysis.
Initial flashing attempts produced confusing verification failures.
After further investigation, the cause turned out to be far less dramatic than expected.
The replacement firmware had been written directly without performing a proper erase cycle beforehand.
Once the correct sequence was used:
- Erase
- Blank Check
- Program
- Verify
the readback matched the source ROM perfectly.
Repeated binary comparisons confirmed consistent results across multiple reads.
The flash memory itself proved healthy.
Further boardview analysis revealed a more sophisticated firmware arrangement than initially expected, including two ROM devices connected through switching logic controlled by a Fairchild NC7SB3157 multiplexer.
At the time of writing, one ROM device has been fully verified while the secondary ROM remains scheduled for additional verification.
PCIe Lane Analysis
With firmware, reset and clock signals appearing healthy, attention shifted toward the PCIe data lanes themselves.
Resistance measurements across multiple TX and RX differential pairs showed consistent values across all tested lanes.
No obvious shorts, opens or abnormal resistance readings were found.
Oscilloscope measurements were then performed directly on the first PCIe transmit and receive lanes.
The results were inconclusive but concerning.
While occasional transient events could be captured during startup, neither TX nor RX lanes displayed the sustained high-frequency activity normally associated with successful PCIe link training.
Compared to the clearly visible REFCLK waveform, both TX and RX activity appeared suspiciously weak and in some cases nearly indistinguishable from noise.
This became one of the most significant observations of the entire investigation.
The GPU appeared to:
- Receive power correctly.
- Read firmware correctly.
- Generate core voltage.
- Receive PCIe reset.
- Receive PCIe reference clock.
- Produce heat during operation.
Yet the PCIe lanes themselves never showed convincing evidence of a successful link initialization sequence.
Current Situation
At the time of writing, the following facts have been confirmed:
Confirmed Working
- RGB initialization
- Fan startup sequence
- 12V rail
- 5V rail
- 3.3V rail
- 1.8V rail
- PLL supply
- Memory voltage
- GPU core voltage
- Firmware read access
- Firmware reprogramming
- PCIe reset signal
- PCIe reference clock
Confirmed Not Working
- PCIe enumeration
- PCIe link establishment
The card still fails to appear on the PCIe bus.
Not as an NVIDIA device.
Not as an unknown device.
Not at all.
Current Theory
At this stage, the most likely fault appears to exist somewhere inside the PCIe initialization process.
The exact cause remains unknown.
Possible explanations include:
- Internal GPU PCIe subsystem failure.
- PCIe PHY malfunction.
- Link training failure.
- Secondary firmware issue.
- Another initialization fault not yet identified.
No conclusive evidence currently points to any single component.
Project Status
Investigation paused.
At this point the easy failures have been eliminated.
Power rails are present.
Firmware appears functional.
Clock and reset signals behave normally.
The GPU powers up and becomes warm.
Yet the card remains invisible to the host system.
The project remains open and may be revisited in the future as additional diagnostic equipment, comparison hardware or new information becomes available.
As with many board-level repairs, reaching a dead end is often part of the process. Every eliminated possibility narrows the search area and brings the actual fault closer into view.
For now, the GTX 1080 Xtreme Gaming remains one of those projects that refuses to reveal its secret.