The collected works of johnnym

This is the machine from my signature. Not sure if someone tried this yet. Took me a few years to get all equipment together (incl. the required CrayLink/XIO cables, which maybe was the hardest part of it). I've anonymized the barcodes as I don't want to disclose the original owners. Below you'll also find some pictures of it (although some hardware from the top GIGAchannel cabinet was (re)moved before getting the `hinv -vm` output). The front skins are more or less intact (if I don't touch them), the top GIGAchannel cabinet originally was a floor-stand version, hence it's missing the sides of the front skins.

hinv -vm

Thanks! I like to call it the Uber-Origin200. From the manual it looks like this configuration was even supported by Silicon Graphics.

From https://techpubs.jurassic.nl/manuals/hdwr/admin/Origin200_OG/sgi_html/ch01.html#id45823 :

[...]
The configurations of an Origin200 GIGAchannel server are as follows:
* Origin200 GIGAchannel CPU module (either a master or slave module) connected to a GIGAchannel expansion cabinet
* Origin200 GIGAchannel master and slave module each connected to their own GIGAchannel expansion cabinets (one GIGAchannel per module)
* Origin200 GIGAchannel in loopback mode (no GIGAchannel expansion cabinet)
[...]

I haven't done anything useful with it yet though. I wonder if OpenBSD will be able to use all expansion cabinets.

smj wrote: Maximum Origin 200, nice! You may have the largest number of intact O200 front doors anywhere.

Yeah, it's a real pity that the plastics on this machine are so delicate.

smj wrote: Any idea of the total current draw when all four units are up and running?

According to the PDU* it's hooked up to, it draws:

• 4.2 A at maximum
• about 3.7 A to 3.8 A when starting/running the firmware
• and between 3.8 A and 4.1 A when starting/running IRIX.

Voltage should be 230 V, so between ca. 850 W and 970 W (with all hardware from the `hinv` output). So not that much actually, compared to the size of the whole machine.

*) The PDU is a Cyclades AlterPath PM10i, not sure how exact its current sensor is. So maybe I'll meter it with another gauge to get a second opinion.

And thanks for the warm welcome to nekochan! Glad to be here finally!

Not sure what the manufacturer of the firmware in your Ultra 40 M2 is, but for BIOS setups from Award there is an option - named "Halt On" usually located under "Standard CMOS features" - where you can configure on which errors the machine should halt on startup. This can also be configured to not halt on any errors and might workaround your problem.

tux wrote: [...] NVRAM battery is dead and I have to set the NVRAM values at the ok prompt before booting if I want to have proper network connectivity. [...]

I've created an expect script which does the reprogramming automatically , which could allow to get along without exchanging the battery. You could give it a try. As I could only test it on a SPARCstation 20 so far, I'd be interested if it also runs on a SPARCstation 5 out of the box.

Hombre71 wrote: Hi Johnnym - main problem is that I can't access the bios setup in any way...no keyboard presses are registered. Cheers.

Sorry, I overlooked:

Hombre71 wrote: but the keystrokes don't produce any result.

Hombre71 wrote: [...]
I tried reseating all memory sticks, no change. I have replace the motherboard battery already. 1.5 is nearly the newest bios, newest one I could find these days. Anyway, the machine booted for a few times after applying it....

Have you already tried to go down with memory modules to the absolute minimum? I know that Athlon64s can do with a single memory module (single channel) but I'm unsure if Opterons can also do this. If you have two CPUs installed you could also try to remove the second one (although cumbersome and delicate for Socket F CPUs) and test all memory modules one at a time (if supported). If you have two CPUs and don't want to remove the second one you could test two modules at a time (if supported).

Or if you have another machine that supports DDR2 memory, you could install the modules there and test them with memtest86+ for a few complete runs to see if they have obvious defects.

Although possibly unrelated: in the past I had problems with Athlon64 X2 systems using DDR2-800/PC2-6400 modules - Windows XP crashed a few minutes after startup, Linux (Ubuntu) worked most of the time. Although these should be supported by the CPU, it only worked reliably if I installed additional DDR2-667/PC2-5300 modules to slow down the memory bus. So if you have DDR2-400/PC2-3200 modules around you could give it a try, maybe they work in your machine. In the end I found out that one of the DDR2-800/PC2-6400 modules was defective, but interestingly the additional modules seemed to have masked this.

Shiunbird wrote: What about what was remaining of OpenSolaris?
I know Oracle took it back, but I guess once it's out, it is out? Is there any fork?

