Well, I've been keeping the Octane/IP30 port alive for quite some time lately,
but the bitrot in the code is making the functionality get progressively worse.
As of 2.6.30, the following will _not_ work:
- SMP capabilities (hangs on boot)
- Impact framebuffer (Oopes the kernel)
- Probably any PCI device plugged into the optional card cage
Unfortunately, I do not have the knowledge or capabilities to fix these, let
alone the time needed to re-write some portions of the code to make these work
properly. And that's not including the work needed to actually get this code
into the mainline kernel.
So I'm looking for help from people that know the kernel a lot better than I,
and don't mind a little bit of a challenge on getting this machine to work
straight again. Maybe even help in some way to get it into an appropriate state
to submit for inclusion in the kernel.
I've put the minimum three patches needed to get this machine to boot online at
Here's what each one does:
This is a partial implementation of turning the IOC3 device in Octane (and also
in Origin-class systems) into a bus of sorts. IOC3 on Octane governs access to
the keyboard/mouse ports, ethernet controller, Real-time clock (a DS1687-5
chip), front panel LEDs, and probably the parallel port. It's not a
fully-documented device, and violates the PCI spec in very unique ways, which
requires special handling.
This is a reversal of a patch committed to upstream almost 2 years ago (possibly
longer), which broke IOC3 (when using the above metadriver) by making Linux
enforce adherence to the PCI specification (I think, anyways. It's been too
long). Without reversing this patch, none of the IOC3 sub-devices are accessible.
Original submission of it (with description) is here:
This is the base code for the Octane port. I've largely maintained it via
bandaid fixes, but even bandaids can't keep a ship from sinking forever. I
managed to figure out the IRQ stuff to move Octane to using
set_irq_and_chip_handler, which got it booting again, but this broke the Impact
video driver, which will oops the kernel on initialization. SMP code broke back
in 2.6.24 due to improper conversion to dyntick, and I've never been able to
figure out why, because my only SMP CPU module turned out to have died while in
So if anyone wants to help, take a look, and let me know if there are any
questions. I'll answer what I can.
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic