Adding support for SGI Altix back into Linux

Published: 16-Mar-2026 - Last Updated: 6-Oct-2026

Linux removed support for the Altix in 2019, although it had been broken since 4.0 in 2015. To make matters worse, Itanium was removed from Linux in 2021. However, in 2026 with modern LLM tools, adding back support for a rare supercomputer is possible by one person that is not a kernel developer. This is an overview of my project to add support for the SGI Altix back into Linux.

An alternate title for this could be "Using an LLM to support vintage computers", as I never would have been able to do this without extensive use of Claude Opus. The LLM did much of the heavy lifting. I just directed it. I think this project is a good example of using an LLM to keep an old computer alive after support for it had been broken for over 10 years.

Github Repo

https://github.com/nsafran1217/linux-sn2

The GPU enabled version is here:
https://github.com/nsafran1217/linux-sn2/tree/master-epic-sn2-gpu

Background

The SGI Altix is a ccNUMA SSI (Single System Image) supercomputer designed and manufactured by Silicon Graphics. The first version, the Altix 3000 was released in 2003 and was the first computer to support running Linux with more than 64 CPUs in a single system image. After releasing the "2nd generation" Itanium based Altix machines, the 450 and 4000, SGI moved to x86-64 processors for the Altix XE, Altix ICE, and Altix UV.

Read the Wikipedia page for more information or the higher intellect wiki page.

Altix (also called SN2 {scalable node 2}) was removed from the Linux kernel for v5.4 in 2019 in preparation for the removal of ia64. During this process, the infrastructure for supporting different machine types at runtime was removed.
This makes adding SN2 support back in more difficult than just reversing the patch. I suppose you could undo everything and re-add the machine vector infrastructure, but in my opinion, this option seemed too invasive and likely to cause bugs.

Since we don't re-add the machvec infrastructure, support for SN2 is decided at compile time, not at runtime. Meaning a kernel compiled for SN2 will not run on a generic ia64 machine, and vice versa.
This may change in the future...

Motivation

I don't know, it sounded fun/interesting. Altix had been abandoned since about v3.10, and was fully broken after v4.0. I originally stopped at Linux v4.19.325, but I really wanted to work on getting the radeon driver working on Altix. I convinced myself that I needed a modern Linux distro to do this, and some folks in the T2 community suggested adding SN2 support back would be easier than building T2 with an older kernel.

Preamble

I knew that I could not do this by myself. I am not a kernel dev, I am not proficient at git, and I would consider myself as a beginner at C/C++. All my C/C++ experience comes from embedded projects on Ardiuno or ESP32, so jumping to the Linux kernel would be a large leap.

However, it's 2026, and I have access to Claude.ai. I had used claude opus for a different C project a few weeks before starting this and was impressed with its output. I had tried to use ChatGPT and Copilot for help with getting radeon working about a year ago, but never really got anywhere with it. I couldn't give it enough context (at least with the free version).

The Process

So how will we do this? I figured we should start with v5.4 and see what it will take to add SN2 back as it was removed; basically just reversing the removal patch. This mostly worked after fixing a few small changes in the kernel API. But reversing the patch touched a ton of files unrelated to SN2. I used claude and did this for v5.4 and 5.5, but I knew this wasn't a good way, especially if my target is v7.0.

So I started a new project and chat in claude and sent this as the prompt:

We need to cleanly re-add support for SN2 to the linux kernel post 5.4. We need to do this without major changes to the existing ia64 code since during the removal a lot of major changes happened. Reversing these changes may bring back bugs or bad code especially as we try to bring SN2 back into newer kernels.

Attached is 5.4-clean.tar.xz. This is clean 5.4 tree with no changes. Use this to test the patches you generate. sn2-reverse.patch is the patch which removed sn2 and made major changes to the ia64 code. sn2-v5.4-split-patches-v3.tar.xz is a corrected patch set which cleanly adds sn2 back into v5.4. This should be your reference. We should change these as needed.

Read the two .md files in the project for more context: sn2-readdition-analysis.md and sn2-split-patches-README.md