There's still OpenSXCE both for x86 and SPARC (sun4u, sun4v).

Shiunbird wrote: Sun was a cool company...

Yes.

cesare wrote: [...]
Actually, when I say it's a 4 core/ 1Ghz, it's actually an 8 core 1.2Ghz but only 4 cores show up, which suggests to me that the machine uses firmware to enable/disable CPU features? (cores, clock rate etc). I'm also not sure if that was common when these machines were released, whether they 'unlocked' capabilities like this. Anyone know?

I actually don't know if Sun did similar things like IBM (capacity on demand) for the UltraSPARC T1 based systems - well at least not for my T1000 - but I know that one can disable components on specific Sun machines. I.e. on a Sun Enterprise 250 you can disable processors, memory, etc. (I believe via OBP) and also for the T2000 this can be done ( via SC and possibly also from OBP). But as your clock rate also seems limited I wonder if your machine maybe has another issue. Maybe you give it a try with the showcomponent command first, to see what's available on your machine.

cesare wrote: I've had a fair dig about and not found anything obvious. From SC I can see the hardware, and it also sees the 16 threads (so 4 cores)

But if the SC does only show 16 virtual CPUs when using showcomponent , how do you know you really have 32 virtual CPUs (8 cores)?

cesare wrote: , which at least means i've not messed up the virtualisation stuff and limited what the OS sees. Saying that, Solaris 11 doesn't play nicely with LDOM with this machine, and I had to back out the default version for an older install to make that work from the host OS.

OpenBSD should also be able to "host" LDOMs , you could give that a try and stay away from Solaris 11 as host OS.

jammaster wrote: Hello!
The workstation only post the low level bios (vga bios on black screen), but no srm or arc console ...
I have try to swap the 2 flash eeproms with working one but nothing.
Is there a jumper for NVRAM factory setting like the alphastation 255's jumperblock (JP1 and JP2)?
dead mobo?

You could try to use a firmware update disk. This could give you output to the serial console port. I have done this on an AXPpci33 to get it going - IIRC after a similar issue than what you describe - vga bios message on black screen. I needed to set the SROM select jumpers (from the AXPpci33 OEM manual page 40 (labelled 2-22)) to "Boot from fail-safe floppy loader", insert the firmware update disk and cycle power. Afterwards the machine gave me console output after an endless 48 seconds and allowed to update the firmware.

I assume the AlphaStation 500 could have a similar functionality and you could update the firmware to the original (no real change to your current config, albeit it might work again afterwards) or the latest firmware depending on what you desire.

EDIT:
The AlphaStation 500 manual also has SROM selection jumpers (see page 120 (labelled C-12)). I assume "Floppy loader" is the relevant configuration.

EDIT2:
It could be that I also had to remove the graphics card before using the fail-safe floppy loader to make sure console output goes to the serial console (also make sure that no keyboard is attached!). If it doesn't print anything with the graphics card installed you could retry without it.

Cheers
johnnym

jammaster wrote: thank a LOT

Just to be sure and to make this thread useful for others, too:

Did the proposed solution solve your original problem?

Nice one! Keep going. When will you show off your Indys and you Indigo²?

Dodoid wrote: Once I get the parts from Ian. The Indys have broken graphics cards (we think) and the Indigo2 has a hard drive but as far as I can tell the drive doesn't work.

It might also work to netboot the Indigo² from one of your working machines. I once netbooted my Octane with loader, kernel and FS served from my Octane 2. There is a guide available for diskless operation that describes things and I believe you need to have the ONC3/NFS disk but I don't remember for sure.

Raion-Fox wrote:

itsvince725 wrote: I put Windows 10 on a NetBurst machine tonight.

Masochist.

I'd rather use a PIII to a Netburst machine any day simply because the latter at least consumes power in accordance with it's performance.

I happen to have one here (a ProLiant DL380 G2 w/2x 1.4 GHz Pentium III-S) and I had to install Windows XP on it to be able to run a firmware upgrade via SCSI for an older Tandberg StorageLoader. It was the only "true" i386 machine with room for a SCSI controller available to me then (and still now).

Y888099 wrote: So, mr LittleCube/Hz is 2X mr OrangeBox/Hz

Impressive result! I didn't knew those PPC74xx have that much juice in them.
Sorry, no comparable results available. But I could do a openssl speed -elapsed on OpenBSD 6.1 tomorrow as a start.

