The collected works of miod - Page 2

jan-jaap wrote:
what, the ladies or the tiny little frogs? :lol: :lol:

Everybody knows the frogs are overrated. Snails are so much better tasting.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
bjornl wrote: So, is it possible to use the built in mouse/kbd connectors or should I go the CADDuo path?
I think I've read that the built in connectors are useless. Is there another way?

Define `useless'. The connectors are wired and functional. However you might need to tinker a bit to get IRIX to load the pckm driver and enable them.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
SunOS 4 will not perform DNS lookups by default. It was built at a time where Sun was pushing YP very hard, and it expects to get hostname resolution through the YP server. The YP server had a `-d' flag to allow it to perform DNS lookups for hostnames not found in the YP database.

Therefore the preferred way to setup a SunOS 4 system is to make it part of an YP network; in your case, simply setting up an YP server on the system, and making it an YP client of itself (i.e. running both ypserv -d and ypbind on the system) ought to do the trick.

If you want to avoid setting up an YP server, Sun had a procedure to enable DNS lookups in the resolver. I don't remember the details, but it involved recompiling (well, really relinking with a few different object files) the libc, which became a problem when some y2k patches caused conflicts with this procedure.

Also, note that /etc/nsswitch.conf is a Solaris thing, it has no effect on a SunOS 4 system.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
I asked Ian Mapleson to part of his last R8000 Indigo2, and he was kind enough to accept. :D Thanks a million, Ian!

Code: Select all

veronne 58# hinv -v
FPU: MIPS R8010 Floating Point Chip Revision: 0.1
CPU: MIPS R8000 Processor Chip Revision: 2.2
1 75 MHZ IP26 Processor
Main memory size: 640 Mbytes
Secondary unified instruction/data cache size: 2 Mbytes
Instruction cache size: 16 Kbytes
Data cache size: 16 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision D
Disk drive: unit 1 on SCSI controller 0 (unit 1)
Integral SCSI controller 1: Version WD33C93B, revision D
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: GU1-Extreme
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A2 revision 1.1.0
EISA bus: adapter 0
veronne 59# gfxinfo
Graphics board 0 is "GR2" graphics.
Managed (":0.0") 1280x1024
8 GEs, 2 REs, 24 bitplanes, 4 auxplanes, 4 cidplanes, Z-buffer
GR2 revision 6, VB2.0
HQ2.1 rev A, GE7 rev B,  RE3.1 rev A, VC1 rev B, MC rev D
unknown, assuming 19" monitor
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jan-jaap wrote: IIRC the R8000 is also very sensitive to ESD so take precautions.

Well, aren't R8000 sensitive to everything, given how prone they are to die? I am wondering whether it is a good idea to let an R8000 system powered on during a full moon :mrgreen:
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
Titox wrote: Pics, pics, pics, pics!!!

Coming as soon as there is a sunny enough day to get proper lighting.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
miod wrote:
Titox wrote: Pics, pics, pics, pics!!!

Coming as soon as there is a sunny enough day to get proper lighting.

And here they are.

Front:
Image

On the back, it's a Power model number indeed!
Image

Cover removed:
Image

``Criticle'' :mrgreen:
Image

The bottom of the processor board, with the warning paper removed:
Image

The top of the processor board, with the CPU and FPU engulfed in a large heatsink:
Image
...and with the heatsink removed, quite close to Jan-Jaap's picture earlier in this thread:
Image

And just for fun, here is what the heatsink looks like from within:
Image
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
PymbleSoftware wrote: I think the flying spaghetti monster has already been discussed here...

You might not believe in It, but that's no reason not to use capital letters, blasphemer!
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
Oskar45 wrote: Actually, while today "Intelligent Design" is considered a more modern movement, arguments against it can already be found in certain documents discovered in the Nag Hammadi library: this creation was not good, not in the least, and it was the result of a cosmic catastrophe, brought into being by an inferior and ignorant deity who erroneously imagined he was God Almighty [what a lovely paradox!]. Consult Mohammed Ali.

Now that make sense. I've always known the only deity worth worshipping was the Holy Pumpkin. The Flying Spaghetti Monster, despite holy^Wserious credentials, is no match for the Holy Pumpkin.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
ClassicHasClass wrote:
I picked up a low-end Indy (I mean low: original 100MHz R4K, 8-bit XL, 32MB RAM) from a fellow collector.

ClassicHasClass wrote:
I'm waiting for an R4600SC

Be careful, you might need a PROM update to be able to use an R4600SC in your Indy if its PROM is too old.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
geo wrote:
As mentioned by rwengerter before, this is the latest fastest MIPS that still have SysAD bus which is possible to plant on an O2?

