Intel has a new space grade system on chip called Starfire, and the first sign of it in Linux is exactly the kind of patch you would expect: a device ID added to the EDAC memory error subsystem, queued for 7.3. The part itself is a Panther Lake derivative built for orbit, with four Intel 18A performance cores, four low power cores, a three tile NPU and an Xe graphics tile made on Intel 3, all packaged with Foveros. Two configurations exist, at ten and thirty five watts, rated up to 45 and 75 TOPS, and specified from minus fifty five to one hundred twenty five degrees Celsius. Samples ship this quarter.
The short answer
Intel unveiled Starfire, a space grade SoC derived from Panther Lake and handled by Intel Government Technologies. It combines four Intel 18A performance cores, four low power cores and a three tile NPU on 18A with a four core Xe GPU built on Intel 3, in a Foveros package. Two configurations draw ten and thirty five watts for up to 45 and 75 TOPS, both with 12 PCIe Gen4 lanes and LPDDR5 or DDR5, rated from minus fifty five to one hundred twenty five degrees Celsius and for a ten year plus life. Radiation data is still in characterization. The first Linux patch, a device ID for the EDAC IGEN6 driver, is queued for kernel 7.3.
New silicon rarely arrives in the kernel with an announcement. It arrives as a hexadecimal number in a table, and somebody who reads commit logs notices. That is how Starfire turned up: a device ID queued into the EDAC subsystem's edac-for-next branch, targeting Linux 7.3, for a chip Intel intends to fly in orbit.
A laptop chip, hardened
Starfire is a space grade system on chip built for the United States government and handled by Intel Government Technologies. The layout is familiar to anyone who has read a Panther Lake block diagram. Four performance cores and four low power efficiency cores, a three tile NPU, and a four core Xe GPU with 64 execution units, assembled with Foveros packaging.
The process split is the interesting part. Compute and the NPU are on Intel 18A, the company's most advanced node and one it manufactures domestically. The graphics tile is on Intel 3, the older node. That is a deliberate chiplet decision rather than a compromise: put the parts that benefit from the leading node on the leading node, and build the rest where capacity is cheap and the process is mature. For a customer whose actual requirement is a domestic supply chain, being able to point at where each tile was made is close to the whole pitch.
Two configurations were published. The low power part draws ten watts, clocks performance cores at 1.0 GHz and efficiency cores at 850 MHz, with the GPU between 800 MHz and 1.0 GHz, and reaches 45 TOPS. The performance part draws thirty five watts, clocks performance cores to 3.1 GHz and efficiency cores to 2.1 GHz with a 2.0 GHz GPU, and reaches 75 TOPS. Both carry 12 PCIe Gen4 lanes, take LPDDR5 or DDR5, and are specified from minus fifty five to one hundred twenty five degrees Celsius with a rated life beyond ten years.
Seventy five TOPS is an unusual number to see attached to a spacecraft. The reason is that satellites increasingly want to decide what is worth transmitting before they transmit it. Downlink is the scarce resource, not sensor capacity, so running inference on the platform and sending conclusions instead of raw frames is the obvious win. An NPU in orbit is a bandwidth argument dressed as a compute argument.
Radiation data is still open
One line in the coverage deserves more attention than the TOPS figure: radiation data is still in characterization. The thermal envelope, the clocks and the lifetime rating are published; the tolerance numbers that actually decide whether a part can fly a mission are still being measured.
That is normal for a program shipping engineering samples in the third quarter of 2026, and it is also the reason to hold the comparisons loosely. Coverage frames Starfire against the RAD750, the radiation hardened processor that has been the default choice for spacecraft for roughly two decades, and on paper the performance gap is not close. On paper is doing a lot of work in that sentence until the characterization results land.
What upstream support will look like
The patch that started this is small on purpose. Starfire's memory architecture is close enough to Panther Lake that the existing IGEN6 driver already handles it, so a new device ID was all the EDAC subsystem needed to bind. Phoronix expects the follow ups to look the same: more IDs, riding on Panther Lake code paths that are already upstream and already tested by a much larger user base.
For anyone who maintains fleets rather than satellites, this is a useful reminder of how EDAC behaves. The driver binds by device ID. When the ID is missing, the driver does not load, and the result is not an error message but an absence: no correctable error counters, nothing under the EDAC sysfs tree, and no data behind whatever memory health alert you thought you had. On brand new platforms that gap can persist for a kernel cycle or two.
The check is cheap. Confirm that an EDAC driver actually bound on a new platform before you trust a dashboard that claims memory is healthy, because a machine that boots is not the same thing as a machine that is monitored.
Sources and further reading
- Phoronix: Linux 7.3 to begin laying the groundwork for Intel Starfire
- Tom's Hardware: Intel shows off Starfire space grade chip
- Igor's Lab: Intel Starfire, 18A SoC for space with 75 TOPS
- Hardware Busters: Starfire puts 18A silicon into orbit
- Kernel documentation: EDAC, error detection and correction
Frequently asked questions
What exactly landed in the kernel, and is Starfire supported now?
What landed is one device ID, queued into the EDAC subsystem's edac-for-next branch during the week of August second, 2026, which puts it on track for Linux 7.3. EDAC is the Error Detection And Correction layer, the code that reports correctable and uncorrectable memory errors, and IGEN6 is the driver that covers Intel's integrated memory controllers on client parts. Because Starfire's memory architecture closely follows Panther Lake, the existing IGEN6 code paths already do the work and only the new ID was needed to make the driver bind. So no, this is not full platform support. It is the first commit of what will very likely be a long trickle, and Phoronix expects the follow ups to look much the same, new IDs riding on existing Panther Lake paths.
Why does a space chip show up in the same drivers as a laptop chip?
Because it is the same design, hardened and re binned rather than redrawn. Starfire is described as Panther Lake derived, and it keeps the client silicon's building blocks: the integrated memory controller, the display and media blocks, the Xe graphics architecture. Reusing a shipping design is the entire economic argument for a part like this, since the alternative is a bespoke radiation tolerant processor that costs a fortune and lands years late with a fraction of the performance. The Linux consequence is pleasant. Drivers written for a mass market laptop chip mostly apply, which is why the first patch is a one line ID addition rather than a new subsystem.
What are the two Starfire configurations?
Both share the same layout of four Intel 18A performance cores, four low power efficiency cores, a three tile NPU also on 18A, and a four core Xe GPU with 64 execution units built on Intel 3. They differ in clocks and power. The ten watt part runs performance cores at 1.0 GHz, efficiency cores at 850 MHz and the GPU between 800 MHz and 1.0 GHz, for up to 45 TOPS. The thirty five watt part clocks performance cores to 3.1 GHz, efficiency cores to 2.1 GHz and the GPU to 2.0 GHz, for up to 75 TOPS. Both carry 12 PCIe Gen4 lanes, support LPDDR5 or DDR5, and are rated for a ten year plus service life across minus fifty five to one hundred twenty five degrees Celsius.
Is Starfire actually radiation qualified?
Not yet, and this is the part worth reading carefully. Coverage of the sell sheet notes that radiation data is still in characterization, which means the thermal and lifetime numbers are published while the tolerance figures that decide whether a part can fly are still being measured. That is a normal stage for a program at engineering sample maturity, and it is also why nobody should treat the TOPS figure as a done deal for a mission. Intel Government Technologies is running the program, samples are slated for the third quarter of 2026, and volume timing has not been stated.
Does any of this affect me if I run ordinary Intel servers?
Directly, no. Indirectly, it is a reminder of how EDAC IDs work and why they matter. If a platform's ID is missing from the IGEN6 table, the driver does not bind, and you silently get no memory error reporting at all: no correctable error counters, nothing in the EDAC sysfs tree, nothing to alert on. That failure is quiet by nature, which is what makes it dangerous on new hardware. The habit worth keeping is to check that the driver actually loaded on any freshly deployed platform, rather than assuming that a booting machine is a monitored machine.