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