SGI Octane (IP30) Patch Available

[Kumba]

I am still working, as time permits, on integrating the Octane patches into mips-sources. In the meantime, I've made a unified patch available for 3.16.0 that will allow building of your own kernel for Octane. A config file is also available.

• Patch: http://dev.gentoo.org/~kumba/ip30/linux ... -ip30.diff
• Config: http://dev.gentoo.org/~kumba/ip30/config-ip30-3.16.0

The patch applies over top of either a vanilla kernel or a git checkout of the kernel source from linux-mips.org. Not everything works 100%. I also have a netboot initramfs I'll add later on (once I find where I stashed it). It's an old buildroot build, but should provide enough functionality for netbooting. I also have some semi-recent stages usable for installs that I'll add at a later date, too.

• Things that DON'T work:
  • SMP SUPPORT IS CURRENTLY BROKEN! I require help in getting CPU1 to 'tick' properly, as it hangs up in the generic MIPS SMP code.
  • R14000 ONLY: Do NOT use CONFIG_TRANSPARENT_HUGEPAGE on an Octane with an R14000 CPU. Otherwise, when the machine starts to boot into userland, it will trigger Instruction Bus Errors (IBEs), which require a complete powerdown of the machine for about 15 seconds to clear.
  • Do not use CONFIG_SLUB, otherwise, you'll get errors when booting regarding duplicate /sys/kernel/slab/* entries in sysfs.
  • Do not use OHCI-based USB 1.0 cards in Octane. They're probably still broke on this machine.
  • Soft power-off via the power button doesn't work at the moment. The poweroff code is there in the rtc-ds1685 driver, but I haven't tested reading interrupts from the power button and wiring that up into calling the poweroff function just yet. Should be triggered on IRQ41, in case anyone is curious.
  • RAD1 Audio compiles into the kernel and is detected, but audio does not play at the moment. Uncertain if it's a bug in the driver due to bitrot or if something is missing from userland.
• Things that might work, but have problems, or are unknown:
  • Serial support on the Octane uses a very basic UART driver that drives the 16550A chip on the IOC3 directly. It does not use interrupts, only a polling routine on a timer, which makes it slow and CPU- intensive. The baud rate is limited to no more than 38.4kbps on this driver. Patches for getting the Altix IOC3 serial driver to work (which uses DMA and supports faster baud rates) are welcome.
  • UHCI Cards are known to have issues, but should still have some functionality. This issue primarily manifests itself when using pl2303 USB->Serial adapters.
  • MENET boards appear to have the four ethernet ports detected, however the six serial ports didn't appear to get picked up by the IOC3 UART driver. The NIC part number is also not read correctly from the four Number-In-a-Cans. Additional testing would be appreciated and patches welcome.
  • >1 PCI Shoehorn. I have tested one PCI Shoehorn together with a PCI shoebox (the card cage), and it appears the Octane can support a maximum of three PCI Buses sanely. Addition of any PCI BRIDGE-based XIO boards beyond this could confuse the IRQ assignment routine. HEART only allocates 64 IRQs, and each BRIDGE chip consumes 8 IRQs right now, even if there is only one PCI device on such a board. To be fixed at a later date.
  • > 2GB of RAM may cause DMA problems, especially with PCI devices. Old bug from the early days of this machine. I've never looked into because I cannot locate the higher-density RAM modules for my Octane.
  • Other XIO-based devices, like various Impact addons, remain untested and are not guaranteed to work. This applies to various digital video conversion boards as well.
  • X.Org is totally untested. The X Impact driver is still around, but I don't think it's been used in a long time. Console works fine.
• Things that DO work:
  • Impact (MGRAS) console, please report any bugs.
  • VPro (Odyssey) console, but no X driver exists yet.
  • PCI Card Cages should work for many devices, except certain types like PCI-to-PCI bridges (USB hubs, USB flash card readers for example).
  • Same as above for XIO PCI Shoehorns (P/N 030-1275-005).
  • SCSI, RTC, base I/O PCI, IOC3 Ethernet, keyboard, and mouse. Please report any problems with these devices.

Please post any bugs/problems/solutions here for now until I get this patch integrated into mips-sources, at which point bugs will go to the bugzilla instead.

Happy booting!

[legacy]

I only have a SMP Octane2 workstation and it seems there is nothing working and too many things to be fixed with kernel v3.*, i have no time for this things, and no reason to use my time for this old things, what i really like is to play with USB in my octane2, and i have already reached this goal with hacks around kernel v2.6.17


