SUMMARY: phase parity error

From: Tanya Herlick (
Date: Mon May 16 1994 - 11:18:47 CDT

Original problem at the end. Also a good explanation and suggestions about
what to do when you get in this pickle.

As many of you have suggested, the phase parity error was due to a duplicate
SCSI id, cable problem, or termination problem. I'm still not 100% sure
which one it was.

Here's the configuration and why it wasn't immediately obvious. We have
2 scsi controllers esp0 (Sun), and ptscII0 (Perf. Technologies).
On esp0 are the following disks sd0, sd1, sd2 (jumpers set to ids 0, 1, 2).
On ptscII0 are these disks sd4, sd5, sd6, sd7 (jumpers set to ids 0, 1, 2, 3).

I added another disk to esp0 and set the jumpers to 5 (I guess this is the
"target" number in the kernel config file?). When I booted the disk came up
with SCSI ID 16 (sd16 at scsibus0 target 5 lun 0--this is how our kernel was

Since no other jumpers were set to ID 5, and there were no other sd16s I
assumed this was not a conflicting ID problem.

I also put a new ribbon cable on the second scsi bus with a terminator on
the cable (as opposed to having the termination on the last disk).

Once I removed the new disk, installed the new cable, and ensured the
termination was correct, the system booted just fine. I'm still not sure
which was the deciding factor.

Thanks to the following people for suggestions and support:

"Lewis E. Wolfgang" <> (Michael Sullivan)
Mike Raffety <> (Joel Shandelman)


On May 13, 11:40am, Michael Sullivan wrote:
> Subject: Re: phase parity error
> This message means data is being corrupted on the SCSI bus.
> In addition to a bunch of control signals, the SCSI bus has 8 data
> signals and a data parity signal which is set so the total number of 1's
> on the 9 data signals is odd. If this condition is violated, a SCSI knows
> that the data on the SCSI bus is has been corrupted and should not be used.
> First check that you haven't inadvertantly set two devices to the same
> SCSI address. Remember that the host controller normally uses address
> 7. If your tower has external switches to control the disks'
> addresses, make sure that the cables are firmly connected from the
> switches to the drives. If the drives' addresses are set by jumper
> shunts, examine them to see that they are in good condition, although
> rare, I have seen cases where a shunts contacts were bent in such a way
> that it didn't make contact with the pins.
> Another likely cause is a loose SCSI cable or terminator. Recheck all
> connections. If you can't spot anything obviously loose try taking off
> each connector and blowing on it (both plug and socket) in case some
> dust got on them and is interferring with the connection. Next try
> substituting a known good cable for each existing cable in turn in case
> a wire broke inside one of them, or, if feasible, try booting (single
> user mode) with only one external SCSI device connected at a time (plus
> the terminator, of course).
> --
> Michael T. Sullivan | email:
> TradeLink L.L.C. | voice: +1 312 408 2599
> 175 W. Jackson, Suite A1235 | fax: +1 312 939 2531
> Chicago, Illinois 60604 USA |
>-- End of excerpt from Michael Sullivan


Original problem:

> Help!
> We have a Sun 670MP and a tower. SunOS 4.1.3.
> We have a Performance Technologies SCSI controller that
> controls the disks in the tower. I was shuffling around disks on the
> system and now I can not boot! During the part of booting where all the
> hardware gets checked, the boot gets stuck at the PT scsi controller and
> spews scads of these messages:
> ptscII0: SCSI bus MESSAGE OUT phase parity error
> When I disconnect the cable to the tower, the system boots fine.

Tanya Herlick 
System Administrator at O'Reilly and Associates	
90 Sherman St. Cambridge, MA 02140   ph: 617/354-5800 fax: 617/661-1116
to reach me: 617/499-7459     email:; uunet!!tanya

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:01 CDT