[jwhat]

Hi Irinikus & Co,

I have not touched my SGI stuff recently as I have been busy with Apple Xserve retirement and learning how to virtualise MacOS machines via Linux/Ubuntu/KVM/QEMU.

As part of reviving my IP59_4CPU 4x1GHz board, I run straight into L1 version issues you had as O350 chassis was on 1.24 L1 version.

Aside from voltage related messages, give away was "IP59_4CPU not recognised model" message. Solution being as you described to put back in IP53_4CPU board and flash up to 1.44, which I did in two steps first by using 6.5.25 L1 flashsc / l1.bin and then 6.5.30 L1 flashsc / l1.bin . I keep history of all the various L1/L2 version in my IRIX archive.

I have also previously experienced the 6.5.30 L2 firmware problem. The solution to this was one of gems described on Nekochan.

From recollection the way to solve the problem is a bit fiddly and involves:

1. Logging into L2
2. Going into L2 Shell (shell or ! after telnet'ing into L2)
3. Creating a temporary directory on L2 /tmp and then copying all the files /stand/sysco/lib (?) into this
3. Then tftp or wget to get copy of missing file ( /stand/sysco/lib/libscan.ppclinux.so ) into the new /tmp based directory
4. Then mount the newly created library copy over the top of the original /stand/sysco/lib (?) directory
5. I can't remember if you had to then change /etc/fstab for this to stick with reboot or you could proceed without reboot
6. Now you can use the L2 software from PATCH SG0007149 which will provide L2 update to 1.48.0 (and L1 1.48.1 if you want it, but I have never seen need for L1 patch to 1.48.1).

The reason for the complicated process was due to the /stand/sysco file system being read only squashfs, so could not change this by simply copying the missing file back.

I know this outline is pretty sketchy, but it is start in trying to get some of those nekochan information gems back out there.

I can collect the various irix version flashsc/l1/2 files I have and put them into a tar and put them up on web server for general use if people want.

I have found this collection very helpful as you need to have the right flashsc version with the right l1.bin / l2.bin files to upgrade / downgrade the l1 software.


jwhat
(Yet another Nekochan refugee ;-) )

[Irinikus]

<QUOTE author="jwhat" post_id="1374" time="1530838296" user_id="259">

Hi Irinikus & Co,

I have not touched my SGI stuff recently as I have been busy with Apple Xserve retirement and learning how to virtualise MacOS machines via Linux/Ubuntu/KVM/QEMU.

As part of reviving my IP59_4CPU 4x1GHz board, I run straight into L1 version issues you had as O350 chassis was on 1.24 L1 version.

Aside from voltage related messages, give away was "IP59_4CPU not recognised model" message. Solution being as you described to put back in IP53_4CPU board and flash up to 1.44, which I did in two steps first by using 6.5.25 L1 flashsc / l1.bin and then 6.5.30 L1 flashsc / l1.bin . I keep history of all the various L1/L2 version in my IRIX archive.

I have also previously experienced the 6.5.30 L2 firmware problem. The solution to this was one of gems described on Nekochan.

From recollection the way to solve the problem is a bit fiddly and involves:

1. Logging into L2
2. Going into L2 Shell (shell or ! after telnet'ing into L2)
3. Creating a temporary directory on L2 /tmp and then copying all the files /stand/sysco/lib (?) into this
3. Then tftp or wget to get copy of missing file ( /stand/sysco/lib/libscan.ppclinux.so ) into the new /tmp based directory
4. Then mount the newly created library copy over the top of the original /stand/sysco/lib (?) directory
5. I can't remember if you had to then change /etc/fstab for this to stick with reboot or you could proceed without reboot
6. Now you can use the L2 software from PATCH SG0007149 which will provide L2 update to 1.48.0 (and L1 1.48.1 if you want it, but I have never seen need for L1 patch to 1.48.1).

The reason for the complicated process was due to the /stand/sysco file system being read only squashfs, so could not change this by simply copying the missing file back.

I know this outline is pretty sketchy, but it is start in trying to get some of those nekochan information gems back out there.

I can collect the various irix version flashsc/l1/2 files I have and put them into a tar and put them up on web server for general use if people want.

I have found this collection very helpful as you need to have the right flashsc version with the right l1.bin / l2.bin files to upgrade / downgrade the l1 software.


jwhat
(Yet another Nekochan refugee ;-) )

