SUMMARY: SCSI bus errors while writing to Exabyte 8500

From: Forrest Cook (cook@stout.atd.ucar.edu)
Date: Thu Aug 22 1991 - 14:56:07 CDT


Wow, what service! I got several replies to my question as well as a few
"I have the same problem" messages. The problem was that SYNC_SCSI was
enabled and the Exabyte was not responding correctly. Here are the two
messages that helped me get things running:

The immediate fix:

>From: stern@bitatron.Eng.Sun.COM (Hal Stern - Consultant)
>
>your exabytes are probably lying. in sunos 4.1.1,
>the scsi driver probes each device and asks if it
>would like to run in sync transfer mode, and if so,
>what rate it likes. your exabytes are probably
>saying "yeah, sure, we'll do synch" but then they
>aren't prepared to handle the sync transfers -- they
>try to do async operation and confuse the bus.
>
>when this happens, the scsi host adaptor (the
>esp0 driver) says "ok, we'll go back to async land"
>and it resets the "does synch" flag. when you access
>the drive again, the driver says "hmmm....maybe he
>can handle synch .... let's ask" and the tape
>repeats it's earlier "yup" reply. so the cycle
>repeats.
>
>fix:
>use adb on the kernel, and look at the "scsi_options"
>flag. subtract 0x20 from this value and rewrite
>it, and you should be set:
> # adb -k /vmunix /dev/mem
> scsi_options/X
> _scsi_options: 78
>> $W
> scsi_options?W 58
> scsi_options/W 58
> $q
>
>where does 0x20 come from? it's the "always negotiate
>synch" flag, defined in /sys/scsi/conf/autoconf.h
>if you turn this bit off, the host adaptor will never
>try to set up synch transfers
>
>--hal stern
> sun microsystems
> northeast area consulting group

The long term fix:

>From: phil@cgrg.ohio-state.edu (Phil Ritzenthaler)
>
>have you tried removing/commenting out the synchronus entry in
> /sys/scsi/conf/scsi_confdata.c
>
>take out the line SCSI_OPTIONS_SYNC
>
>and remake the kernel. You have to do this if you have an exabyte on the
>system.
>
>good luck . . .

Thanks for all of the replies and I hope this helps those of you with
this problem.

My original posting:

Greetings sun-managers, has anyone seen a problem like this before?

When I create a tar file on the Exabyte with the command:
tar -cvf /dev/nrst8 20_meg_file

I get the following message repeated many times:
esp0: Target 4 now Synchronous at 2.0 mb/s max transmit rate

I occasionally get a bunch of these messages as well:
Aug 21 14:13:55 barleywine vmunix: esp0: Spurious data out phase from target 4

These messages only happen during write operations.

The system is a Sparc SLC client running Sunos 4.1.1
with 2 Exabyte 8500 high density drives and nothing else on the bus.
The Exabytes are both running the rev 0050 firmware from May 91.

So far I have tried:
- Running a cleaning tape through the drive.
- Changing tapes (Sony P6-120MP)
- Running the command on both of the exabyte drives.
- Changing SCSI cables.
- Changing to a different SLC.
- Changing the SCSI terminator.
- Re-squeezing the scsi mass-termination connectors inside of the box.
The messages still persist.

Amazingly, the files that I am writing may be read back and seem to be
unchanged from the original according to diff.

Forrest Cook
cook@stout.atd.ucar.edu WB0RIO
{husc6|rutgers|ames|gatech}!ncar!stout!cook



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:19 CDT