Hello
sorry if I'm late with my summary but I'm still not sure of the solution
to my problem. Because the error message seems to be "random"
I will wait a little more before to say that it is solved ...
For the moment we changed the Transceiver and the error seems to be
disappeared .but I'm waiting to change the SCSI cable ..
Thanks a lot to all that were been involved ...
Best Regards
elena
My original post was :
> Subject: SCSI transport failed
>
> Hello,
>
> in /var/adm/messages* I founded this series of messages ...
> Can anyone help me to understand where is the problem?
> (what's means SCSI transport failed: reason 'reset' ????)
>
> p.s. sunvlsi is a sun station : SunOS 4.1.3 1 sun4m
>
> Thanks a lot
> Cheers
> elena
>
> Jul 23 09:28:15 sunvlsi vmunix: esp2: Current command timeout for Target 3 Lun 0
> Jul 23 09:28:15 sunvlsi vmunix: esp2: State=DATA_DONE (0xa), Last State=DATA (0x9)
> Jul 23 09:28:15 sunvlsi vmunix: esp2: Cmd dump for Target 3 Lun 0:
> Jul 23 09:28:15 sunvlsi vmunix: esp2: cdb=[ 0x8 0x9 0x55 0xf0 0x70 0x0 0x0 0x0 0x0 0x0 ]
> Jul 23 09:28:15 sunvlsi vmunix: esp2: Target 3.0 reverting to async. mode
> Jul 23 09:28:15 sunvlsi vmunix: sd8: SCSI transport failed: reason 'reset': retrying command
>
>
> Jul 16 09:12:38 sunvlsi vmunix: esp2: Current command timeout for Target 1 Lun 0
> Jul 16 09:12:38 sunvlsi vmunix: esp2: State=DATA_DONE (0xa), Last State=DATA (0x9)
> Jul 16 09:12:38 sunvlsi vmunix: esp2: Cmd dump for Target 1 Lun 0:
> Jul 16 09:12:38 sunvlsi vmunix: esp2: cdb=[ 0x28 0x0 0x0 0x31 0xcc 0x6c 0x0 0x0 0x38 0x0 ]
> Jul 16 09:12:38 sunvlsi vmunix: esp2: Target 1.0 reverting to async. mode
> Jul 16 09:12:38 sunvlsi vmunix: sd9: SCSI transport failed: reason 'reset': retrying command
>
>
> Jul 16 09:43:15 sunvlsi vmunix: esp2: Current command timeout for Target 3 Lun 0
> Jul 16 09:43:15 sunvlsi vmunix: esp2: State=DATA_DONE (0xa), Last State=DATA (0x9)
> Jul 16 09:43:15 sunvlsi vmunix: esp2: Cmd dump for Target 3 Lun 0:
> Jul 16 09:43:15 sunvlsi vmunix: esp2: cdb=[ 0x8 0x9 0xf8 0x30 0x70 0x0 0x0 0x0 0x0 0x0 ]
> Jul 16 09:43:15 sunvlsi vmunix: esp2: Target 3.0 reducing sync. transfer rate
> Jul 16 09:43:15 sunvlsi vmunix: sd8: SCSI transport failed: reason 'reset': retrying command
> Jul 16 09:43:15 sunvlsi vmunix: sd9: SCSI transport failed: reason 'reset': retrying command
>
Here the answers:
From: Mark Gahan <mgahan@dxcern.cern.ch>
Hi,
This looks like a hardware problem with your SCSI line/drives are you
able at a prom level to probe-scsi. Are all the attached devices found?
Does the system boot cleanly. Have you added any SCSI devices recently?
Cheers,
Mark.Gahan
Email:mgahan@dxcern.cern.ch
TEL:6478
-----------------------------------------------------------------------------
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
In this case, it means that a command timed out, so the driver reset the
bus in order to restart the command. Since this is most often due to cabling
problems, it reverts to async, which is more reliable on a flakey bus.
I'd check the cables, or see if you are using third party drives that need
something patched/jumpered...
l & h,
kev
-----------------------------------------------------------------------------
From: Travis <tehoyt01@msuacad.morehead-st.edu>
Hiya,
Well I've had a similar problem and I'll tell you what I did.
The problem was that I have an Exabyte tape drive between the
CPU and a Seagate 9.0 Gb drive. Well the CPU and the drive can
talk at 10 meg/sec...the tape drive however cannot. So in the file:
/kernel/drv/esp.conf i put the line:
scsi-options=0x178;
This slowed the SCSI chain down to 5 meg/sec. It worked for me.
You will probably get a bunch of messages in response saying to shorten
your scsi cables and get some special terminators...while true it's best
to have the shortest distance between your scsi devices...it is not
always the answer to every scsi 'reset' error. It's just something
you may want to try...see if it works for you. I can't hurt it that's
for sure. Just don't forget the ";" at the end of the line...'tis very
important.
Good luck!!
Travis
--
Travis Hoyt <tehoyt01@msuacad.morehead-st.edu>
Morehead State University
-----------------------------------------------------------------------------
From: Bob Corbett <bob@singapore.geco-prakla.slb.com>
I get those all the time on one particular machine. I suspect that it
comes from having SCSI-II and SCSI-I devices on the same SCSI bus. The
errors always seem to popup when we access the one SCSI-II disk.
Tha's just my theory, though. I'll be intersted in your summary,
Regards,
bob
------------------------------------------------------------------------------
From: "Sergey Gribov" <sergey@venus.compugen.co.il>
Hi,
It seems, that you have some problem with the SCSI devices on targets 1 or 3.
"SCSI transport failed: reason 'reset'" means, that target device doesn't react
to some host's command much time, so host thinks that something hangs and does
reset on the all SCSI bus.
Try to check all SCSI connectors and termination. Its may be also a problem of
one of devices.
Note, that this is may be a problem of some another device, than 1 or 3, if
some another device doesn't respond and you trying to do something f.e. with
device 1, you'll get reset on device 1.
rgrds,
------------------------------------------------------------------------------
From: suner@intas.ke.sanet.sk
Hi Elena,
I had similar problem like you ( same messages). I found that it was
caused either by my external disk (HP) or by cables it is conected
to SparcStation 20 ( centronics cables instead of micro D cables).
I havent solved it problems till now, but after disconecting
this external disk it works ok.
bye
dodi
------------------------------------------------------------------------------
From: ashley@savy.itg.ti.com ( Ashley Gilbert)
Hi,
Me too!Pls let me know the solution if you get any.I keep getting this error
on couple of systems ,But systems still works!
Ashley
E-Mail:- ashley@india.ti.com
elena
------------------------------------------------------------------------------
From: Weldon S Godfrey 3 <weldon@PCS.CNU.EDU>
You might want to try a different SCSI cable.
------------------------------------------------------------------------------
From: bismark@alta.jpl.nasa.gov (Bismark Espinoza)
Have you added SCSI-1 and SCSI-2 devices?
Or a new disk? There is scsi problems with some
scsi devices not responding to scsi-2 commands,
scsi-2 tagged commands, etc.
------------------------------------------------------------------------------
From: cdoane@geoworks.com (Chris Doane)
Elena -
I, too, have been seeing these messages for awhile and have
had some funny business occuring from time to time on one
of the scsi buses on a Sparc 10. Turns out the problem is
related to mixing 3rd-party drives on the bus, mixing fast-
scsi drives with older models.
Sun support was pretty helpful with this problem - they
suggested setting the scsi bus to asynchronous. I asked
them about what kind of performance hit to expect, and
they sent me this great white paper - which I will include
for you.
I've yet to change the setting, as this is a production
machine and I haven't been able to take it down yet. But
I think you'll find the enclosed mail from Sun insightful.
Chris Doane
cdoane@geoworks.com
----- Begin Included Message -----
>From gary@lapis.corp.sun.com Wed Jul 19 16:16:44 1995
Date: Wed, 19 Jul 1995 16:12:11 -0700
From: gary@lapis.corp.sun.com (Gary Northup)
To: cdoane@geoworks.com
Subject: Re: scsi timeouts, SO# 2051225
Hi Chris,
In response to my inquiry;
>I've told my customer to set his scsi bus to asynchronous but he wants to know
>>what to expect if he does this.
I received this from my *best* scsi engineer.
...
In async mode, the xfer speed is about 3-5MB/sec compared to
5MB/sec in sync and 10 MB/sec in fast sync
Since the data xfer is only a small part of the time on the bus
(assuming small xfer sizes) and the overhead of the scsi
protocol the performance hit isn't very high
fritS
...
As far as data loss/disk crashes, it is no more likely that you will get them
after making the change than before. I'll include a scsi white paper that
includes lots on various scsi subjects. It's getting a little old but still
asnwers some questions.
Gary
---
>I'm tempted to jump right into this, as I'm very concerned
about possible disk crashes and data loss - this would be
painful. But, I think it might be wise to find out a little
about the implications of what you're proposing before I enact
this change. Could you explain for me what would be the effect of
turning off syncronous scsi, and why this may be the answer
to my problem? Or maybe you could direct me to an FAQ or
further reading on this subject.
--59e2_1cfb-3f54_ff6-abd_31df
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-MD5: nMnBo2vjJmUM34u//nk7Vw==
Content-Description: scsi white paper
>From Gary.Croak@Corp Thu Oct 22 11:12:24 1992
Date: Thu, 22 Oct 92 11:15:16 PDT
From: Gary.Croak@Corp (gary c croak - CS Engineering)
To: crosstalk@EBay
Subject: Fast SCSI Configuration White Paper
Cc: davis.macfawn@east, jonathan.berry@east, loydstaff@n6xm.EBay.Sun.COM,
se-hw@vintage.Corp.Sun.COM, se-sw@vintage.Corp.Sun.COM
Content-Length: 20596
X-Lines: 459
Status: RO
The following white paper produced by Bob Snively is the result of
efforts by SCSI Engineering, TSO Support Engineering, Marketing, and
Technical Publications. The goal is to provide practical guidelines
for setting up and supporting fast (10MB/sec) SCSI systems and
peripherals. In addition, mixing fast and slow devices on the same bus
is described as is mixing "older" SCSI devices.
For further clarification or discussion of this paper please reply
directly to me. Thank you.
gary c croak
TSO Support Engineering
gary.croak@corp
x67650
To: Distribution
From: Bob Snively
Date: October 21, 1992
Subject: SCSI Configurations using Single-Ended Fast SCSI Devices
1.0 SCOPE
The high performance SCSI devices now available provide
the capability of significantly improving system performance
for some applications. One of the special capabilities of these
devices is the ability to transfer data at a 10 megabyte per second
data rate using the "fast SCSI" synchronous transfer timings
defined by the SCSI-2 standard. These high performance SCSI devices
are fully compatible with standard SCSI devices and will operate
in almost all normal SCSI configurations. Some SCSI enclosures,
cables, and terminators do not take into account the special loading
and impedance matching requirements for fast SCSI. The attachment
of such peripherals may cause systems using fast SCSI devices to
operate incorrectly. Such non-conforming SCSI cables and
enclosures include some of Sun's early designs and some third-party
cables, terminators, and peripheral device enclosures.
The installation manuals for all fast SCSI devices and all new
Sun installation manuals contain the strong recommendation that
fast SCSI devices not be placed on the same SCSI port with
SCSI components that do not conform with the requirements for
fast SCSI. This paper provides recommendations for the
technical modifications that can be made in a SCSI system to allow the
operation of fast SCSI and non-conforming enclosures, cables, or
terminators on the same system.
2.0 IDENTIFICATION OF Sun SYSTEMS REQUIRING SPECIAL ATTENTION
Differential SCSI host adapters and devices, including the
DSBE/S card and the Differential SCSI Data Center Disk Tray,
are all designed to meet fast SCSI requirements and will
operate at 10 Megabytes per second. The maximum total cable
length of a differential SCSI system is 25 meters. The
installation guides for the SCSI devices indicate
the equivalent cable length of the device.
SCSI host systems that operate at 5 megabytes per second, including
all Sun SPARC-based systems developed prior to the SPARCsystem 10, will
support any presently defined configuration of 5 megabyte
SCSI devices. A fast SCSI device can be installed on such
systems, since the host and the fast SCSI device automatically
negotiate the proper operational speed. Fast SCSI devices
attached to 5 megabyte hosts will only operate at 5 megabytes,
but the capacity and access latency improvements provided by
many such devices can still improve the flexibility and
performance of such systems. Single-ended SCSI systems operating
at 5 megabytes have a maximum total cable length of 6 meters.
^L
SCSI systems and host adapters that operate at 10 megabytes per
second, including the SPARCsystem 600MP series, the SPARCsystem 10,
and the FSBE/S host adapter, will support any presently defined
configuration of 5 megabyte devices. Again, the host will
determine automatically that the devices are 5 megabyte per
second devices and negotiate the proper operational speed with
each device.
SCSI host systems that operate at 10 megabytes per second and
have at least one fast SCSI device attached require that the
entire SCSI port configuration be composed of components that
will support fast SCSI. The components include cables, device
enclosures, and terminators. The recent Sun SCSI products, including
the Desktop Storage Pack, the Desktop Storage Module, and
SCSI Expansion Pedestal are devices and enclosures that meet
the fast SCSI requirements. The regulated terminator
(Sun part number 150-1785-02) meets the fast SCSI
requirements. The host will negotiate with the 10 megabyte devices
to perform 10 megabyte transfers and with the each of the other
devices to perform transfers at their preferred rates.
Single-ended SCSI systems operating at 10 megabytes using the
proper components have a maximum total cable length of 6 meters,
in accordance with the proposed SCSI-3 standard.
Those Sun enclosures with the three-row 50-pin D connector,
including the External Storage Module, do not meet the fast
SCSI requirements. Those Sun enclosures with the
Centronics-style 50-pin flat ribbon contact connector, including
the Front Load 1/2-inch Tape Drive, do not meet the fast
SCSI requirements. The Sun SCSI terminators other
than 150-1785-02 do not meet the fast SCSI requirements.
Section 4 of this paper defines the steps that must be taken to
assure reliable operation of fast SCSI systems containing
combinations of fast SCSI devices and components that do not
meet the fast SCSI requirements. The maximum total cable length
for such systems should not exceed 6 meters.
SUMMARY OF SYSTEM REQUIREMENTS
TABLE 1
| SCSI Host | fast SCSI | 5 Mbyte SCSI | Special |
| Type | device | device | Modifications |
| | installed? | installed? | Required? |
|_____________|_____________|________________|_______________|
| | | | |
| 5 megabyte | don't care | don't care | no |
|_____________|_____________|________________|_______________|
| | | | |
| 10 megabyte | no | don't care | no |
|_____________|_____________|________________|_______________|
| | | | |
| 10 megabyte | yes | all conform | no |
| | | to fast SCSI | |
| | | requirements | |
|_____________|_____________|________________|_______________|
| | | | |
| 10 megabyte | yes | one or more | yes |
| | | don't conform | see section 4 |
| | | to fast SCSI | |
| | | requirements | |
|_____________|_____________|________________|_______________|
^L
3.0 IDENTIFICATION OF MIXED VENDOR SYSTEMS REQUIRING SPECIAL ATTENTION
SCSI peripheral devices, connectors, and cables provided by
companies other than Sun are not tested by Sun in the fast
SCSI environment. If any of the following symptoms occur
when using such devices in Sun fast SCSI systems, it may be because
the peripheral device, related components, or the configuration does
not conform to the fast SCSI requirements. The steps described in
section 4 can usually be used to correct these symptoms if the
components meet the standard SCSI requirements. The system will
usually continue operating normally, even if these errors do occur,
because as part of the software error recovery, the SCSI data rate is
slowed to allow reliable operation.
The maximum total cable length for such devices should be 6 meters
if they properly follow the recommendations of the SCSI standards
committee.
CHART OF SYMPTOMS
RELATED TO SCSI DEVICES NOT MEETING FAST SCSI REQUIREMENTS
Sun OS 4.1.3
Examples of the warning system messages that occur during
boot are contained in the appendix to this paper. The
key words of one symptom are:
Target 1.0 reducing sync. transfer rate
SCSI transport failed: reason 'reset': retrying command
Target 1.0 reverting to async. mode
SCSI transport failed: reason 'reset': retrying command
A second symptom may be:
Current command timeout for Target 3 Lun 0
Cmd dump for Target 3 Lun 0:
Target 3.0 reducing sync. transfer rate
SCSI transport failed: reason 'reset': retrying command
A third symptom may be:
Error for command 'read'
Error Level: Retryable
Sense Key: Aborted Command
Vendor 'XXYYZZ' error code: 0x47
^L
Sun Solaris 2.x
Examples of the warning system messages that occur during
boot are contained in the appendix to this paper. The
key words of one symptom are:
WARNING: ....
SCSI bus DATA IN phase parity error
WARNING: ....
Error for command 'read' Error Level: Retryable
Sense Key: Aborted Command
......
A second symptom may be:
WARNING: ....
SCSI transport failed: reason 'timeout': retrying command
The present negotiated data rate in kilobytes per second
can be determined for a disk by requesting the necessary
data with the prtconf command as shown below. If the
negotiated rate is lower than expected, error recovery
procedures may have been executed because of non-conforming
devices in the configuration.
# prtconf -v
esp, unit #0
Driver software properties:
name <target1-sync-speed> length <4>
value <0x00002710>.
The value 0x00002710 is 10000 kilobytes per second in decimal.
If the boot process was not observed, the boot messages
are stored in the file /var/adm/messages for reference.
The messages can be displayed by performing the command:
# dmesg | more
4.0 METHODS FOR MANAGING FAST SCSI SYSTEMS WITH NON-CONFORMING COMPONENTS
4.1 Follow installation recommendations
The use of fast SCSI hosts and fast SCSI peripherals provides
significant performance improvements for some types of applications.
To take full advantage of those performance improvements,
the installation guides for SCSI devices recommend that
only those components and peripheral devices supporting fast SCSI
requirements be installed on a fast SCSI port. If non-conforming
devices must also be installed on a host, a separate SCSI
host adapter should be installed and all the non-conforming
devices should be installed on that SCSI port, isolated from
all the fast SCSI devices that are running on fast SCSI
host adapters.
^L
4.2 Actively terminate SCSI configurations containing the ESM
The External Storage Module (ESM) is a special case, since it conforms
to the fast SCSI requirements except for its adapter cable and
terminator. The following procedure allows the correct
termination of the External Storage Module and allows
correct fast SCSI operation for all fast SCSI devices installed
on the SCSI port as well as normal synchronous operation for the
devices installed in the ESM.
One or two ESMs may be installed in the middle of a string of SCSI
devices. Use a Desktop Storage Pack or Desktop Storage Module
with a regulated terminator (Sun part number 150-1785-02) as
the device farthest away from the host on the SCSI port.
Connect the ESM's into the string of SCSI devices using 0.8 m
Sun cables. (Sun part number 530-1829-01, Rev.51). Do not exceed
the maximum total cable length of 6 meters.
4.3 Slow all SCSI ports to asynchronous operation.
For all other fast SCSI hosts attaching devices that do not
conform with the fast SCSI requirements, the operating system
should be modified to run all SCSI ports in asynchronous mode.
This slower mode fully interlocks all the SCSI data transfer
signals and provides for reliable operation of the Extended
Storage Module at the end of a SCSI bus. It allows
Sun configurations containing both fast SCSI drives and
non-conforming devices to operate reliably on fast SCSI ports.
If the system configuration meets the standard SCSI requirements,
then reliable operation can usually be provided with third-party
components and peripherals as well. The slower data rate applies
to all SCSI ports on the system. Some applications may show
a decrease in performance because of the slower data rate.
^L
For 4.1.x. OS:
To change to the slower asynchronous data rate, type:
adb -w /vmunix
scsi_options?W 58
$q
then reboot the system.
To turn synchronous transfer back on at the
highest possible speed, use the same procedure,
replacing the middle line with:
scsi_options?W 178
For Solaris 2.x:
To change to the slower asynchronous data rate,
add the following line to /etc/system file:
set scsi_options = 0x58
then reboot the system.
To turn synchronous transfer back on at the
highest possible speed without using tagged
queueing, change the scsi_options line to:
set scsi_options = 0X178
To turn synchronous transfer back on at the
highest possible speed allowing tagged queueing
(if available in the operating system),
change the scsi_options line to:
set scsi_options = 0X1f8
^L
APPENDIX A
SAMPLES OF 4.1.3 ERROR MESSAGES
In this example, target 1 (sd1 on esp0) is a fast scsi disk
Sep 16 15:53:23 b34a vmunix: esp0: Target 1.0 reducing sync. transfer rate
Sep 16 15:53:23 b34a vmunix: sd1: SCSI transport failed: reason 'reset': retrying command
Sep 16 15:53:23 b34a vmunix: esp0: Current command timeout for Target 1 Lun 0
Sep 16 15:53:23 b34a vmunix: esp0: State=DATA_DONE (0xa), Last State=DATA (0x9)
Sep 16 15:53:23 b34a vmunix: esp0: Cmd dump for Target 1 Lun 0:
Sep 16 15:53:23 b34a vmunix: esp0: cdb=[ 0x8 0x0 0x7e 0x0 0x10 0x0 0x0 0x0 0x0 0x0 ]
Sep 16 15:53:23 b34a vmunix: esp0: Target 1.0 reverting to async. mode
Sep 16 15:53:23 b34a vmunix: sd1: SCSI transport failed: reason 'reset': retrying command
or
Sep 16 15:57:41 b34a vmunix: sd3 at esp0 target 0 lun 0
Sep 16 15:57:41 b34a vmunix: sd3: <SUN0669 cyl 1614 alt 2 hd 15 sec 54>
Sep 16 16:01:12 b34a vmunix: esp0: Current command timeout for Target 3 Lun 0
Sep 16 16:01:12 b34a vmunix: esp0: State=DATA_DONE (0xa), Last State=DATA (0x9)
Sep 16 16:01:12 b34a vmunix: esp0: Cmd dump for Target 3 Lun 0:
Sep 16 16:01:12 b34a vmunix: esp0: cdb=[ 0x8 0x0 0x0 0x0 0x7e 0x0 0x0 0x0 0x0 0x0 ]
Sep 16 16:01:12 b34a vmunix: esp0: Target 3.0 reducing sync. transfer rate
Sep 16 16:01:12 b34a vmunix: sd0: SCSI transport failed: reason 'reset': retrying command
Sep 16 16:01:12 b34a vmunix: sd1: SCSI transport failed: reason 'reset': retrying command
or
Sep 16 16:36:51 b34a vmunix: sd3c: Error for command 'read'
Sep 16 16:36:51 b34a vmunix: sd3c: Error Level: Retryable
Sep 16 16:36:51 b34a vmunix: sd3c: Block 1386, Absolute Block: 1386
Sep 16 16:36:51 b34a vmunix: sd3c: Sense Key: Aborted Command
Sep 16 16:36:51 b34a vmunix: sd3c: Vendor 'MICROP' error code: 0x47
^L
SAMPLES OF SOLARIS 2.x ERROR MESSAGES
In this example internal disk 1 (target 1) is a 10 MB/sec disk:
WARNING: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000 (esp0):
SCSI bus DATA IN phase parity error
WARNING: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@1,0 (sd1):
Error for command 'read' Error Level: Retryable
Block 59640, Absolute Block: 59640
Sense Key: Aborted Command
Vendor 'SEAGATE' error code: 0x48 (<unknown extended sense code 0x48>), 0x0
or:
WARNING: /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@1,0 (sd1):
SCSI transport failed: reason 'timeout': retrying command
APPENDIX B
TABLE OF DEVICES, SYSTEMS, AND THEIR FAST-SCSI CHARACTERISTICS
SYSTEMS AND HOST ADAPTERS
Official Name SCSI Data Rate
SPARCsystem 10 fast SCSI
424 Megabyte internal Disk 5 MByte SCSI
1.05 Gigabyte internal Disk fast SCSI
SPARCstation 1 5 MByte SCSI
SPARCstation 1+ 5 MByte SCSI
SPARCstation IPC 5 MByte SCSI
SPARCstation SLC 5 MByte SCSI
SPARCstation IPX 5 MByte SCSI
SPARCstation ELC 5 MByte SCSI
SPARCstation 2 5 MByte SCSI
SPARCserver 4/330 5 MByte SCSI
SPARCserver 4/370 5 MByte SCSI
SPARCserver 4/390 5 MByte SCSI
SPARCserver 630MP presently fast SCSI
SPARCserver 670MP presently fast SCSI
SPARCserver 690MP presently fast SCSI
SBus SCSI Host Adapter 5 MByte SCSI
SBE/S Host Adapter 5 MByte SCSI
FSBE/S Host Adapter fast SCSI
DSBE/S Host Adapter differential fast SCSI
PERIPHERALS
Official Name Common Name SCSI Data Rate
Desktop Storage Pack Lunchbox
207 Megabyte Disk 5 MByte SCSI
424 Megabyte Disk 5 MByte SCSI
Sun CD ROM 5 MByte SCSI
150 Megabyte 1/4" Tape 5 MByte SCSI
Desktop Storage Module Dinnerbox
1.3 Gigabyte Disk 5 MByte SCSI
2.3 Gigabyte 8 mm Tape Drive 5 MByte SCSI
5.0 Gigabyte 8 mm Tape Drive 5 MByte SCSI
SCSI Expansion Pedestal Bullwinkle
1.3 Gigabyte Disk 5 MByte SCSI
2.3 Gigabyte 8 mm Tape Drive 5 MByte SCSI
5.0 Gigabyte 8 mm Tape Drive 5 MByte SCSI
Sun CD ROM 5 MByte SCSI
2.1 Gigabyte Disk differential fast SCSI
Differential SCSI Data Center Disk Tray Tarzan
2.1 Gigabyte Disk differential fast SCSI
Front Load Tape Drive 1/2" tape 5 MByte SCSI
External Storage Module P-Box 5 MByte SCSI
----- End Included Message -----
--59e2_1cfb-3f54_ff6-abd_31df--
----- End Included Message -----
-----------------------------------------------------------------------------
From: Roger Salisbury <rogers@ttmc.com>
The drive does not support sync 10mb/s, since this mode is faster the controller
trys this mode then falls back, you prob. also see the drive hang during this time then restart after the mesg. I haven't been in 4.x for awhile(2.x you would just set scsi-options = 0x78(no tag queuing, no fast SCSI, and no wide SCSI) in /etc/system; there is a way to disable these per controller but again this would require some kernel config.
Hope this helps!
-----------------------------------------------------------------------------
From: jsteve_s@interramp.com (Steve Shirley)
Hi Elena.
Well as for the REASON, that may be a little iffy. From my experience,
the problem is something wrong with your SCSI buss (rather obvious, I know)
which may be the disk drive, a cable, taking power hits, or other problems.
Most typically, if you are not using removable disk drives or something
like that (I do and they are a source of a great many problems), I fear
you may be having a problem with your disk drive. My first reaction would
be to make sure my backups were current and then monitor the situation.
When your bus reverts to ASYNC mode, the bus is slowing down data tranfers
to remain synchronous, from what I've been told anyway. This makes your
I/O slower.
Good luck.
-----------------------------------------------------------------------------
From: billh@dcvast.com (Bill Holzapfel)
Check your cables and terminator. My guess
would be somebody bent a pin or something.
-----------------------------------------------------------------------------
From: lsimon@pdn.paradyne.com
Some typical reasons for this problem are:
bad scsi cabling
out of spec scsi cabling
bad terminators or no terminations
a possibly bad scsi controller or CPU board
How ofter are these errors occurring?
-----------------------------------------------------------------------------
From: reguero@sunsoft.cern.ch (Ignacio Reguero)
Hi ,
These SCSI bus resets are normally provoked by a cable/terminator problem.
I does not seem to be a disk problem.
Nothing dramatic but it screws performance and it may lead to other problems.
I would just tell them to tidy up their installation and reduce SCSI cable
length.
cheers ...Ignacio...
-----------------------------------------------------------------------------
From: dsteiner@ispa.uni-osnabrueck.de (David Steiner)
Hi, Gianolio.
You posted this message to sun-managers almost a month ago. Unfortunately, about
that time we had a network connection problem and it only showed up in my
mailbox this weekend.
I am seeing the same type of messages on one of our Classics. I has been
going on for several months intermitantly, sometimes causing no problems,
sometimes causing the machine to reboot.
A couple of weeks ago, the machine when down several times with a Watchdog
reset message and then finally refused to boot at all. A technician told me
that it was the drive. We sent the drive (still under warrenty) back to our
dealer who returned it saying that the filesytem and kernel had been screwed.
He said he reformatted it and it tested out ok.
When I got the disk back, I reinstalled it and prepared to reformat and
install the OS. The machine would sometimes boot from the CD and sometimes
not but, in any case, I never managed to get through the formatting process
with out the machine either hanging or crashing with a Watchdog (Instruction
Access Error) error.
My technician still insists that it is the disk so he is sending me a
replacement to try out (I should get it today). I will let you know what
happens.
I would appreciate any info that you may have gathered from your inquiries
on this problem. (I scanned the list, but I didn't see a summary.)
Take care,
-David-
-----------------------------------------------------------------------------
GIANOLIO Elena
,,,
(o o)
---------------------------------ooO-(_)-Ooo---------------------------------
Phone : (+41 22 767) 47 51
Fax : (+41 22 767) 33 94
Beep : (internal use only) 13 + 5140
-----------------------------------------------------------------------------
CERN | E-mail
ECP div | Elena.Gianolio@cern.ch
Blg. 14-6-12 | gianolio@sunvlsi.cern.ch
1211 Geneva 23 | gianolio@cernvm.cern.ch
Switzerland /|\
-----------------------------=====oooooooooo=====----------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:31 CDT