It would fit an O2, but the Processor identification register returns a different value than the RM7000. You would need a new PROM to be able to use this processor.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
bluecode wrote:
I don't think 3A is supported yet.

Not yet. Working on it.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
dyverize wrote:
I acquired a Indigo r4k sometime ago that was giving the TOD clock error, which I managed to fix with by replacing the battery only to discover there was a prom password. I managed to successfully clear the password by removing and reseating the eeprom chip. As expected the mac address reverted to ff:ff...... and I am unsure if the mac address can be reset on a r4k indigo or how to set the clock from the command monitor. IRIX is not bootable yet but I am working on that.

Well, no, this is not to be expected on an R4k Indigo - they don't lose their Ethernet address when the TOD clock battery dies.

However, quoting from G. Lenerz' site ( http://www.sgistuff.net/hardware/systems/indigo.html ) :

Quote:
Bad eaddr

Signs of failure: The system complains about a bad ethernet address (ff:ff:ff:ff:ff:ff).

In general this means that the EEPROM that contains the hardware ethernet address is dead or contains invalid data. It is an 8 pin MiniDIP serial EEPROM (93C56) which is socketed on the backplane.

In many cases the reason is, that in the Indigo different CPU boards (IP20, then IP12) were used. The location of the adress is different between the two boards and is properly relocated when a system is upgraded from IP12 to IP20. When the IP12 is placed back in the system the MAC address is erased.

A possible solution is to place the IP12 in the system and reset the mac adress from the PROM monitor using the eaddr command - the IP20 doesn't allow that. After that the system can be used with the IP12 board or upgraded to IP20 which will relocate the address once again.


I'd wager your Indigo had been used for a while with a R3000 Indigo CPU board. And apparently, you won't be able to restore the proper Ethernet address until you can put an R3000 CPU board in it.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
smj wrote:
GL1zdA wrote:
PS. William Gibson on the shelf behind 8)

Please leave that self-proclaimed and proud Luddite out of this.


What's wrong with being a Luddite ? :mrgreen:

