THE SHORT ANSWER
“Unknown header type 7f” means the tool read an unrecognized PCI configuration header layout. An all-ones header byte (0xff), masked with 0x7f, produces 7f. That can accompany an unreachable device. The message alone cannot tell you whether the cause is power, the link, reset, firmware, or hardware.
What does unknown header type 7f mean?
The PCI header layout field lives at offset 0x0e. The usual layouts are 00 for an endpoint, 01 for a PCI bridge and 02 for CardBus. The top bit has a separate multifunction meaning. pciutils: PCI header register and layout definitions.
lspci masks the byte with 0x7f before interpreting the layout. So 0xff & 0x7f = 0x7f. “7f” is hexadecimal; its decimal value is 127. This explains the number, but does not prove every occurrence came from an all-ones read. pciutils: how lspci reads and displays the header type.
If you also see rev ff, prog-if ff or several functions failing together, investigate whether configuration access has been lost. A device name still printed by the OS is not proof that the device is responding now.
Which checks should I run first?
Record when it starts: immediately at boot, after sleep, after a VM stops, after connecting a dock, or after programming an FPGA. Then identify the PCI address. These examples inspect status; they do not write PCI registers or reset devices.
uname -r
lspci -Dnn
lspci -t
# Replace this example address with your device address.
lspci -s 0000:01:00.0 -nnk
sudo lspci -s 0000:01:00.0 -vv
sudo journalctl -k -b --no-pager0000:01:00.0 is an example domain:bus:device.function address, often called a BDF. Save the device IDs and the nearby kernel messages. Look for link-down, AER, failed power transitions or reset errors before the header warning. On systems without a persistent journal, check the available kernel log instead.
Avoid full configuration-space dumps as a routine first step. Extra probing can disturb fragile hardware; stop if even normal inspection stalls.
How do I choose the right fix?
| Trigger or device | Next investigation |
|---|---|
| GPU missing after sleep or load | GPU access, driver and resume checks |
| VM works once, then fails to restart | Host state and passthrough reset lifecycle |
| External GPU or dock | Thunderbolt authorization and PCIe path |
| Wi-Fi or Ethernet disappears | Bus visibility before network settings |
| FPGA after a new bitstream | Configuration timing and endpoint baseline |
| esd CAN/402 behind a bridge | The vendor’s documented bridge erratum |
For a sleep-related failure, compare a fresh boot with the failed resume. PCI power management is relevant because access and recovery depend on device and platform state; a power-state clue is not a diagnosis by itself. Linux kernel: PCI power management.
What is a sensible recovery sequence?
- Preserve evidence. Record the exact device, trigger, kernel, driver and firmware versions before changing anything.
- Return to a baseline. Save work, stop affected workloads and use an orderly restart. If that does not recover the device, follow the computer or enclosure maker’s documented complete power-off procedure.
- Test one supported change. Compare a previously working distribution kernel, a vendor-supported driver, or a documented device-specific workaround. Keep a rollback route.
- Retest the actual trigger. A recovered device after boot is not evidence that suspend, VM restart or sustained operation is repaired.
PCI remove, rescan and reset are different operations. A rescan asks Linux to discover devices; it cannot guarantee a dead link or unpowered endpoint becomes usable. Removing a bridge can remove its children. Do not copy a reset command onto a storage controller or the NIC carrying your remote connection. Linux kernel: PCI sysfs, remove, rescan and reset interfaces.
Common questions
Does 7f mean my card is dead?
No. It does not establish permanent hardware failure. A reproducible failure across a supported baseline and the vendor’s hardware diagnostics is stronger evidence than this one message.
Will reinstalling a driver fix it?
Only if a driver-related cause is established. First determine whether the host can access the device. Network settings and guest drivers cannot repair a missing PCIe link.
Is this a Windows error too?
The literal message is associated with Linux PCI tooling and related software. A Windows dual-boot state can influence the next Linux boot, but Windows Device Manager error codes need their own diagnosis.
What should I send to support?
Send a concise good-versus-bad comparison: exact model and PCI IDs, physical path, versions, trigger, first relevant kernel errors and recovery behavior. Review logs for identifying information before sharing.
Sources and scope
This is a source-based diagnostic guide, published by Header7F. We have not reproduced every scenario or validated these steps across all devices. Vendor-specific advice is identified above; examples use placeholder PCI addresses. A suggested comparison is not a guaranteed fix.
- pciutils: how lspci reads and displays the header type
- pciutils: PCI header register and layout definitions
- Linux kernel: PCI power management
- Linux kernel: PCI sysfs, remove, rescan and reset interfaces
Published 18 October 2026. For corrections or a case this guide misses, send a short description.