to summarize: my Octane2 is able to attach an usb-disk to the PCI Card Cage, handing an EHCI USB chip in order to do read/write I/O at 20Mbyte/sec, unfortunately i have issues with 2Gbyte of ram, so i had to remove ram module to be under 1.5Gbyte, this way i have a working stable machine

[Kumba]

I only have a SMP Octane2 workstation and it seems there is nothing working and too many things to be fixed with kernel v3.*, i have no time for this things, and no reason to use my time for this old things, what i really like is to play with USB in my octane2, and i have already reached this goal with hacks around kernel v2.6.17

I should be getting an SMP R14000 module in soon, so I hope to tackle that again and get it fixed. I got hung up getting the second CPU to "tick" and properly send inter-processor interrupts (IPIs) to the primary CPU.

to summarize: my Octane2 is able to attach an usb-disk to the PCI Card Cage, handing an EHCI USB chip in order to do read/write I/O at 20Mbyte/sec, unfortunately i have issues with 2Gbyte of ram, so i had to remove ram module to be under 1.5Gbyte, this way i have a working stable machine

PCI-to-PCI bridges have always been a problem with the Octane, and I believe a SATA USB connection would qualify as one of those. Stan didn't have enough documentation on the BRIDGE ASIC to figure that out. Additionally, if you have >2GB of RAM, 32-bit DMA suffers because the code wasn't fully fleshed out, either. Luckily, I found documentation on the BRIDGE chip on an open FTP server a few days ago, so at some point, maybe I can figure out those bugs and try to get them fixed. It all depends on how much free time I get. I hope to get a 3.17 mips-sources out soon that functions on Octane again and I've started splitting the patches up so I can send them upstream for review and inclusion.

[legacy]

I should be getting an SMP R14000 module in soon

lucky you are, this module costs to me something like 400 euro, definitively too much for me!
i think that USA has lower price for these things, i live in Europe, prices are higher

if you have >2GB of RAM

i have problem with everything bigger than 1.5Gbyte, i had to reduce the ram from 2Gbyte (not working) to 1.5Gbyte

to summarize: my Octane2 is able to attach an usb-disk to the PCI Card Cage, handing an EHCI USB chip in order to do read/write I/O at 20Mbyte/sec,
I found documentation on the BRIDGE chip on an open FTP server a few days ago

could i see it ?

[Kumba]

lucky you are, this module costs to me something like 400 euro, definitively too much for me!
i think that USA has lower price for these things, i live in Europe, prices are higher

I actually bought it from a guy in the EU, so I paid about that price. Every time I saw one in the US on eBay, it was an auction and the price skyrocketed by the auction's end.

i have problem with everything bigger than 1.7Gbyte, i had to reduce the ram from 2Gbyte (not working) to 1.7Gbyte

Yup, that's the problem that's long been with the Octane. The actual bug is in the pdev_to_baddr() function in arch/mips/include/asm/mach-ip30/dma-coherence.h (after you apply the patch). I can't remember if 64-bit PCI devices were unaffected (PCI-X), but 32-bit PCI, which is most devices, are. Funny enough, the BaseIO devices, like the IOC3 or SCSI, are not affected by this, I believe. I have exactly 2GB of RAM in my system, and no ill effects so far. I am always on the lookout for the higher density RAM modules so I can go to 4GB or even max it at 8GB just to see what the effects are.

could i see it ?

I'm not going to directly link it here because I don't know what the legal ramifications are, but if you search Google, it'll turn up. It's got a 2009 date stamp, so it's been out there for quite some time. I am surprised myself that I never found it before then.

[legacy]

t's the problem that's long been with the Octane. The actual bug is in the pdev_to_baddr() function in arch/mips/include/asm/mach-ip30/dma-coherence.h (after you apply the patch)

could i also patch the 2.6.17 ? it's my currently FULL working kernel and i had to change my ram modules in order to make my octane to work, so, in case, which patch ?

[Kumba]

could i also patch the 2.6.17 ? it's my currently FULL working kernel and i had to change my ram modules in order to make my octane to work, so, in case, which patch ?

Do you have the source tree for this 2.6.17 kernel? If so, it's probably a slight change in the path, include/asm-mips/mach-ip30/dma-coherence.h or such. Just do a 'find' in the source tree looking for that file.

Arguably, if you have knowledge of working on a kernel, help would be appreciated in making the 3.16+ Octane code work better. I've got 3.17.1 running on my Octane, but I've been spending time splitting the patch apart, actually storing the bits in a personal git repo, and working on getting the IOC3 metadriver code to work on my Onyx2 (IP27). I can't send the IOC3 metadriver patch upstream for inclusion if it breaks IP27, despite that IP27 appears to already have problems in the latest kernel. And getting the metadriver into mainline for MIPS (it's only available for IA64 atm) is the first big step in getting Octane added.

