No, but there's no reason why it wouldn't work. The only arch support that's been dropped recently is i386 and a few obscure ARM CPUs.

A lot of these archs were never supported to begin with. I was running Gentoo on an SGI Octane from 2006-2008, and the IP30 wasn't fully supported, and only one of the O2s I was working with at the time were supported as well (was it a 5K and 15K that we had? I don't remember anymore). Also, I'm not sure that portage if Gentoo still builds on these systems. The MIPS team was pretty sparse back then.

"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such

"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such

that means -> i do not trust 2.6.29 at all

I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code._________________"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

"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such

that means -> i do not trust 2.6.29 at all

I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code.

I remember seeing something like that on the Gentoo Octane I had running in college. I've got two at my house now (not the same two I was working with in college) - one is running IRIX, the other has no OS (I think the SCSI controller might be shot. Need to make sure everything is tight now), and I might be willing to give a new netboot image a test run on it.

[snip]
"Scheduling while atomic" means bad things happened, it indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler, it happens when the scheduler get confused and therfore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one. For example using sleeps inside of a section protected by a spinlock. trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to beahve as such

that means -> i do not trust 2.6.29 at all

I remember this one. Ran into it myself when playing around w/ 2.6.29 once. Never figured it out, as at this point, the userland was partially active, so most of the debugging one could do within the kernel were useless in figuing out what happened. Considering Octane's main issue was figuring out how to handle IRQ's correctly, betcha it's a bug in that core code.

I remember seeing something like that on the Gentoo Octane I had running in college. I've got two at my house now (not the same two I was working with in college) - one is running IRIX, the other has no OS (I think the SCSI controller might be shot. Need to make sure everything is tight now), and I might be willing to give a new netboot image a test run on it.

I've got Octane booting again somewhat in 3.14. The IRQ handler has been patched up thanks to a patch sent to me a few years ago that I forgot about. Had to mix and match some code, but I can boot to a console using only the Odyssey driver. Keyboard works again, probably mouse too. No serial console, no RAD1, and no ImpactSR right now, as I haven't been able to fix those drivers yet. SCSI access is extremely slow, probably because I need to tune the IRQ handling some more. Almost got the RTC to play nice...but ARCS keeps resetting the clock back to 1970 every two reboots for some absurd reason. No SMP either...and I don't look forward to tackling that code. But since I have an understanding of HEART's IRQ management now, maybe...

Oh, and ethernet does work, but like SCSI, I expect it to be a bit sluggish...though I have not tried benchmarking it yet._________________"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