Regarding Netburst, there were a few later systems with Netburst CPUs (Xeon 7000 and 7100 series) that had cool features, like memory mirroring and/or memory hot-plug. I think of the ProLiant DL580 G3 and G4 , later systems (like the G5) no longer supported memory hot-plug. Sadly the mechanics of those hot-plug memory modules (each of them takes four DDR2 DIMMs) are bugged: it's sometimes terribly hard to unlock them and how cool is hot-plug if you can't get the module in question out of the machine?

(Re)built current Debian 8 and Debian 9 Linux kernels for MIPS based Cobalt machines using my xw9400, two changed root environments and QEMU user mode emulation. Both work well with my first Qube 2 (not tested with RaQs yet, but I assume they will also work there).

japes wrote: I was wondering if anyone has a system, or is considering some kind of catalog or inventory for their hardware (or not so vintage, or other hobbies, or ...).

I had some thoughts about this - also because my inventory is slowly getting out of control and I should start with something similar to stay in control (most things are still in my head, but I start to forget specific inventory items). And I also recogized those useful stickers jan-jaap had applied to the sse/se combination package I purchased from him late last year. What a cool idea is that!

I develop a collection of scripts to remote control machines and other gear (like PDUs, lights, etc.) and there I already organize inventory items (directories) in a directory structure. Each item can contain further items or so-called controls (on, off, reset, nmi/xir, etc.). To organize things in different machine halls (or locations) or for different purposes you can group items in super-items like machine-room-1, machine-room-2 or dns-servers, gluster-peers, etc. by simply adding symlinks:



Hence I'm biased here a little bit, but still, a box full of spare parts could also be described as a directory containing other items. You can still group boxes inside of other boxes or lockers and even in different locations (cellar, attic, parent's home, etc.). Moving things around can be done with mv . Finding things could be done with find or grep depending on how you implement leaf items.



And now assume you could use fsn for managing it?

So why not use a directory structure like an inventory?

A little rough and primitive and additional tools (for e.g. generating unique item numbers, creating summary lists) would still be helpful. E.g. in the future you could also make use of barcode scanners and preconfigured stickers with unique item numbers. So whenever you put something in a box, you scan the box, then choose the add function (implementation needed) and then scan the new item's sticker to add it. Similar actions could be done on removal or movement of a specifc item. And one could also think of barcodes for the state of the item (dead, untested, working), i.e. if an item is tested OK, select the state function for the item and scan the "working" barcode. You might even be able to start specific actions by scanning a barcode for add, remove, state, etc.. The company where I made my apprenticeship long ago had a system similar than that (not only for inventory but also for managing production, final testing, service, etc.) running on (Open)VMS. I think they started with VAXen and later moved to Alpha, not sure if its still in use today, maybe on Itanium.

jan-jaap wrote: Achilles heel: you have to keep it up to date.

Same here, but I think you always need to keep an inventory up to date, regardless what tool you use, except maybe where you have an automatic warehouse which takes care of that and you simply insert or (re)move items (from) there. My father once had a small automatic shelf store (with only a few shelves though) where you could select each shelf by a button press and the machine rotated until the desired shelf was available for access. Not sure if this could be also controlled remotely. He used it for tools but sadly gave it away some time ago...

A HP 9000 Model 712/80 (w/maxed out RAM and additional VRAM module installed) thanks to FlasBurn .

Runs well with both OpenBSD 6.1 and Debian 9 unstable and is currently tested using openssl speed -elapsed . It gets a little hot around CPU, cache and crystal oscillator. I measured about 57 degrees Celsius on the heatsink during operation (case was just opened for a few seconds for the measurement).

OpenBSD (6.1) works diskless so far. I see a lot of "ie0: receive descriptors out of sync at [...]" and "ie0: TDR detected an open [...] clock(s) away" during kernel boot and from time to time though, but that didn't stop the show, only slows things down AFAICS:


Debian GNU/Linux (9 - unstable) also works diskless, but running apt is not recommended and can lock up the machine. apt is usable from a disk install though or when mounting and updating the FS from a more powerful PA-RISC machine (e.g. a c8000):

Y888099 wrote:

johnnym wrote: HP 9000 Model 712/80

I owned a 712*100Mhz/192MB of ram, it was good as X11 terminal, but with gentoo it took 15 weeks (24h/24) just to compile a minimal stage4

Sounds like a good burn-in test. If it doesn't went up in flames during 105 days of continuous operation, heat might not be a problem for the electronics of this machine (although the 712/100 has a different system board then my 712/80).

kramlq wrote:

johnnym wrote: A HP 9000 Model 712/80 (w/maxed out RAM and additional VRAM module installed) thanks to FlasBurn .