I just got serial working on the IP27 again under the IOC3 metadriver, and have been hung up trying to talk to the RTC chip (an M48T35) on the Onyx2. It's also hidden behind the IOC3 generic ByteBus like Octane, but whereas Octane uses PIO access to an "addr port" and "data port", IP27 can ioremap() its RTC memory area and use MMIO to talk to the registers directly. And for some reason, under the metadriver, those MMIO accesses aren't working correctly any more.

[legacy]

Do you have the source tree for this 2.6.17 kernel? If so, it's probably a slight change in the path, include/asm-mips/mach-ip30/dma-coherence.h or such. Just do a 'find' in the source tree looking for that file.

yes i have, i hacked it a bit, but i have not understood exactly which patch i have to apply in order to fix my problem

do you mean adapting things your from http://dev.gentoo.org/~kumba/ip30/linux ... -ip30.diff ? if so i could try

sorry, i have no Onyx and i have no time now to support a new kernel for IP30, i have been working hard for Atheros9 (it's a SoC based on MIPS32), it may be i could get more free time for the near future, but first of all i'd like to finalize the work i did on 2.6.17 because i'd like to use it for real usages, which implies attaching USB disk and using 2Gbyte of ram

p.s.
have you seen my link to NSA forum ? have you seen how pretty is working with an USB disk unfortunately with a band limit of 20Mbyte/sec ? have you seen the ramrootfs ? it's funny job

[Kumba]

yes i have, i hacked it a bit, but i have not understood exactly which patch i have to apply in order to fix my problem

Your problem is not fixed in my 3.16 patch. I was stating that if you wanted to take a crack at it, you'll want to look at the dma-coherence.h file in the mach-ip30 folder of your 2.6.17 source. That is, I believe, the logic that needs correcting. I just don't know how to correct that logic.

do you mean adapting things your from http://dev.gentoo.org/~kumba/ip30/linux ... -ip30.diff ? if so i could try

I meant using this on a 3.16 source tree (or 3.17, it applies on top fairly well, though you might get rejections on ioc3-eth.c). There's no point in attempting to backport the 3.16 code to 2.6.17. That's almost 8 years of changes you'd be fighting with, and that's not a battle you want to take up.

sorry, i have no Onyx

I was referring to the stuff I am doing with my Onyx2. Though, Origin 200, Origin 2000, and Onyx2 systems are all in the same family, so anyone with those is free to take a crack at things.

and i have no time now to support a new kernel for IP30

This is what you'll want to do in time, however.

but first of all i'd like to finalize the work i did on 2.6.17 because i'd like to use it for real usages, which implies attaching USB disk and using 2Gbyte of ram

What kind of changes have you made? Depending on the subsystem, it might be easy, or really difficult, to port those changes to 3.x. I have no plans to support anything 2.6.x related any more. I'm hoping to get the code into a usable-enough shape so I can send things upstream, at least the IOC3 stuff and the core Octane system code (not the video/sound drivers), to reduce the code I have to maintain. I ain't going to be able to keep forward porting Octane again for another 10 years...it takes just one odd change in a kernel subsystem to kill an external patch pretty much.

p.s.
have you seen my link to NSA forum ? have you seen how pretty is working with an USB disk unfortunately with a band limit of 20Mbyte/sec ? have you seen the ramrootfs ? it's funny job :D

I have not -- I have no idea what the "NSA forum" is. Doesn't appear to be on Gentoo's forums.

[legacy]

this link of my first post

see this (click) thread, it's in italian, but i have added a lot of dmesg and logs

is showing a kernel log of my IP30 that i have posted on that forum, it's my 2.6.17 + hacks + a custom ramrootfs + XIO-PCI-USB with an USB disk attached for tests, as i told you it is FULL working except the problem i have with the 1.5Gb Gbyte of ram

I have no plans to support anything 2.6.x related any more.

as far as i know there is no working 2.6.x, the last one is the 2.6.17, everything else is broken and full of problems
e.g.

Code: Select all

2.6.17	 pretty stable, used in production, 2xR12K working, ram MUST be reduced to 1.5Gb Gb in order to use PCI-usb, also IOC-serial-kb must be removed
2.6.19	 not stable as 2.6.17, issue when executed on system with 2Gbyte of ram, PCI-cadge not working, issues with SMP, machine crashes
2.6.20.*  dead
2.6.25	 busted, stay away
2.6.26	 may be there is a patch, but IOC3 is hardly issued, SMP dead
2.6.29	 bugs in the scheduler, not booting on 2xR12K
…

so i want to finalize that kernel in order to enjoy my workstation instead of continuously test/hack/fix this & that, as i told you the 99% of my MIPS development activity has been switched to Athero9, which is modern, lighter, and cheaper (less than 200 euro for the whole hw), also it eats less than 10Watt


btw about IP30 i will investigate about dma-coherence and in case i will try to fix it

[Kumba]

this link of my first post

Oh, that link. I looked at it briefly a few days ago, but I have not seen the Octane's PROM crash like that after a soft-reboot. Basically, you got a data bus error, which I think on MIPS points to an address alignment issue. All addresses on MIPS have to be aligned. It also looks like you've got some significant changes to the kernel, especially at the boot-up phase. What's "BSP for IP30 SGI Octane2, with SMP"? What else have you changed? It could be something one of your changes did that doesn't agree with the rest of the kernel..something I've ran into myself on both Octane and O2 before, and are one of the harder issues to track down.

as far as i know there is no working 2.6.x, the last one is the 2.6.17, everything else is broken and full of problems

A lot of the problems changed when the ability to assign struct irq_chip members directly was taken away (you have to go through accessor functions now), and then further broken by the introduction of clockevent and dyntick/tickless idle, and then just plain bitrot.

so i want to finalize that kernel in order to enjoy my workstation instead of continuously test/hack/fix this & that, as i told you the 99% of my MIPS development activity has been switched to Athero9, which is modern, lighter, and cheaper (less than 200 euro for the whole hw), also it eats less than 10Watt

Understood, but remember, Linux on IP30 has always been advertised as experimental. If it's stability and production you want, then there's IRIX or even OpenBSD. I am hoping to change that with the 3.1x series by getting this machine to work right once again, and get its code sent upstream so that major subsystem changes won't leave the machine totally dead next time.

[legacy]

Oh, that link. I looked at it briefly a few days ago, but I have not seen the Octane's PROM crash like that after a soft-reboot.

in the italian thread i wrote that during the development i got a lot of "surprises" like the strange issue i have posted (caused by something miss aligned), the kernel and the userland are perfectly working from the boot to the shutdown without any issue in the current configuration.

the log shows that i have found a valid working PCI_USB board, perfectly working with an attached USB_DISK, although it works you can see the performance of 20Mbyte/sec instead of the expected 40Mbyte/sec (measured with the same PCI-board and the same USB-disc on a PC), there is something wrong with throughput.

note that the userland is a ramrootfs uclibc stage that i made by myself and there is not standard /sbin/init, as result if you manually kill the bash you get kernel panic, that is a wanted features because it forces machine reset without having to deal with ioctl and this ugly and boring things

What's "BSP for IP30 SGI Octane2, with SMP"? What else have you changed?

I have added a BSP, aka Board Support Package, which is a collection of low level functions that could be used in the kernel space or that could be used in a bareboard firmware you could write without linux in order to test/understand a specific hardware component. The last BSP has support to initialize both uart portsn and both the CPUs in the SMP module. It has been used for testing purposes.

In my case the BSP is like a collection of primitives, the 2.6.17 kernel is just invoking a few of them, especially the machine-reset and the machine-power-down, plus a toy function that toys with the 2 frontal leds. Everything-else is not currently really used by the kernel, while i opened a branch in where i have hardly hacked the PCI-usb stuff because it has a lot of issues, and also in that branch i have fixed a bit of things around.

The main problem is still the 1.5Gbyte limit, which is present in the original code and not solved in my branch: i have the same issues in both the tree, the original one and my branch, if i plug 1.7Gbyte or 2Gbyte the machine has strange reactions about the EHCI USB, something like panics, data corruption in the usb-data, etc, also i had to remove IOC-serial-kb because it caused a lot of issues

[legacy]

wandering who is using IP30 with gentoo, it seems to me we are only in two X_X

[Kumba]

wandering who is using IP30 with gentoo, it seems to me we are only in two X_X

When I get mips-sources updated, and spread the word some more (followed by rebuilding all the mips big-endian stages again, and tackling netboot), maybe more will use them. There's plenty of these machines floating around on eBay.

Currently failing miserably at SMP support. I have a dual R14K module now, and I can get the thing to boot into an initramfs, but init immediately exits w/ exitcode 0x0000000a or 0x0000000b. I am completely stumped as to what the cause is. Likely, I'm using spinlocks incorrectly (i.e., I'm not 100% positive that spin_lock_irqsave/spin_unlock_irqrestore should be used inside the struct irq_chip accessors or not), or there's a previously undiscovered hardware bug I am hitting. It is quite maddening...

