The collected works of rturja

Taking boards off, cleaning contacts from both the board and backplane and putting them back might work wonders. Another angle of attack is checking the socketing of every chip which is not soldered on the board - pushing them firmly with thumb or like while the board is on level, antistatic surface. Wriststrap might be a good idea in that as well... The cleaning of contacts shouldn't be made using anything abrasive though.

That was how I made my Amiga 3k working again - even if the computer manufacturer differ, the older beasts seem to have pretty similar things happening due aging.

//edit
and yes, that means taking *everything* apart and doing the cleaning/checking, not just the supposed failing component. It takes some time and seems low brow, but might spare you similar operation with another board in near(ish) future...

-Reko

ramq wrote: And I still can't access the site! Pity, cause I was in a buying-mood all of the sudden. Argh.

Looks like they are for some reason blocking Sweden - or at least parts of it. Cannot access ebid at all from Bredbandsbolaget but from my server co-lo'd at Helsinki ebid opens using Lynx. Go figure

-Reko

After reading several threads about Fuel power supplies dying, I tried to dig some info about the supplies used. I'm in the process of slowly upgrading my Fuel and was wondering about the options. I've had some PSUs dead before due machines kitted out beyond the capabilities of the supply and following in the SGI Fuel specs page was somewhat interesting:

Combined 3.3-V, 5-V, and 12-V output is limited to 300 watts.
An additional 18 amps @ 12 V powers the onboard switching regulators.

So we have a power supply of nominally capable of pushing 430 watts, but the real oomph it can give out maxes out at 300. Bit like el cheapo ATX supplies which promise huge wattage, which peters out long before reaching the max cap. For me 300 watts sounds like pretty little, especially if the fuel is above the minimum: Processor upgrade, all hd bays in use, scsi, fc, sound, V12, 4G of memory... And the descriptions of dying fuel power supplies sound pretty much like any description of a supply dying a slow and painful death due overdrawing current.

Looking at the PSU replacement part names I found the following PDF from the defunct NMB supply department (this is/has been sold as replacement of Fuel PSU part No 060-0140-006 or 060-0140-007) Fuel 460W supply . What makes the pdf interesting is that the pinout is exactly the same as ATX v2.2 main power, ATX v2.2 main power pinout . I didn't find the original Fuel PSU pinouts though.

So definitely it looks viable to replace Fuel PSU with a regular modern ATX, but is it doable in practise? so far any discussions about the subject have stopped on the it must be special SGI supply to get it working level, and people who were trying a regular ATX stopped reporting of the progress at some point.

Any comments welcome

-Reko

Is this happening each boot or is this something that's just happening - meaning that your machine just did show up this screen?

Anyway it's local version of the BSOD and it tells you that there was a segment violation somewhere in the code you are running causing the kernel to crash and dump the contents of ram into HD for later post mortem analysis.

If this was one off or occurs just running certain software it's very likely a bug in the program itself - or drivers or... If it happens often and whenrunning different software, it might be an indication af a hardware problem.

Maybe someone who's more knowledgeable of the iron can give you even more exact causes by looking at the dump screen

-Reko

From FreeBSD dbus port (It seems to be tightly coupled with Xorg...):

Description:
D-BUS supplies both a system daemon (for events such as "new hardware device
added" or "printer queue changed") and a per-user-login-session daemon (for
general IPC needs among user applications). Also, the message bus is built on
top of a general one-to-one message passing framework, which can be used by
any two apps to communicate directly (without going through the message bus
daemon).

WWW: http://www.freedesktop.org/Software/dbus

It looks like dbus would need an X-server with appropriate bindings anyway, which I reckon the one running in vanilla Irix doesn't qualify I'd say it's safe to ditch it if there is a compiler option.