[/code]

Nice. I've got a 712/100 with 192Mb which is quite slow, but probably one of my favourite machines. They were never speed demons - even back in the days these were current, they were mainly used as glorified xterminals where I worked (i.e. an xterminal but with a floppy drive, which is why they were chosen over proper xterminals by the guys in testing).

Actually speed is not that an issue, as long as there are other options to compile or update software. And especially for Debian on HPPA it's easy to just use a later machine for this work (same for OpenBSD and NetBSD I guess). Nevertheless I was shocked how demanding apt is nowadays. Of course I made it extra hard by using a NFS root FS over a 10 Mbps NIC.

kramlq wrote: In terms of maxing it out, beyond RAM, its quite difficult out as the parts are rare. I've got probably the most useful GIO option: the 2nd VGA and Ethernet GIO Card with breakout cable, but you don't see them for sale much.

Is this a 100 Mbps NIC then?

kramlq wrote: The second (teleshare) slot is also impossible to find anything for, but pretty useless these days anyway. Even the floppy + matching bezel is very difficult to find outside of buying a complete system with one installed.

Fortunately for me FlasBurn had the original non-floppy bezel, which I like even more for a machine that should be used without disks.

kramlq wrote: There is also a nice matching external CDROM and HDD if you want to go for the full setup

Yeah, I've seen a few pictures of these external devices on the web. They look pretty cute. Sun had a similar idea for their lunchbox models. I got two SPARCclassics with matching CDROM and disk enclosures. Makes a nice tower.