Keep notes in a PLAN.md file during this process.

Remember that the goal is to touch non SN2 specific code and build files as little as possible. I do not want to re-implement the machvec infrastructure that was removed in 5.4. It was removed for a good reason.

If you need additional files, let me know. Lets go over your planned changes before executing on them.

And it generated a plan and generated the patches. And after a few build issues and one DMA issue on boot, it works. All without reimplementing machvec and touching all arch/ia64 files. This gave me the confidence to continue moving up in versions.

So I started working through the versions, 5.4 -> 5.5 -> 5.10 -> 5.15 -> 6.1 -> 6.2 -> 6.3 -> 6.4 -> 6.6,
and then jumped to 6.16 with the Linux v6.16-eipc2 patches.

After a 2 week break, I returned to the project and got SN2 support working on the master-epic branch of linuxia64.

I kept track of the patches in this repo: https://github.com/nsafran1217/sn2-kernel-tools/tree/main/diff.
Also contained in the repo is some build scripts, some notes on bisecting issues, and my kernel configs I used for test. Most of the individual version directories have a readme or a fixes.md outlining the changes from the previous version.
Not all of the patches have all of the fixes that were found during this process. For example, after v4.0, the serial console started behaving strangely. This was fixed with a small patch, but I did not confirm if all versions have the fix.

In general, my fork of linux has all the patches and should be used to generate patch files if needed.

I used a standardized prompt to start the forward porting process. I would provide a tar file of the clean tree, a tar file of the previous patched version, and the patch for the previous version.
Claude would then apply the patch to the clean version, fix any rejected hunks, and look at the file for any changes which would prevent it from building. Obviosuly it won't catch everything since it can't compile this, so I would send it any issues after, instructing it to keep track of the changes and provide individual patch files for the fixes. At the end, it would combine the patches and confirm is applies cleanly to the clean tree.

This process worked great. Some of the versions would be done in 30 minutes. I'm sure an experience kernel dev could have also finished these versions in 30 minutes, but for someone with my skill level they would have taken a long time.

Recurring issues

I had one difficult issue keep coming up during the process related to loading modules. This specific bug was introduced in v5.2, but I didn't catch it then because I didn't have any USB devices plugged in. After plugging in a keyboard and mouse to test modules, the issue happened almost every boot.
Initial chats with claude did not help find this issue, so I bisected the kernel until I found the commit which introduced the bug.
Once I had the commit and gave that to claude, it was able to determine a possible cause for the issue, and a fix. The cause is documented here.

After jumping to v6.16 from 6.6, the issue came back as the overrides we were using were no longer possible. Claude did recognize it would come back, though it recommended building modules into the kernel as a fix. After telling it to fix it, claude was able to implement a fix that is SN2 specific and hopefully continues to work for many more versions. Description here.

The real root cause is an unfinished implementation in arch/ia64/include/asm/tlbflush.h for flush_tlb_kernel_range, where they just flush all.

static inline void flush_tlb_kernel_range(unsigned long start,
                                          unsigned long end)
{
        flush_tlb_all();        /* XXX fix me */
}

24 years later, it was never fixed.
Update! It was finally fixed!
I was able to drop the hack in the 7.3-rc3 kernel release!

Also during the jump to v6.16, a major bug was introduced which prevented the kernel from loading any binaries. This turned out to be a fix that was already introduced in other architectures, but was missed in ia64 since it was removed from Linux. HP Integrity and Ski were unaffected, but SN2 did not get lucky. This patch has been applied to the linux-ia64 branch.

The sgiioc4 driver, which is IDE, was removed for the 5.15 patch since legacy IDE was removed in 5.14.
Claude was able to rewrite the driver for libata so we continue to support all the original Altix hardware.

Conclusion

At this point, I want to do some final cleanup and see if we can merge the changes into to linux-ia64 repo.

Next steps:
1. Get radeon PCI GPUs working on Altix - Done
2. Fix Grub2 on Altix - Done, issue submitted
3. Write a guide for installing T2 Linux - Done
4. Investigate minimal machvec so generic kernels work on Altix