The collected works of jan-jaap - Page 7

If that's an Indigo2 with a graphics option made up from multiple PCBs (so HighImpact, MaxImpact), you could try to pull the PCBs apart and reseat them. It looks like either bad frame buffer memory, or a bad connection between frame buffer and display generator (DAC).

TRAM is used only for textured graphics and a terminal window isn't, so I wouldn't suspect TRAM.

Oh, and run the diagnostics.

Nice classic

Since you ave a rev. "C" MC chip, you can. Otherwise it would start to complain when you install more than 256MB.

Yeah, I recognized the Nidec Beta fans. My 4D/380 VGX "predator" rack has the same

I still have an IP17 board and some RAM I could sell.

100MHz R4000. I only have the 2MB SIMMs left, but probably 32 sticks for a total of 64MB RAM

As mentioned in the quoted text, the SGI User Group independent from SGI (the company).

It is unlikely that SGI (the company) is going to make new MIPS/IRIX products. IRIX and some systems will be support until 2013 I believe.

There are plenty of SGI users out there still using IRIX, so it makes sense that the SGI UG talks about IRIX and Linux. Maybe even after 2013. Under the umbrella of the SGI UG, or right here on Nekochan

I've got 4 * 1TB in a (soft) RAID5 with LVM and XFS on my home server running Debian 'Lenny'. Works fine, but most I/O is reading and it is rarely hammered from multiple clients simultaneously.

RAID5 is economical when files are mostly read, but if a significant portion of your I/O is writing it's a bad idea. I don't think LVM causes a significant overhead. Any FS will slow down when you fill it up and XFS is no exception. But my old server (similar setup) was routinely > 95% full and it didn't become noticeable to me at least. XFS performs relatively well with large files like video. If you regularly delete large numbers of files, you will hate the XFS synchronous file delete which is slow. There are probably ways around that.

Transparent Indigo2 skins, probably from a prototype:



More prototypes: an Onyx rack , an Octane2 , a Power Indigo2 and Nekonoko's transparent O2 .

I still use that Fuel , btw.

TweakUI has options to fix this.

bump -- still looking (qty: 2)

In Europe, 3-phase is 380V.

I used to think Paris was bad. Then we went for holidays in Egypt and I saw the Traffic in Cairo

The problem in Germany is that cars that can do 200+ km/h are too affordable. It used to be only the big Mercedeses, BMWs and Porsches that would go that fast, and by the time you'd have gathered enough money to pay for one, you'd have matured a bit and drive it with some sense of responsibility. These days any pimple-head in a second hand VW Golf can do 200km/h but they don't realize yet that traffic is not a computer game...

Whenever you rub something against something else, you can build up a charge. Air is not 'empty', there's a lot of matter in it.

Static discharge is a slow killer. The damage it does may result in failure later on, and you may not realize what caused it.

I see that 'red fever' is nothing new

The DS1386 (used in the Indy) is out of production so you cannot request samples anymore. It's replacement , the DS1553 , is not pin compatible.

Several threads, but THIS is the most recent one. I you want to know where to open a DS1386 to attach a battery, look HERE .

Full backups and a UPS


Have you read Filesystem performance tweaking with XFS on Linux ?

Wrong.

When you have two RMs in an Onyx2, raster memory adds up (so you can have more features or larger bit depth), but texture memory is used in parallel to speed things up.

So any IR pipe with RM9s has 64MB texture RAM, regardless of the number of RMs. Any IR3 has 256MB, or four times what IR2E has.

I removed the "code" tags to make the bold work.

Old :

EXCEPTION: <vector=NORMAL>
Exception pc: 0xbfc108a0
Cause register: 0x30001008<CE=3,IP5,EXC=RMISS>
Status register: 0x80000<CM,IPL=8>
Bad Vaddress: 0xc0000000
Error Addr register: 0x17b40
Local I/O interrupt register: 0xff <>
Parity error register: 0x0
Registers (in hex):
arg: c98cf600 ffffffff 15180 0
tmp: 0 0 0 0 0 0 0 0
sve: a0017b93 bfc268c8 bfc268ca 1 54 0 1 800
t8 ff00 t9 502e8000 at 1 v0 c0000000 v1 f65da k1 bfc04234
gp 0 fp bfc04bd0 sp a0017b64 ra bfc10744
exit(-1) called

New:

EXCEPTION: <vector=NORMAL>
Exception pc: 0xbfc108a0
Cause register: 0x3000 5008 <CE=3,IP7,IP5,EXC=RMISS>
Status register: 0x80000<CM,IPL=8>
Bad Vaddress: 0xc0000000
Error Addr register: 0x17b40
Local I/O interrupt register: 0xff <>
Parity error register: 0x0
Registers (in hex):
arg: c98cf600 ffffffff 15180 0
tmp: 0 0 0 0 0 0 0 0
sve: a0017af7 bfc268c8 bfc268ca 1 54 0 1 0
t8 ff00 t9 502e8000 at 1 v0 c0000000 v1 f65da k1 bfc04234
gp 0 fp bfc04bd0 sp a0017ac8 ra bfc10744
exit(-1) called

You have to read the CAUSE register as a bitmask, and it seems that in the new situation bit# 0x00004000 (named IP7, this has nothing to do with a PowerSeries CPU board btw.) has been set where it wasn't before.

The PC where it crashes is the same, in other words it crashes at exactly the same code location. Locations 0xBFCxxxxx are ROM addresses (PROM code). In other words, it crashes during self test, but you knew that already

The exception handler has no way to recover from this error, so it reboots the system ("exit(-1) called"). Which results in an endless loop of course.