Two blazingly fast 50 MHz MicroSPARCs, a high-speed CDROM and SCSI disk, all in one tower!
With the words of IBM - although they meant another machine - "[...] this system is a supersonic race car on the IT highway. [...]" (taken from http://www-03.ibm.com/systems/power/hardware/775/ ).

I wonder why SGI never thought about external enclosures for single CDROM and disk drives that match the design of the base machine (i.e. CDROM for Octane, etc.).

jan-jaap wrote:

johnnym wrote: So why not use a directory structure like an inventory?

This focuses very much on *where* a part is. As if things stay in the boxes they arrive in, in chronological order.

Not necessarily: you can move around things by simply mv ing the contents between boxes/directories (plus doing that in reality of course). I currently don't have an argument, where a tree like structure could be helpful in managing an inventory, but find using such quite manifest or natural.

jan-jaap wrote: I try to keep related parts together

Me too actually, as long as related parts fit in the same boxes or the available room close by - which is a problem in my computer room, I'm afraid.

jan-jaap wrote: It's really a matter of keeping it simple (the KISS principle). It has to be easy to edit or I won't bother and that would make it worthless. The little Excel sheet gets the job done, if I need a complicated system it's probably a sign of a bigger problem (like way to much crap I should really get rid of instead of cataloging it).

Using a table is indeed nice and simple, but the need for Excel or something heavy like Open/LibreOffice keeps me at distance. But I'm sure the flattened view of an inventory is advantageous for some operations (e.g. printing).

robespierre wrote:

johnnym wrote: I wonder why SGI never thought about external enclosures for single CDROM and disk drives that match the design of the base machine (i.e. CDROM for Octane, etc.).

They did: The Indy had the Challenge Vault S, the Indigo2 had the Challenge Vault M, and the O200 had the Origin Vault.

I actually knew of these, but I thought more about external enclosures of smaller scale, for one single drive, like the ones for the 712 series pictured in the following images:

kramlq wrote:

johnnym wrote: I wonder why SGI never thought about external enclosures for single CDROM and disk drives that match the design of the base machine (i.e. CDROM for Octane, etc.).

They do! They offered granite enclosures to match the granite keyboard and mouse of the Indy, Indigo2 etc. I've got the CDROM, Floppy and DDS3 drive versions, which stack nicely just like the Sun boxes. I posted a picture on here many years ago: viewtopic.php?f=5&t=17035&p=132888#p132888

For Octane, there is also an external DVD in dark grey, and presumably tape, floppy as well.

Ok, I didn't knew these external enclosures were sold by SGI. I've seen some of them on the web but thought they were of generic source, also because I didn't recognize that the ones in lighter grey/beige actually have a granite look.

But compared to the machines itself, the smaller external enclosures have a pretty generic look don't you think?

Maybe SGI's intention was to emphasize the design of their machines by surrounding it with generic looking peripherals (apart from the granite look).

Sorry, a little late to the party, but I only recently got my hands on a POWER5+ based machine (yes I know, no POWER6 like in the thread title but most of the thread is about POWER5 anyhow ) and thought I could add some info about support in newer Debian releases:

• Debian 8 (ppc userland with ppc64 kernel; tested with on disk installation and debootstrapped NFS root FS) and
• Debian Sid (9) (ppc64 userland and kernel; tested with debootstrapped NFS root FS)

...both work on my p5-520Q (9131-52A).

The disk installation of Debian 8 works similar to Shiunbird's guide on Youtube with the following changes:

Shiunbird wrote:

astouffer wrote: Just a quick note for anyone else with this hardware, Debian 7 ppc installs fine.

I run Debian on my Power5. It was a pain to get it booting however.
After months trying to sort things out, I found out that the installer was reading the wrong devalias from the OpenFirmware (or the OpenFirmware was sending it wrong to the installer). This at the time of configuring the boot loader. So what was happening instead was that I was installing to the disk with SCSI ID 5 (listed by the installer as my first SCSI disk), but the boot loader configurator would detect my first disk as being SCSI ID 8 and not configure itself correctly.

I only used a single disk in the machine during installation (just like astouffer) to avoid this issue.

Shiunbird wrote: Edit: another thing... I found out that the partitioning layout matters a lot. I had to create the prep partition, and have /boot separated as ext2. Then the rest could be ext4 or whatever.

I was digging out a lot and found at the time some document from IBM recommending to use ext2 for /boot.

As per your guide I first tried to create a partition for /boot with EXT2, but this always failed with strange hangs both in the installer and on the command line. I succeeded in creating an EXT2 formatted partition by using a Debian 7 installer CDROM. IIRC this could be used by the Debian 8 installer later on if you do not try to reformat it, but in the end I read somewhere on the web (sorry, I don't remember the URL) that yaboot should "now" support EXT4, too, so I reinstalled Debian 8 using only a single EXT4 formatted partition for both / and /boot. And this also worked fine and is bootable.

Still important - but no change to Shiunbird's howto video - when creating an initrd use the targeted approach instead of generic , as yaboot seems to have a file size limit for the intrd it loads or it does not reserve enough memory for both kernel and initrd:

...and the driver for the disk controller is a module, so not compiled into the Linux kernel and hence unavailable for use if it cannot be loaded from an initrd.

Shiunbird wrote: [...]
Imagine the following two files

/computers/intellistation/dev/1gb-samsumg-ram-serial_number
and
/computers/intellistation/dev/scsi/20gb-ibm-scsi-hd-serial_number

These two devices have different specifications, so you can track, for example, for the RAM:

Code: Select all

manufacturer=samsung
capacity=4GB
number_of_chips=8
chip_capacity=512MB
device_type=hard-drive

And for the HD:

Code: Select all

manufacturer=ibm
capacity=20GB
rotational_speed=10000rpm
bus_type=parallel-scsi
bus_speed=320
device_type=ram-module

I didn't thought about doing this for machines, too. That's a cool idea! Using hinv is nice and handy and always current without keeping it up to date manually, but it only works when the machine is running and if it's SGI based. You can of course store the output but it will look differently compared to output from machines with other firmware (e.g. IEEE 1275 compatible). So why not create the hardware directory yourself the same way for all machines?

I'm currently experimenting with bar codes on boxes and bags for container like things. My recently acquired scanner (a Symbol LS 4004i with RS-232 interface which I can recommend) also understands most bar codes (for serial numbers or similar) I've seen on spare parts (except 2D bar codes like QR, though it should work with PDF417 , but I haven't tested this yet), so I use these to identify an item in a container instead of applying another bar code myself. Items are "containers" itself, in the sense that they contain meta data (manufacturer, type, description, state, etc.) as leafs (simple text files) and sometimes also other items, e.g. think of those hot-plug memory modules of a HP ProLiant DL580 G3/G4 containing four DIMMS.

So currently the directory names are solely made of numbers and further info can only be found in the meta data in each directory, unless you understand the numbering schemes of some manufacturers. I'm not yet sure if this is the way to go, but I'll see how this works out in the next weeks.

vishnu wrote: ...

gijoe77 wrote: ...

mopar5150 wrote: ...

@vishnu , @gijoe77 , @mopar5150 :
Thanks guys! I believe I was just lucky to get all pieces together and intact.

vishnu wrote: Have you come up with any nice uses for it?

I was afraid, someone would ask. Actually it's currently waiting for the next start up . I have mainly played with my other machines since my last post to this thread. It would be interesting to know, how many external graphics modules can be used with this machine (like with bjornl's Onyx 200 ).

vishnu wrote: Uh, you're not really running OpenBSD on it though, are you?

Actually I don't remember if I ever started OpenBSD on the whole machine, I know that it works on my first O200 (a single node, which originally came with the GIGAchannel expansion cabinet that's now on the top of the machine this thread is about). On http://www.openbsd.org/sgi.html it reads that MP operation is only supported on single-node IP27 machines. So it might not work at all on a craylinked O200. But I should check. On the other hand it might run on the machine if its partitioned into two systems, although that's not that useful (first craylink two machines, then partition into two machines).

EDIT:
Last paragraph moved to new thread .

1. Does anyone have some experience with (hardware) partitioning an O200?
   
2. Can this be done from the firmware monitor or do you need IRIX for it?
   
3. And, also important, will each partition behave like a "real" machine for other OSes than IRIX or does this only work wih IRIX?

I found the following docs on the web:

• Partitioning The Silicon Graphics Origin 2000
• IRIX Admin - System Configuration and Operation ("Partitioning Your System" starting on page 125 (89 inside of the document) and following)

Well, these are actually meant for Origin 2000 machines, but maybe this will also work on an Origin 200 - at least I believe I've seen the mentioned setpart PROM monitor command on my craylinked machines. I'll give it a try this weekend if time allows.

jan-jaap wrote: So, if you pull this off, you'll probably end up with two O200 systems (modules) with a rather fast interconnect. I don't know how the interconnect is exposed (MPI?). An interesting experiment, but I'm not sure how useful it is. Then again, that's true for most things I do with my SGIs

According to OpenBSD's SGI platform page MP operation for IP27 is supported for single nodes only. So it might not be possible to use the whole machine with OpenBSD. But it could be possible to use OpenBSD on one partition of it. And maybe run IRIX on another partition at the same time. Could be a nice stunt. Yeah, usefulness is very limited here - it could be easier to just remove the CrayLink cable between the parts - but who cares?

Ok, as the docs don't tell much about the setpart PROM monitor command, I'll give some details about it on Origin 200s:

setpart options:


Listing all partitions on an unpartitioned Origin 200 shows all modules as part of a partition 0:


According to the docs, " A partition ID of 0 indicates an unpartitioned system. " ( IRIX Admin - System Configuration and Operation , page 130 (93)), though this ID can be used by setpart and I didn't saw a difference between module 1 in partition 0 (module 2 in partition 1) or module 1 in partition 1 (module 2 on partition 2). But using a partition ID of 0 might be an error, so I used IDs 1 and 2.

Partitioning can be started by using setpart or setpart -s :


After a reset of the machine the current partition comes up with the hardware of the other partition removed:

I didn't find a way to access the console of the second partition though, I tried both the serial ports and the MSC port of the second module to no avail.

When running IRIX 6.5.5 (as the manpage of mkpart in 6.5.30 only speaks of Origin 3000s, but actually gave similar results, I tried an older version of IRIX to see if it's different there) on the first partition and using mkpart it seems to detect that the machine is partitioned although it does not see the other partition:

The hardware is limited to the hardware available in module 1.

Unpartitioning the machine in the PROM monitor with setpart -c and trying to partition it under IRIX with mkpart does not really work:


So all in all, hardware partitioning might not work on an Origin 200, or at least not as expected. But maybe I'm doing something wrong. If somebody has some insight, please let me know.

The pictured CPU module is a 013-2511-001 which according to Ian's Origin parts list is a dual R12K 270 MHz module with 4 MiB of L2 cache.

Pictures please!

Irinikus wrote: [...]
All machines are spotless cosmetically speaking.
[...]
It was the Powermac G4 that first sparked my interest in Apple and it's the reason why I collect computers today!

Nice. Did you actually buy them new when they were current and took much care to preserve them? Or were you lucky to get the machines in pristine condition?

Mine were all bought used, starting a few years ago. I recently added a Power Macintosh G4 Yikes! board to the collection and was hoping to get it installed in one of my Sawtooth based "barebones", but the backplate can no longer be easily removed on the G4 (AGP) cases, so I'll either have to remove it the hard way or have to wait for a G4 (PCI) case or just "upgrade" my G3.

Raion-Fox wrote: Here's my newest project.

1994 Green Mitsubishi 3000GT (Jade Fox)

84k miles (branded not-actual-mileage due to a DMV transcription error, not my fault)

Automatic/FWD

Do you have all-wheel steering in it and will you paint it red later?