[legacy]

personally i think that if there are no developers it means that machine has no interest at all!

we have to consider that it's a more than 10 years old machine at least, and it's still too expensive, too heavy (which also means expensive shipping), and it eats too much energy if compared to SoCs

i have googled a bit checking around for a few mail-lists and forums about Octane/2 and it seems no one has never used an Octane with gentoo in the last 8 years; i was not able to see any interest about such a machine, just a few guys

[Kumba]

personally i think that if there are no developers it means that machine has no interest at all!

we have to consider that it's a more than 10 years old machine at least, and it's still too expensive, too heavy (which also means expensive shipping), and it eats too much energy if compared to SoCs

i have googled a bit checking around for a few mail-lists and forums about Octane/2 and it seems no one has never used an Octane with gentoo in the last 8 years; i was not able to see any interest about such a machine, just a few guys

There are some users over on the OpenBSD side, since they support not just IP30, but also IP35 as well. And then you have a whole forum full of folks at Nekochan that still use IRIX on these machines. So I'd say there's definitely the potential for interest. I don't plan on getting this machine working again and then maintaining a patch for several years. My goal is to get it into a usable-enough state and send patches into the mainline kernel. I may just have to abandon SMP support for now to do that.

SoCs are nice, but there's a kind of....nostalgia with these old SGI machines. The same way some people have a fix for old cars and trucks, despite the newer models available today are vastly superior. I also know of people who have a love for old VAX machines, old AS/400's, old Apple II's, etc. There's even a guy's website that hooks you into a real PDP-8 that he runs in his living room. Age of hardware does not necessarily correlate with interest. The fact that I failed to maintain the patches properly and that Stan moved on to other things in his life is why there's not much interest on them with Linux. But I hope I can salvage that somewhat.