The fact that CE=3 is set is a little confusing, it claims that a coprocessor (#3) caused the crash but AFAIK there is no CP3 in this system (there's always a CP0, and CP1 is the math coprocessor).

The CAUSE register describes the state of the CPU when an exception happens. Bits 8:15 (IP bits) describe I nterrupts P ending when the exception happened. To make it more confusing, IP is subtly different from the rest of the CAUSE register fields; it doesn’t indicate what happened when the exception took place, but rather shows what is happening now. In your case INT5 and INT7 are pending. What went wrong is this: EXC=RMISS: the CPU tried to read from memory and failed. On memory exceptions, the BadVaddr Register contains the address whose reference led to the exception: 0xc0000000. This (virtual) address is the base address of the KSEG2 address space. This area is only accessible in kernel mode and it's translated through the MMU.

Why it would fail is a little harder to say. It could be any component in the memory subsystem:
* The main memory itself.
* The primary cache memory
* The secondary cache memory
* The MMU which translates between physical and virtual addresses.
* Some other part of main board logic (buffers, drivers, ...)

You've eliminated main memory I believe, does it crash before or after the cache memory diagnostics? Have you tried to boot it with no memory at all installed, and did that make any difference?

You could try to set the debug switches to halt in PON mode. This is an extremely crude monitor program, but it runs entirely inside the CPU + cache memory. If you get that far, you can have some confidence in the CPU and can run some cache diagnostics from inside PON I believe. Expand the "circle of trust" starting from something that works, rather than making a guess from a situation that doesn't work.

If you can eliminate CPU, L1 and L2 cache from the list, and it's not main RAM, then it must be a main board problem, probably a driver chip for the main RAM. There's a bunch of 74AS1004A chips (drivers) and 74AS623 chips (bus transceivers) around the SIMMs. Unfortunately they are not socketed.

If only those jumpers in the same area would be documented. I bet they can be used to configure/enable/disable banks of memory. Could be very helpful in your case.

Let me guess, gfx: can't reset GM textport In my system the CPU board works, and I can sometimes enable the graphics (sometimes it fails). It is good enough to get a graphics PROM console, but any attempt to boot into IRIX with the graphics installed in the system will cause bus errors, crashes, ... The GM board probably contains a memory buffer which is mapped into the address space of the CPU for communication between the two, and I have a feeling mine has some dodgy RAM chips...

Well, at least with the GM/GE boards pulled mine boots into IRIX. Slower than anything I've ever seen.

Right on the money

Last, multiple raster managers results in more raster memory, but also a higher fill rate because the raster managers are interleaved. So, theoretically multiple RM9/RM10s may have a higher fill rate than a single RM11, but whether that is true remains to be seen. Very little benchmark data of IR4 is public.

I've used a DELL 2407WFP (24", 1920x1200) panel on my Onyx2. Works nicely, but to get an acceptable picture quality at such high resolutions you need quality cabling and minimize the number of plugs and contacts in the signal path. So avoid 13W3-HD15 converts and PC VGA cables, but use a quality cable with a 13W3 plug on one end and a HD15 on the other end.

A DG5-2 has too little bandwidth to run two panels at 1920x1200 @ 60Hz. You can fiddle with the refresh rate to lower the bandwidth requirements but your panel and/or eyes may not appreciate the results. I believe a DG5-2 will do twice 1920x1200 @ 56Hz, but the 2407WFP didn't like it. I will probably get myself a pair of 1920x1080 panels some day, but have been too busy with other projects recently.

Ironically, a V12 with DCD will do twice 1920x1200@60Hz.

It's entirely possible that you need fill all slots on the first board before installing a second MC2. That's how the IP9 board works (which supports some RAM on the CPU card, an optional MC2 isn't used before all lots on the IP9 are full).

I could eventually verify this with the 4D/380 rack, but don't hold your breath. I've got other projects going on

Good to see it's working. Mouse OK too?

It never made much sense to me either. As I see it, two numalinked O300s are roughly the equivalent of an O3200. The O300's take up 4U of rackspace, the O3200 is a rack (OK, a short rack, but still).


CX bricks and InfinitePerformance were introduced well after the O3200 as well.

The density of O3k C bricks is low, presumably because a lot of space was reserved for the anticipated larger and more power hungry Itanium CPUs. You could say the O3200 was ready for an Itanium upgrade that never happened, whereas the O300 wasn't.


Digikey sells it, Farnell doesn't. You can order some samples straight from Maxim: http://www.maxim-ic.com/datasheet/index ... /2775/t/or
If you don't dare to solder it in yourself, surely you know someone who can do it for you?

What, you're looking for 2MB PowerSeries SIMMs? I have plenty.

FWIW, old SUNs used basically the same mouse . Maybe you have more luck finding a SUN3 mouse mat?

Hey! I have a VW Beetle One day I'm going upgrade it with a Porsche 911 engine. Better upgrade the suspension too

I tried to move a Crimson in it once. That didn't fit, or at least not without removing a front seat (like a Mexican taxi )

Rather than release IRIX source, I wish they'd release diagnostics and the schematics of the hardware. It would make repairs and troubleshooting much easier. In the long run, if we want to keep these systems running, we will have to repair failed components because you will not be able to replace them any longer.

Wow, a genuine museum piece. And in good condition too. Does it still work?

Welcome to Nekochan!

This looks encouraging!


I'd almost say the graphics board is set to a config which requires more frame buffer than the 32MB installed on a V10. Maybe the system used to have a V12 and the config is still stored somewhere other than the graphics board?

You say you can (sometimes) boot it into IRIX. Next time, try this from IRIX:

and reboot.