[stuart]

I have a Fuel which I've left plugged-in, but haven't actually powered-on in an age.

I came back to it the other day, and found that pressing, holding, doing anything with the front-panel power-switch does... absolutely nothing :(

However, I previously invested in a converter board (the name of which currently escapes me) which allows me to use a standard ATX PSU with this hardware.  And it has an orange LED which is clearly lit!  It also has an override push-button which can be used to power-on the system - and if I hold this down then the fans all spin up and if I hold it down longer it sounds as if the firmware is beginning to bring the system up.  But as soon as I let go the power dies again.

   

I'm pretty rusty these days, but I'm digging around to find serial cables/converters to plug into the internal L1 connector and the rear serial port... but, in the meantime, is this a known problem?  Is there something I've missed?  Any suggestions for anything I can try?

(My understanding is that the common environment-monitoring issues Fuel systems have - which, so far, I'd not been affected by - lead to premature shutdown rather than a complete failure to start at all?)

[indigofan]

Have you tried using a serial cable to see what it's barking back when trying to boot up? I had what I thought was the environmental monitoring issue, but was really a fan that needed to be re-seeded. Once I reseeded the fan it powered up like a champ wanting to crunch some visualizations.

[Raion]

Welcome Stuart, I recall your Felicia Avatar from Nekochan.net. Welcome back to the fold.

Yeah, env monitoring usually doesn't cause a complete failure to start. I'd first check to make sure your power switch circuitry has continuity. If it does, go down the line. What if you jump it at the pin header?

Beyond that, sounds to me like capacitor failure somewhere if it's this bad. That's Kuba's board you're using, and it seems to be reliable for most people.

[Trippynet]

My honest advice with the Fuel is to hook the L1 up via serial and see what it is saying. Don't forget that Fuel uses 38400 baud rather than 19600 like the earlier SGIs. Once you can see what L1 is complaining about, things should be clearer.

Environmental monitoring may have failed, but usually the symptom when that happens is a Fuel that turns on for several seconds then powers down again, so this may be something else.

[stuart]

Welcome Stuart, I recall your Felicia Avatar from Nekochan.net. Welcome back to the fold.

Thank you!  It took me a little while to find Felicia again, but it wouldn't have felt right not to 😅

---

... and thanks all - I've been digging through my stuff to find a serial-cable or two (... and something to attach the other end to!).  I'm hoping to get something hooked up at some point tomorrow, so I'll try to report back on what I find soon.

[stuart]

My honest advice with the Fuel is to hook the L1 up via serial and see what it is saying. Don't forget that Fuel uses 38400 baud rather than 19600 like the earlier SGIs. Once you can see what L1 is complaining about, things should be clearer.

Environmental monitoring may have failed, but usually the symptom when that happens is a Fuel that turns on for several seconds then powers down again, so this may be something else.

I've eventually had time to try this - holding down the power button on the Kuba board causes an additional on-board LED to light green, the disks to spin-up, and other hardware add-in boards to initialise.  The lightbar lights white, but there's no video output and the lightbar never changes to red (which IIRC is usual during the system bring-up process).

I connected an FT232 cable with lights embedded in the DB9 shroud, but saw no output via /dev/ttyUSB0 on a connected Linux laptop - although strangely, the lights on the connector never lit either.

Falling back to my Octane, a serial cable from /dev/ttyd1 to Serial #1 on the Fuel also showed nothing at all.  Connecting to the L1 connector on the mainboard outputs ~5 carriage-returns when power is applied to the system, but otherwise also appears silent.

I've been using `minicom`which also always shows 'Offline' in it's status bar - is there a better way to see serial activity at as raw a level as possible?

Update:

After using the GNU `stty` command to set the serial baud-rate (... which minicom claimed to have done...) and then 'screen' to connect input and output, I have a connection!

Code:

SGI SN1 L1 Controller
Firmware Image B: Rev. 1.24.11, Built 10/29/2003 00:05:26

001a01-L1>

(... post-midnight firmware builds 😯)

The `cpu` command shows CPU A as present and enabled, although `date` is showing a date in 2019 - so, on the assumption that the system clock _was_ right at some point in the past, it appears not to have tracked time - I'm not sure whether this is diagnostically significant?

I note for Googlers from the future: The documentation at https://techpubs.jurassic.nl/manuals/lin.../ch03.html specifies a different date format to the Fuel's L1, which uses a date string of `MMDDhhmm[[CC]YY][.ss]`.

Does `debug` value 4 (verbose) or values 2-3 (more testing) apply to the Fuel?

`env check` outputs `Environmental monitoring is enabled and running.` although `env` itself shows all sensors as `Wait Pwr`, which makes sense... except for `BEDROCK` which shows as `Not currently available`?

`leds` outputs:

Code:

CPU  A: 0xff:    Console poll found data for reading

`log` seems to contain only repeats of:

Code:

<date> <time> L1 booting 1.24.11
<date> <time> PSC: 0x07
<date> <time> USB0: waiting on open

... with occasional entries reading `SMP-R: UART:UART_FRAMING_ERROR` or `SMP-R: UART:UART_BREAK_RECEIVED` - although I suspect that these were from my prior attempts to access the L1 controller (which suggests that data was reaching the L1, just not coming back to my console!)

`power` shows all items in state `off` or NC`, although `Fuel CPU` has a `Value` of 132...

The first thing which looks potentially like any form of error - `serial` returns:

Code:

BSN: NCJ502.   SSN: 08:00:69:xx:yy:zz.    Time: 02/08/2021 18:57:23 UTC
Public Key data in EEPROM is invalid

... and the `serial all` `EEPROM` section reads `NA` for `Serial`, `Part Number`, and `Rev` of `MAC`.

After issuing a `power up` command the system has booted to ARCS via the V12, but has stopped complaining `dksc(0,1,8)/sash:  no such device` - which it the next thing I need to look at.

L1 `logs` now shows:

Code:

02/08/21 19:03:11 power up (COMMAND)
02/08/21 19:03:17 reset again MIPS

The `env` output looks good (and `BEDROCK` has appeared).
`leds` now shows:

Code:

CPU  A: 0x55 unknown LED status.

(I assumed this would be the lightbar state on the Fuel?)

`power` _still_ shows 132 for `Fuel CPU` and `NC` for: `12V IO`, `5V`, `3.3V` (with a `Value` of 0), `1.5V` (with a `Value` of 0), `5V aux`, `3.3V aux`, `PIMM0 12V bias`, `Fuel SRAM` (with a `Value` of 0), `PIMM0 1.5V` (with a `Value` of 0), `PIMM0 3.3V aux`, `PIMM0 5V aux`, `XIO 12V bias`, `XIO 5V`, and `XIO 3,3V aux`.

(`power` outputs reading `on` are `12V`, `2.5V`, and `XIO 2.5V` - but all also have a `Value` of 0)

Could someone with a working Fuel please confirm what values `power` outputs on their system?

Overall, if anyone has any thoughts on why the system might power-on from L1 but not from the front-panel button, then I'm all ears!  Although I've not tried to power-on the system in a fairly long time (many months if not several years!) it hasn't been physically moved since it last worked, so it's unlikely that the issue is that the power-button is physically disconnected (and the light-bar does work)...

---

Further to these issues - from ARCS, `hinv`/`arcshinv` does shows the hard drive (and CDROM) as being present.

`ls` outputs:

Code:

dksc(0,1,8)/:
sgilabel  sash
No file system found for "/"

... although booting manually to `sash` and issuing an `ls` command shows the contents of `disc(0,1,8)` and `dksc(0,1,0)` without error.

Booting the system from here results in a warning of:

Code:

WARNING: rtdoc: preposterous time in tod chip: 14:26:55 2051/25/23
CHECK AND RESET THE DATE![color=#111111][size=small][font=Tahoma, Verdana, Arial, sans-serif]

... but otherwise IRIX does boot.

Shutting-down (which only returned me to `sash`) and then `boot`ing again didn't show the same warning.

Argh - but I've changed something and now choosing 'Boot' from the ARCS menu only takes me to `sash` :(

On the positive side of things, though, the Fuel does now seem happy to start from its front-panel button - and a power-cycle seems to boot to IRIX again, rather than stopping at `sash`!

[jwhat]

Hi Stuart,

great to see your Felicia back.

I had lots of problems with getting access to L1 serial comms with "new" Fuel I got last year.

Here is thread of my testing and updates.

I ended up:

1. Updated L1 Software (requires bootable machine :-( )
2. Going into POD/CAC mode to do reset of logs
3. Changing various IRIX serial port configuration items.

See here for full history of stuff I did: https://forums.irixnet.org/thread-2477.html

Having done this I have now got reliable serial access to internal diagnostic port (38400,8,N1), serial 1 port on back (9600,8,N1) and USB L1 port.

As I had so many problems getting access to serial comms, I used the L1 USB port via L2 (linux emulator). The USB access was always available and reliable irrespective of all the serial comms issues I had.

Suggest you post full L1 boot diagnostic to help with looking into problem further.

NOTE: Preposterous date is sign of flat battery on Snaphat timer chip...

Cheers from Oz,


jwhat/John

[weblacky]

Wow that's a lot of stuff.

First off ENV disease works both ways. It would shutdown your system because of incorrect voltage readings, it would prevent you from booting the system due to incorrect voltage readings. So incorrect voltages are the symptom (also wild temp readings that make no sense) or 0v and 0 fan rpm readings. I don't see enough evidence in your post to know that's' what's going on. If you can post a full formated env output, we'd likely be able to tell.

The order I'd go is:

1. Multimeter probe the plugged-in PSU ports on the mainboard for DC voltage values during this power state. Those zeros could be real, or they could indicate a short, or they could be a misread. Try to find out if they aren't at least real.

2. New PSU, a zombie PC can be a symptom of a bad PSU...either from bad power taking way too long to stabilize on boot (must often be around ~300ms on modern PCs, I've seen 800ms power good signal zombie a PC board where the fans run, drives spin up, power LEDs are on, but no POST. After new PSU that system worked fine). Now a fuel isn't a normal PC...but it's power supply is sort of a normal PC PSU and has the same sort of Power good signal and on signals.

While I hate being a "parts charger" for troubleshooting. I'm smelling bad PSU on this one, yes you may have other issues. But if you had a DEAD RTC and a DEAD snaphat...they'd be automatically filled with default values are boot, you'd have the wrong times...but (assuming you installed OS with default values and SCSI ID) you'd still boot! that's the great thing about dead RTC batteries, they blank the RTC chip every time you pull power, so the boot process fills them as if they are empty. Now you may be missing your serial number too (check L1 serial command) but a blank RTC chip should be auto-filled (on fuel t's auto right?) with it's serial, but maybe not. So check for that.

But otherwise, you'd boot with wrong date and default NVRAM values. That fact that have other weird stuff...power related (my gut feeling).

Which PSU did you buy? I didn't see it mentioned, just to make sure you bought one that has the capacity to run the Fuel's odd low-voltage (high current) rail demands.

[stuart]

As an additional note, whilst the machine's not been powered *up* in a while, it's always been connected to a mains supply with the PSU turned on... which I thought was enough to keep onboard batteries charged.

Does the machine have to actually be powered-up to charge the RTC battery, or could there be some dying component causing problems here?

[robespierre]

Does the machine have to actually be powered-up to charge the RTC battery, or could there be some dying component causing problems here?

While some old computers have rechargeable (most often nickel-cadmium) batteries, I'm not aware of any SGI that used them. They have lithium primary (non-rechargeable) cells. Either CR2032 in the Personal IRIS, or Dallas SmartWatch/TimeKeeper units on most of the others.

It's safest not to leave such old computers (old power supplies, really) on the mains because of the fire risk. If the machine has a soft power circuit, the standby supply and PFC will always be operating and further wearing out. If there is a physical off switch (as there is on Professional and Personal IRIS, at least) I wouldn't be worried.