(I'm not a fan of Gibson either, though)

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jan-jaap wrote: Somewhere in the early GCC 3.x series it stopped working on R3K CPUs. I suspect someone used R4K instructions in the crtbegin/crtend assembly code.

Aren't the various crt* files provided by the operating system? gcc does not provide such files.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jan-jaap wrote:
miod wrote: Aren't the various crt* files provided by the operating system? gcc does not provide such files.

GCC on IRIX provides crtbegin.o and crtend.o to deal with constructor/destructor stuff.

Ah, right, the joys of the collect2-as-an-ld-wrapper platforms.

jan-jaap wrote: Edit: crtbegin/end are built from C code, but the mips specific code does contain two asm files. Or maybe the GCC code generator got borked, who knows.

Well, the two .S files seem mips1-compatible to me. What may be wrong, OTOH, are the stack adjustments. The mips default frame size in gcc-produced code has changed several times over gcc development, and since almost noone tests gcc on IRIX < 5 those days, it is very likely that a stack frame size change has been applied everywhere but in gcc/config/mips/crt[in].asm...
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
ClassicHasClass wrote: I've thought about getting an old RS/6000 workstation with 3.2.5 to relive the glory days, since I administered a passle of 3.2.5 machines in my previous career.

The glory days? Looks like you've never had to put an AIX 3 machine in an YP network... :evil:
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
mia wrote:
I had random crashes on my O2 with 5.1 during makeworld, I'll probably give this one a shot. I think it might have been a bug Miod was working on earlier this year. He's done so much for this port, I should have at least provided him with a trace. I'll test and do that.

You're the guy with an RM7000 O2, aren't you?

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
mia wrote:
miod wrote:
You're the guy with an RM7000 O2, aren't you?

Yes, is this a hardware bug?

Hah! I wish it was. (Hmm, come to think of it, and given how much hair I have lost due to hardware bugs, I might not wish that much :mrgreen: )

No, there are issues on RM7000 since a few releases, which I'm afraid I couldn't figure out the cause of. But this definitely smells like a (subtle) software problem. In the meantime, running 16KB page size kernels (adding an "option PAGE_SHIFT=14" line to GENERIC-IP32) appears to work fine.

I still hope to eventually realize what is wrong and fix the bug... but I've been quite blind to the issue so far.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
hbent wrote: Frames are definitely my problem at the moment. The cross-compiler generates them correctly:

Code: Select all

.frame  $fp,24,$31              # vars= 0, regs= 2/0, args= 16, gp= 0

but the native compiler is totally wacked:

Code: Select all

.frame  $fp,12698368,(null)             # vars= 24, regs= 269896524/0, args= 0, gp= 0

I was working on the assumption that it was a problem with the compiler I was using to build gcc, and have switched to a different one for the run I'm doing now. Is there something else I should look into?

This smells like variadic functions (in that case, fprintf), are not working correctly. Are you sure your native compiler is built as an o32 binary (I'm not 100% sure anymore, but I doubt I am wrong assuming IRIX 4 uses the o32 ABI). Furthermore, if you're on an R4000 system, are you sure the native compiler isn't trying to output 64 bit code behind your back, or isn't built to expect an n64 world? An n32 vs o32 problem seems more likely so far, though.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
dyverize wrote:
I also have several O2's which work on the non SOG monitors albeit a green tinted image. Is this normal behaviour or is something wrong?

This is normal behaviour for non-SOG monitors: they don't recognize and filter the sync signal, which causes the image to be greenish.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
commodorejohn wrote:
  • I don't seem to be getting a picture out of the video card (PV21X-GD high-resolution color board.) I'm using an LCD monitor (Samsung Syncmaster 193p Plus) that is supposed to support sync-on-green (and that definitely supports the resolution and refresh rate used) with a makeshift cable setup (RS/6000 3W3-to-BNC cable plus 3xBNC-to-VGA cable - I gather that the RS/6000 has red and blue switched around, but I accounted for that and anyway it should only affect the colors, not the ability to form a picture.) But I'm not getting anything - the monitor OSD is claiming "no signal," not even that it's out-of-range. Is there some trick to this that I'm missing?

You should at least see something during the self-tests. You might want to check that the graphics board is correctly fitted in its connector - it's not uncommon for VAXstation 4000 graphics board to move during transportation.

commodorejohn wrote:
  • More problematically, I can't get to the console over the serial port, either. I have the baud rate set correctly on my terminal, but I'm not seeing any output at all. Do the console functions only work over the MMJ RS-423 serial port and not the DB-25 RS-232 one?

The only suitable serial console port is the MMJ port - the DB-25 is a different port (there are four serial ports on the machine, two for keyboard and mouse, two for regular operation). While the keyboard and mouse can be either connected directly to the system or to an extender cable which itself connects to the 15-pin multiplexed connector, the console and so-called printer port connect to distinct ports.
You might also want to check the status of the S3 switch on the front panel, which selects between glass and serial console.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jpstewart wrote:
IIRC somebody, somewhere else in these forums mentioned that there's a timeout on the TOD clock error. Something like 2 or 2.5 hours.

That would be me, on an R4000 Indigo. Of course now that the battery has been changed, this doesn't matter anymore... and you need a lot of patience to wait for 2 hours to get a prom prompt, then 2 more hours for it to process your first boot command... I ended up soldering a new battery (and I plan to solder a CR2032 socket once the new battery dies)

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
thunderbird32 wrote:
Here is the output of the probe-scsi command if that helps:

It does! According to probe-scsi, your cd-rom drive is set to id #3, while the ``cdrom'' alias in the prom uses id #6. You might want to fix your cd-rom drive jumpers, but in the meantime
Code:
boot disk3:f -s

might work (or
Code:
boot disk0:f -s
if your prom is still one of those which swaps id #0 and #3).

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
SAQ wrote: RS/6000 7030 model 3CT. 70-some MHz Power2 processor, MCA expansion, memory installed in groups of 8 40-bit SIMMS.

Isn't the 3CT running at 62.5MHz only?
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jsloan wrote:
Yes, the 8mb vsimm is the real value there ... those are not so easy to find.

Yes, but 4MB VSIMM are enough if you stick to 1152x900, or do not mind 8bit color depth at 1280x1024 or larger resolutions. A 4MB VSIMM can still display 1600x1280 or 1920x1080, after all.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
smj wrote:
Factory spec'd sure, but for maximum pain entertainment I wonder if the "up to 33MHz" SM20 would function in an Aurora... Image

No, the SS20 can not lower its MBus speed below 40MHz, thus SM20 and SM30 can not run in them. The crappiest module you can run in an SS20 is the SM40.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
smj wrote:
I'm really curious about the 4 pin Molex connectors on the one board, wondering what that was for...

This looks like an unfinished attempt at putting an internal SCSI disk on the unused part of the mobo. But apparently no header was soldered to the internal SCSI connector area.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
ShadeOfBlue wrote:
diegel wrote:
Just one more question: assuming we have a R12000 processor. -param l1-cache-size=32 but what is the correct cache-line-size for this architecture?

32 bytes for the L1 cache and 128 bytes for the L2 cache, it's the same for R10k and R5k as well, IIRC :)

Things are a bit more complicated than this.
L1 line size differs between instruction cache (64 bytes) and data cache (32 bytes) on the R10k family. Also, the L2 line size varies between systems. R10k-based O2 systems use only 64 bytes, while all other systems (Indigo2, Origin, etc) use 128 bytes.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jjacocks wrote:
So, I picked up another old workstation, this time an HP 9000/375.

Lucky man!

jjacocks wrote:
1) I have the HIL-PS/2 adapter (HP calls is the "keyboard adapter module"), but it doesn't plug in to the HIL port on the machine. There is a descending piece of plastic on the right side of the 10P10C connector that blocks it. I know that this adapter was made for the 9000/700 PA-RISC workstations, will it work with the 375, if I remove that tab?

I don't know for sure, but I am not aware of anyone using this adapter module on 68k workstations. I would not expect it to work if I were you.

jjacocks wrote:
2) What kind of memory do these machines take? I find reference to a 32mb kit (of 2 16mb modules) via HP part number 98229E. The specs say that this machine will take 128mb. So, should I just try to track down 4 kits?

The CPU board should have 8 slots, with memory sticks set in pairs. It will accept any pair of 2MB, 4MB, 8MB or 16MB modules of the A-3004-xxx series.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jjacocks wrote:
So, based on your note, I guess that HIL on the 300 series is not the same as that on the 500 or 700 series, even though it has the same name?

It theoretically is, though. Regular HIL devices (keyboards, mice, button boxes, digitizers) work as well on 300 as on 700. But HIL converters (quadrature or PS/2) are another story.

jjacocks wrote:
Is there an alternate HIL-to-PS/2 adapter available?

I'm not aware of any.

jjacocks wrote:
I take it that the memory is proprietary to the 9000/300 series?

Yes, it is. (Nitpickers will tell you they work on 9000/4xx models but these are 300 compatible)

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
Estuans wrote:
ifconfig ec0 simply tells me that the connection is up, with the static settings that were entered into the Network Manager.
netstat -r looks right too, but I'm not managing to get anything out.

I'm not managing to get a link light at all on ANY switch, is there a PROM setting that will disable ec0 entirely?

Does your O2 has its PCI tray correctly installed? If it is missing or not properly connected, the system will not be able to read its Ethernet address. ifconfig should be able to print the Ethernet address, which should start with 08:00:69 on the O2.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
The radar guy wrote: About the privileges of the root user, I do have the credentials to access as the root user, and our maintenance technicians too, but they told me that, even in this way, there are some files and menus which stay locked out.

Does this application use its own set of login credentials? If so, it would not be surprising that some features are only made available to specific maintainence users. All you'll need is to figure out how their user database is stored, and then, as root, you should be able to alter it.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
bluecode wrote:
I'd like to see Miod (forum member and OpenBSD developer) port IRIX to the Lemote Fuloong. I imagine I would like AIX also but have no POWER gear.

Bwahahahaha! I'm not sure IRIX is endian-neutral... and then, the graphics performance would suck, bigtime. The Fuloong uses a SiS 315 craptastic GPU.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
Nuke wrote:
And more importantly, would it please Hamei?

You can't please Hamei, but it's fun to watch people trying.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
smj wrote:
Two other boards are the 98549 framebuffer (1024x768x?bpp)

The 98549 is a 1024x768x6 frame buffer.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
jan-jaap wrote:
computron wrote:
i have bought a crimson last week end

Red fever made another victim :mrgreen:

Better than avian flu! :lol:

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
hamei wrote:
miod wrote:
Better than avian flu! :lol:

If you're interested, we're having a half-off sale on chicken plus if you hurry, with every case of wings we'll toss in a complete river pig for another fifty cents !

Sounds like a real bargain to me!

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
hamei wrote:
That's what I always thought too but came across this (oddly enough, while reading people gushing about fuse, which seems to be a re-animator's version of the OS/2 IFS idea - all the file systems in OS/2 were userland, so maybe not so slow after all ?

I'm afraid you got the wrong impression from IFS - filesystems under OS/2 were kernel code, but dynamically linked so that new filesystems could be added without too much hassle. The same goes for the device drivers - they would look like regular dll but use different entry point and are allowed to use the DevHlp services.

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...
smj wrote:
mia wrote:
Wow, nice one smj. I like the HD spindle too.

Well, terrifying to think how long ago that was - I only bear a vague resemblance to the kid in the chair now. ;)

It is obvious, by the hair, that this person can't be you! :mrgreen:

_________________
:Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :A350:
among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...