[Kumba]

For those interested, I finally got mips-sources-3.18.3 posted, with the Octane patches. Please let me know of any problems.

[legacy]

hi
any news ?

i am a follower

p.s.
my friend Octane's front plane went damaged, i have to replace it, and it's too expensive
i am working too far away from my Octane, at the moment

[Kumba]

hi
any news ?

i am a follower

p.s.
my friend Octane's front plane went damaged, i have to replace it, and it's too expensive
i am working too far away from my Octane, at the moment

Latest mips-sources has the needed kernel patch. Just pass USE="ip30" to get a source that should build for it.

I also have some recent stage builds available on the mirrors from 20150205 that are gcc-4.7.4-built. However, I recently found a patch that fixes PR61538, so I've rebuilt some of the stages for gcc-4.9.2 and am currently uploading those right now.

No word yet on installation medium. I'm kinda in a bind on that because there's no mips-uclibc big-endian stages anymore. Could do something from glibc, but that'll be a huge netboot. Might look at livecds again.

[legacy]

wandering if i can use my ramrootfs, it's pretty full of useful stuff and takes 40Mbyte of ram.

what about the kernel ?

[legacy]

any news ? is the SMP now working ?

[Kumba]

any news ? is the SMP now working ?

I've got working 4.x ebuilds, but I haven't had a lot of time to test them out and/or upload them yet. I've been confined to weekends only for playing with these machines now. No SMP, either.

[legacy]

any news? does SMP work now ? On 2xR12K ? On 2xR14K ?

is 3Com 3c996b supported ? if so, under which kernel module?

is Menet supported ? if so, with both 4 ethernet lan ports && 6 uart ports ?

[Kumba]

any news? does SMP work now ? On 2xR12K ? On 2xR14K ?

I've stated elsewhere that SMP works fine in 4.1 and up. I didn't get time to make 4.3.x ebuilds yet, though.

is 3Com 3c996b supported ? if so, under which kernel module?

No idea. If you have such a board, you'll have to try it out using a PCI card cage or XIO shoehorn. PCI is known to be a bit screwed up on IP30 due to BRIDGE DMA not being worked out fully, so YMMV.

is Menet supported ? if so, with both 4 ethernet lan ports && 6 uart ports ?

I have a MENET board that has its ethernet ports detected, but not the serial ports. I haven't worked out why yet, though.

[legacy]

can't you tarball your linux kernel sources and send me them in order to help me to test and develop ?
(under the promise I won't release to anybody without your authorization)

elsewhere you are alone