ok probe-scsi-all /pci@1f,2000/pci@1/SUNW,isptwo@4 Target 0 Unit 0 Disk QUANTUM ATLAS_V_18_SCA 0230 Target 1 Unit 0 Disk QUANTUM ATLAS IV 9 SCA 0909 Target 2 Unit 0 Disk QUANTUM ATLAS IV 9 SCA 0909 /pci@1f,4000/scsi@2 Target 0 Unit 0 Disk QUANTUM ATLAS10K2-TY367JDDD6 Target 1 Unit 0 Disk QUANTUM ATLAS10K2-TY367JDDD6 Target 2 Unit 0 Disk MAXTOR ATLAS10K4_73SCA DFF0 Target 3 Unit 0 Disk QUANTUM ATLAS10K2-TY367JDDD6 /pci@1f,4000/scsi@3,1 Target 4 Unit 0 Processor TRANST MatchBox 1.03 Unit 1 Processor TRANST MatchBox 1.03 Unit 2 Processor TRANST MatchBox 1.03 Unit 3 Processor TRANST MatchBox 1.03 Unit 4 Processor TRANST MatchBox 1.03 Unit 5 Processor TRANST MatchBox 1.03 Unit 6 Processor TRANST MatchBox 1.03 Unit 7 Processor TRANST MatchBox 1.03 /pci@1f,4000/scsi@3 Target 0 Unit 0 Disk IBM DDRS39130SUN9.0GS98E Target 6 Unit 0 Removable Read Only device TOSHIBA XM6201TASUN32XCD1103 ok
Note from October 20, 2008 email re 64-bit:
Just so you know, the 64 bit was caused by me going into single-user mode and transitioning into multi-user mode after that. I believe it did that to me before and I forgot about. So rebooting the box straight into multi-user mode fixes the 64-bit problem.
As per November 5, 2008 A. Conrad/D. Chan email exchange:
The root transputer board (DAQ17) that was swapped in during June 2008 was labelled with a note saying it had been tested with NIRC2 on September 2, 1999.
There exists one more spare DAQ17 for NIRC2. This one is labelled with a note that says it was tested with NIRC2 on September 9, 1999. It was assigned serial number 1000 on November 3, 2008.
There is also one spare DAQ17 for NIRSPEC.
From A. Honey's August 27, 2010 email:
During testing today with alad server version 4.11 (in response to
the problems encountered by A. Conrad during observing the
previous night (see K2-19106 and K2-19107), I
modified
/kroot/kss/nirc2/alad/keyword/Authorize
file. That
file has entries in it of the
form nirc2:nirc2.caltech.edu:1
. I modified the file
to contain all the references to accounts for observing (user
accounts and such) at Keck, and removed the caltech entries. I did
that because the problems on the previous night indicated issues
with the processing of the Authorize file (seg faults occurred on
the response to parsing the file). The modifications I made to the
file did not resolve the problem (show and modify failing). I
subsequently modified the processing of the Authorize file on the
keyword side (show and modify) so that it was effectively
neutered. Those changes are not in effect operationally but are in
version 4.12.
Later in the day the operational system could not be made
functional – the alad_server_bin
would repeatedly
fail. It turns out that the low level startup code uses the
Authorize file to determine if the Transputer boot file is allowed
to be downloaded. As I had left my modification in place and
deleted the Caltech entries, the system failed. I still do not
understand why those original entries in the Authorize file are
essential to booting! I will try to figure it out.