The solution is to install patch 2051 (Jot fix for mmapping), which changes the way jot behaves when accessing files over NFS-mounts. The patch is available from SGI's ftp site(s) at:
ftp://patches.sgi.com/support/patchset/ ftp://patches.sgi.com/support/patchset/.allrecpatch/
If you have patch CD sets (eg. 'IRIX 6.2 Required/Recommended Patches' and the two 'Fix on Fail' CDs that go with it), you'll find patch 2051 on the first of the 'Fix on Fail' CDs.
As far as I know, there is no need to install patch 2051 on a stand-alone system.
NOTE: an alternative solution is to upgrade to 6.5.
<0>PANIC: KERNEL FAULT
PC: 0x8801ad5c ep: 0xffffc710
EXC code:128, `Software detected SEGV '
Bad addr: 0x0, cause: 0x8<CE=0,EXC=RMISS>
sr: 0xff03<IM8,IM7,IM6,IM5,IM4,IM3,IM2,IM1,IPL=0,MODE=KERNEL,EXL,IE>
and the operating system you're using is IRIX 6.2. I don't know if the problem described here occurs with other OS versions.
The problem lies with the kernel rollup patch (the latest version of which is patch 3156 from the September 1998 'Required/Recommended' CD). Apparently, all versions of this patch that are later than patch 2777 will cause the above kernel fault to occasionally occur on any IRIX 6.2 system which has a CPU that does not have secondary cache. This means Indy will be affected more than any other system because several zero-L2 CPUs were used in Indy:
RxxxxSC systems shouldn't be affected by the problem described here, so the very latest kernel rollup patch (3156) should be ok if you're using any of the following CPU types with IRIX 6.2:
However, the first method worked ok.
What if I've already installed a post-2777 patch, eg. 3156?
My experience with this wasn't good.
13 of the 16 Indys in the lab I run have 549MB disks. To save space, I'd removed the patch histories, so patch 3156 couldn't be removed. Thus, for these Indys I had to reinstall them all. This was a trivial procedure: binary disk cloning allowed me to complete the entire reinstallation of all 13 machines in not much more than 2 hours, ie. a single reinstalled disk clones to 2, 2 to 4, 4 to 8, then the final 5 are done (40 mins to create the first disk and about 20 mins for each cloning step).
The other 3 Indys have 2GB disks with alot more software installed (full IDO and Varsity). These were the machines that I had problems with. I ran swmgr, chose 'Manage Installed Software', selected patch 3156 and executed the removal, which was successful. Afterwards, I decided to reboot the system just to make sure everything was ok. Maybe this was the wrong thing to do. Maybe I should have installed patch 2777 at that point, ie. as soon as patch 3156 had been removed. Either way, the system produced a kernel configuration error during the reboot and was unable to successfully reconfigure the operating system. It looked as if the patch installation history had not changed the system back to the state it was in before the patch was installed. Perhaps this happened because the patch was installed as part of a patch set - I don't know.
Anyway, the only choice was to reinstall one of the 2GB disks and clone it to the remaining two. The procedure isn't complex, it just takes much longer because three times more data needs to be installed (at the time, I had to use an old 2X CDROM). Unfortunately, I had executed the above patch removal procedure on all 3 machines with 2GB disks at the same time, so I've no idea whether installing patch 2777 immediately after removing patch 3156 would indeed have been the correct thing to do.
If you find yourself in a position where you have to remove patch 3156, and discover that installing patch 2777 immediately afterwards does work ok, then please let me know because you could save alot of Indy users the hassle of a reinstallation if they encounter this problem.
systune -i
Updates will be made to running system and /unix.install systune->
nfs3_default_xfer = 16384
nfs3_default_xfer = 16384 (0x4000)
Do you really want to change nfs3_default_xfer
to 16384 (0x4000)? (y/n)
In order for the change in parameter nfs3_default_xfer to become effective, reboot the system
Note: the above procedure must be carried out on all the systems on the network.
jot /var/X11/xdm/Xlogin
Search for three lines that look like this:
#if [ -x /usr/bin/X11/xset ] ; then # /usr/bin/X11/xset s 600 3600 #fi
The lines may or may not be uncommented, and note that the numerical values 600 and 3600 might vary between systems, eg. IRIX 6.5 on O2 has 1200 instead of 3600.
Make sure the lines are uncommented, and change the middle line so that the three lines look like this:
if [ -x /usr/bin/X11/xset ] ; then
/usr/bin/X11/xset s 0 0
fi
The xset man page says that supplying xset with zero values makes the monitor deactivate its power saving feature. It works! I made these changes because I want passing new students to see the SGI monitors in an activated state and hopefully become interested. With power-saving turned on, students usually just see monitors with black screens and assume the SGIs are turned of and not for their use, which isn't true.
Load the following file into an editor:
/usr/lib/X11/app-defaults/4DWm
In the section entitled, "4Dwm Specific Appearance and Behavior Resources", look for the line which begins with:
*keyboardFocusPolicy:
By default it says 'pointer'. Change it to 'click'. Save, then logout and back in again.
There are two solutions to this:
1. Install the system using a lesser CPU, such as an R4K/200 (1MB), put on all the software you need, and then after the latest 5.3 patch set has been applied, put back the original R4K/250 CPU. The patch update fixes the 2MB L2 bug.
2. Do the installation using the release of 5.3 which is specifically called, "IRIX 5.3 with 2MB Cache Support". As the name suggests, this release does not have the relevant bug.
nvram SystemPartition 'scsi(0)disk(1)rdisk(0)partition(8)' nvram OSLoadPartition 'scsi(0)disk(1)rdisk(0)partition(0)'
or if you're using something like an Octane and are trying to setup dual-boot 6.4/6.5, the lines for the disk on ID 2 would be:
nvram SystemPartition 'xio(0)pci(15)scsi(0)disk(1)rdisk(0)partition(8)' nvram OSLoadPartition 'xio(0)pci(15)scsi(0)disk(1)rdisk(0)partition(0)'
Enter 'nvram' on its own to see the exact format you should use, eg. an O2 will use slightly different definitions.
After the script changes the nvram settings, just include the reboot command to reboot the system, and that's it!
Note that it's a good idea to include a confirmation question in the script, and some kind of time delay so that one can close any applications and logout if required, though this isn't essential. If you're creating the script for someone else to use then it's essential to make it clear what is happening, and offer the user the chance to cancel the operation.
But one of my disks is already installed and using the wrong ID.
How do I change it? I tried and it doesn't boot!
I initially ran into this problem, thinking that after installing an OS on a disk using SCSI ID 1, all I had to do was change the nvram settings, change the SCSI ID and the disk would boot on ID 2 quite happily, but this isn't the case. The reason is that the /dev directory contains three device files which point to specific disk devices, namely root, rroot and swap. After changing the nvram settings and the SCSI ID, the disk can't boot because these device files will still be point to devices on SCSI ID 1. In my case, I had the wierd situation of the 5.3 disk on ID 2 trying to boot partly from the 6.5 disk which was now on ID 1.
The solution is to erase and recreate the device files using mknod, based on the major and minor numbers that are shown under /dev/rdsk.
Assuming the situation is as I've described, ie. a disk installed using ID 1 (in this case containing IRIX 5.3) is to be changed so that it boots from ID 2, then here's how to do it...
With the disk still on the original SCSI ID 1, boot up and login as root.
Examine the details of the relevant files under /dev/rdsk thus:
# ls -l /dev/rdsk/dks0d2s0
brw------- 2 root sys 128, 32 Jul 17 21:26 dks0d2s0
# ls -l /dev/rdsk/dks0d2s1
brw------- 2 root sys 128, 33 Jul 17 21:26 dks0d2s1
Here, the major/minor numbers for the system partition are 128 and 32, while the numbers for the swap partition are 128 and 33.
Now delete the unwanted old device files and create the new ones:
cd /dev rm root rroot swap mknod root b 128 32 mknod rroot c 128 32 mknod swap b 128 33
By default, this creates the files with slightly incorrect permissions, so do the following to make the necessary changes:
chmod go-r root rroot chmod o-r swap
And that's it! Shutdown (I did a hard power off to make sure the system didn't have a chance to alter anything), change the SCSI ID of the disk to 2 and then power up.
At least that's the theory anyway. Some people reckon that the kernel itself includes some values which refer to the SCSI ID the system should be using, so the advice is to rebuild the kernel too. I found that a straight rebuild attempt with autoconfig did nothing - the kernel was said to be current. Thus, just in case and to be absolutely sure, I forced it to create a new kernel:
/etc/autoconfig -v -f
and then powered off, etc. It worked great! In my case, using an Indigo2, all I had to do was move the disk from the bottom slot to the top slot which changes the ID automatically to 2.
Example 5.3/6.5 Dual-Boot Scripts
For those who aren't familiar with writing scripts, here are the examples I used for a 5.3/6.5 dual-boot setup on an Indigo2. All scripts were stored in /usr/local/bin and all related text files were in /usr/local/doc.
For the 6.5 disk on SCSI ID 1, the script is called 'switch5.3' and contains:
#!/bin/sh
case `xconfirm -c -header "Switch OS to IRIX 5.3..." -icon question -b No -B Yes -file /usr/local/doc/switch5.3.txt`
in
Yes)
echo "Ok! Rebooting the system to run IRIX 5.3 in 30 seconds..."
echo "Close all applications and logout NOW!"
nvram -v SystemPartition 'scsi(0)disk(2)rdisk(0)partition(8)'
nvram -v OSLoadPartition 'scsi(0)disk(2)rdisk(0)partition(0)'
sleep 10 && echo "T minus 20 seconds..." && sleep 10 && echo "T minus 10 seconds..." && sleep 10 && echo "Rebooting!..." && reboot&
;;
No)
echo "Switch to IRIX 5.3 cancelled."
;;
esac
and the text file 'switch5.3.txt' contains:
Are you sure you want to reboot
the system to use IRIX 5.3?
For the 5.3 disk on SCSI ID 2, the script is called 'switch6.5'
and contains:
#!/bin/sh
case `xconfirm -c -header "Switch OS to IRIX 6.5..." -icon question -b No -B Yes -file /usr/local/doc/switch6.5.txt`
in
Yes)
echo "Ok! Rebooting the system to run IRIX 6.5 in 30 seconds..."
echo "Close all applications and logout NOW!"
nvram -v SystemPartition 'scsi(0)disk(1)rdisk(0)partition(8)'
nvram -v OSLoadPartition 'scsi(0)disk(1)rdisk(0)partition(0)'
sleep 10 && echo "T minus 20 seconds..." && sleep 10 && echo "T minus 10 seconds..." && sleep 10 && echo "Rebooting!..." && reboot&
;;
No)
echo "Switch to IRIX 6.5 cancelled."
;;
esac
while the text file 'switch6.5.txt' contains:
Are you sure you want to reboot
the system to use IRIX 6.5?
I also included two extra scripts, one on each disk, to allow for
an immediate change and reboot from one disk to another. These show
what must be done at a minimum in order for the mechanism to work.
On the 6.5 disk, a script called switch5.3fast:
#!/bin/sh echo "Rebooting the system to run IRIX 5.3 NOW!..." nvram -v SystemPartition 'scsi(0)disk(2)rdisk(0)partition(8)' nvram -v OSLoadPartition 'scsi(0)disk(2)rdisk(0)partition(0)' reboot&
and on the 5.3 disk, a script called switch6.5fast:
#!/bin/sh echo "Rebooting the system to run IRIX 6.5 NOW..." nvram -v SystemPartition 'scsi(0)disk(1)rdisk(0)partition(8)' nvram -v OSLoadPartition 'scsi(0)disk(1)rdisk(0)partition(0)' reboot&
Note that the script names are quite long compared to most UNIX commands because it is important to make 'dangerous' operations of this kind difficult to do by accident.
This can be a frustrating problem to solve. Swapping out frontplanes, using other V6s, etc., all have no effect. All the parts are known to be ok, but it still doesn't work.
The solution is to make sure the OS is reasonably up to date (eg. 6.5.26) and then reflash the system PROM before swapping in the V6. Do this with by logging in normally as root and entering:
flash -v
This situation will most often occur when upgrading an older non-VPro Octane, eg. an R10K/250 SI. If your system is more up to date, eg. an R12K/300 SE, then it's more likely the PROM will already be at a revision that understands the V6 ok.
Thanks to Emery Davis for this information.
The use of fx is the same, eg. to repartition a disk as a system disk with an XFS file system, but the syntax for doing a mkfs on the disk is more verbose. Thus, for example, if you're used to the mkfs command being used like this under IRIX 6.2/6.5:
mkfs /dev/dsk/dks0d2s7
then here is how you would do the same operation under IRIX 5.3 with XFS:
mkfs -b size=4096 -d name=/dev/dsk/dks0d2s7 -l internal,size=1000b
or if the disk is smaller than 4GB:
mkfs -b size=512 -d name=/dev/dsk/dks0d2s7 -l internal,size=1000b
The best thing to do is to setup a couple of simple scripts in /usr/local/bin to do all of the hard work, eg. a file called mkf containing:
#!/bin/sh mkfs -b size=512 -d name=$1 -l internal,size=1000b
and another called mkfl (mkf large) for use with 4096 block size:
#!/bin/sh mkfs -b size=4096 -d name=$1 -l internal,size=1000b
then you can use the scripts much as you would use mkfs under 6.2 or 6.5:
mkf /dev/dsk/dks0d2s7
Presumably SGI changed how mkfs works with the release of IRIX 6 so that the extra detail is not needed. Indeed, the detailed nature of XFS has changed several times, so that, for example, a disk mkfs'd under IRIX 6.5 will not be mountable under IRIX 6.2. If you want to have an XFS file system which can be mounted by any XFS-capable OS version, then you should use IRIX 6.2 to fx and mkfs the drive.
NOTE: none of the above applies to dealing with EFS file systems, and remember that the standard November 1994 release of 5.3 does not support XFS.
hosts: files dns
If you don't make use of any DNS servers, then 'dns' can be removed aswell.
It is also a good idea to make sure the icon caches are up-to-date and cleaned, so enter as root:
/usr/lib/desktop/cleanCache types /usr/lib/desktop/cleanCache layouts /usr/lib/desktop/flushCache types /usr/lib/desktop/flushCache layouts
Lastly, I find it helps a little if a file manager window is always open and minimised, so either use the Toolchest or enter:
fm