Hi John, I'm glad to see that you made it here!

Any bit of information we can get our hands on, regarding the intricacies of troubleshooting these machines is valuable! (And your contributions are certainly that)

[kln_nurv]

What exactly are the symptoms if the L2 is bricked by the 6.5.30 bug? Does it happen right away or after several reboots?

[Irinikus]

The Tezro only has an L1 controller.

[jwhat]

What exactly are the symptoms if the L2 is bricked by the 6.5.30 bug? Does it happen right away or after several reboots?

If you connect to serial console port on L2 you will see that is goes into a loop complaining about missing file: libscan.ppclinux.so

I have recently looked back at this and the way to get new writable file systems on L2 is by doing mount to type tmpfs (temp file system):
# cd /tmp
# mkdir TMPFS
# mount -t tmpfs -o size 800k temps /tmp/TMPFS

The mount type tmpfs does mount and creates writable file system at the same time, so there is no need to do mkfs .

Sorry for long delay in response, but I have only just relooked at this.

Cheers from Oz,

John.

[weblacky]

Out of question, how do you guys know the L1 is on the IO9? I mean the RTC Dallas chip that the L1 uses for NVRAM/Time/Logs is on the Mainboard...so why isn't the L1 also on the mainboard?.

Plus the console port you use to talk to it, isn't on the IO9 board. If it's the mainboard's job to be firmware compatible with a later nodeboard...then I'd think the L1 + firmware is on said mainboard.

[jwhat]

Out of question, how do you guys know the L1 is on the IO9?  I mean the RTC Dallas chip that the L1 uses for NVRAM/Time/Logs is on the Mainboard...so why isn't the L1 also on the mainboard?.

Plus the console port you use to talk to it, isn't on the IO9 board.  If it's the mainboard's job to be firmware compatible with a later nodeboard...then I'd think the L1 + firmware is on said mainboard.

Hi Weblacky,

I am not sure if this was in response to my note, but I was talking about bricked L2 not the L1.

The L2 has its own console port and the L2 WILL GET BRICKED if you do a firmware upgrade using the SGI supplied 6.5.30 L2 firmware.

This was a major SGI defect released into production, fix was in PATCH SG0007149.

Maybe we are talking about different things, I am not sure...

Cheers from Oz,


John.

[weblacky]

My response to to post #7, showing a picture of an IO9 board and claiming to try programmers on it to update an L1 "out of system". I wasn't making any reference to your postings about L2 brick...which yes..is real...that's the reason SGI put out a patch 10+ years ago ;-).

[jan-jaap]

I am not sure if this was in response to my note, but I was talking about bricked L2 not the L1.

The L2 has its own console port and the L2 WILL GET BRICKED if you do a firmware upgrade using the SGI supplied 6.5.30 L2 firmware.

This was a major SGI defect released into production, fix was in PATCH SG0007149.

Maybe we are talking about different things, I am not sure...

There was a shared library missing from the L2 software IIRC, right? There were ways to recover from that, but it was surely annoying.

[jwhat]

Hi Jan-Jaap,

yes problem was missing file, which SGI addressed with patch, but they did not document how to get L2 working to point that patch could be applied.

This was documented originally by Prymble Software on Nekochan.

It was not just a simple matter of copy over the missing file as L2 is actually a "BusyBox" embedded Unix deployment and the file system is read only with exception of /tmp.

Hence you need to create new copy of directory via tmpfs mount and then copy all the files to this including the missing file (to get all the files into single directory) and then create another tmpfs over the top of /stand/sysco/lib and copy all the files over to this read/write file system.

Only then can you apply patch.

So a bit of low level tinkering required.

As Weblacky's says a very old patch but important to keep the work around fix documented so others who fall into the same hole can recover their bricked L2 controllers.

Cheers from Oz,


John.