Thanks for listening Sun Managers, but no one hit the jackpot.
First, the solution. It was a faulty SCSI terminator. An
intermittent problem which made diagnosis difficult, but it was
finally isolated by trying the SCSI terminator alone on another Sun
system where we were able to duplicate the symptoms.
Credit goes to our "Sun Authorised Service Representative", Cliff
Rose, and myself :).
Cliff had never encountered this error before and it seems no one
else out in sun-managers land had either as there were no reports of
similar problems elsewhere. Here is a copy of my original message and
the responses I received, thanks to the three responders. The first
one suggests making sure those connections are sound, the other two
shed some light what "phase" is in the SCSI sense and possibly what
the monitor was complaining about.
--- original message ---
OK Sun managers, todays challenge is:
Configuration:
SS1, 16Mbytes of RAM, SunOS 4.1 and one ESM "Shoe box" (669Mbyte disk
and QIC-150 tape unit).
Problem:
Fell over last night sometime with "SCSI reset" (error messages not
noted unfortunately). Now when we attempt to boot the system we get
"SCSI unexpected phase = 80002800". Here is what happens when we try
to reboot by powering off or using "reset":
[ Logo and other information appear, ROM Revision (1.0), amount of
memory, ethernet address, etc - Note the word "Testing" does not
appear as it usually does. ]
SCSI unexpected phase = 80002800
ok [any command yeilds...]
Data Access Exception
By switching off the ESM unit and powering up the SS1 I can talk to
the monitor with out the "Data Access Exception" error message. I then
switch the drive back on, wait for it to power up and use the
"probe-scsi" command with the following results:
ok probe-scsi
Target 3
Unit 0 Disk MAXTOR XT-8760S SUN669 SUNC
SCSI unexpected phase = eb2403fc
About a week ago the machine was upgraded to 4.1, 16Mbytes of RAM
(from 8), and the larger disk unit. We swapped the tape unit from the
outgoing ESM (no scsi address switches) with a 327Mbyte CDC Wren IV to
the new disk unit. Everything has worked fine until now.
Attempted fixes so far:
I tryed reconnecting the scsi cable from the pizza box to the ESM,
making sure the connections were sound - no improvement.
So what does "SCSI unexpected phase = [blah]" mean? And more
importantly what needs to be fixed?! I checked out the error messages
from the monitor and boot program in the System and Network
Administration manual (appendix E), but it did not list this
particular error message at all. We have logged a fault call with Sun,
so now we sit and wait. I would be keen to hear from anyone who has
had a similar problem (and hopefully solved it :).
I will summarise - thanks in advance.
--- end original message ---
--- reponses ---
From: jeg@ced.berkeley.edu (James Ganong)
On my sgi's I get an "unexected phase" when the connections are not
REALLY FIRMLY pushed in. The drives are mounted on slide out
brackets that click loudly when they are in place. But I even then
I get "unexpected phase" if I don't press them in REAL HARD.
I know this is not very explanatory, but good luck.
From: dan@breeze.bellcore.com (Daniel Strick)
"SCSI unexpected phase" is probably a reference to the state of three
SCSI signal lines (in/out, cmd/data, normal/message) that the target
(the disk) sets to tell the initiator (the cpu host adapter) what the
target wants to talk about. The sun SCSI driver probably doesn't know
how to handle a certain sequence of phase transitions generated by
the target. The issue is complex. Only SCSI enthusiasts and other
masochists deal directly with phases. I must refer you to the ANSI
standard X.131-1986 for further disinformation.
From: kevin%ronin%sundev@Sun.COM (Kevin Sheehan {Consulting Poster Child})
Reply-To: kevin%synergy@Sun.COM
SCSI transactions go thru several bus phases - for instance, a normal
read/write will go thru arbitration, selection, command, status, and
possibly message in/out during it's lifetime.
In this case, one of the drivers (presumably the prom) is telling
you that the bus is in an unexpected phase at some point. The UNIX
driver is fairly tolerant (i.e. there are many possibilities as to
which phase comes next, the UNIX code is more flexible) of all this.
I don't have the esp docs around anymore, but you might consider waiting
until the UNIX driver is around, and then switching on the drive - that
way you'll at least get the phase named (if it *is* a legal phase...)
--- end responses ---
Tony Martindale Computing Services Centre,
email: tony@rata.vuw.ac.nz Victoria University of Wellington,
phone: +64 4 721 000 x8453 P.O. Box 600, Wellington, NEW ZEALAND.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:12 CDT