JP2003515967A - Peer-to-peer interconnect diagnostics - Google Patents

Abstract

(57) Abstract An information processing device such as a disk drive includes a controller that communicates with other devices in a loop to perform distributed or peer-to-peer loop error diagnosis. One example of a loop is a Fiber Channel arbitrated loop. Distributed or peer-to-peer loop error diagnostics identifies and diagnoses errors on the upstream device and the upstream link by monitoring the error count and determining whether the error count is increasing. An incrementing error count or changing loop configuration indicates that the error source is not an upstream device, while a constant error count and a constant loop configuration indicate that the error source is an upstream link.

Description

Detailed Description of the Invention

(Related Application) S. Claims priority to US Provisional Application Serial No. 60 / 166,805 filed November 22, 2000 under C219 (e).

TECHNICAL FIELD OF THE INVENTION The present invention relates to the field of loop diagnostics. In particular, the invention relates to peer-to-peer interface diagnostics.

BACKGROUND OF THE INVENTION One of the key components of computer systems is the device that stores data. Computer systems have many different locations where data can be stored. A common place for storing large amounts of data in computer systems is on disk drives. The most basic components of a disk drive are the spinning disk, the actuators that move the transducer to various locations on the disk, and the electronic circuits used to read and write data to the disk. The disk drive also includes circuitry to encode the data so that it can be successfully retrieved and written from the disk surface. The microprocessor, along with most operation of the disk drive, controls the passing of data to the requesting computer and the taking of data from the requesting computer and storage on disk.

Information representing the data is stored on the surface of the storage disk. Disk drive systems read and write information stored on tracks of a storage disk.

Fiber Channel (FC) is a serial data transfer system standardized by ANSI. The famous FC standard is Fiber Channel Arbitrated Loop (
Fiber Channel Arbitrated Loop, FC-AL). This standard defines a distributed daisy chain loop. FC provides peer-to-peer communication on this loop.

FC-AL was designed for new mass storage devices and other peripheral devices that require very high bandwidth. FC-AL also supports other higher level protocols in addition to the Small Computer System Interface (SCSI) command set. The mapping of these higher level protocols to FCs is called the FC-4 layer.

In FC-AL, information from a generator can be delivered to a plurality of other devices via a link between the devices before arriving at the receiver. Although passing information on multiple links adds the complexity of separating the limit and failed links over a point-to-point connection, there are three conventional techniques for separating the limit links. One technique for isolating marginal FC links uses link status to isolate problem links. The second method uses the FC-4 mapping error reporting function. The third scheme is a combination of the first two.

A key requirement of the three technologies is knowledge of topology (ie connection order). Knowledge of the topology is obtained from the loop position map at FC-AL defined loop initialization or by implicit means. An example of an implicit means is a hard drive enclosure of hard drives.

The first scheme that uses link status for marginal link separation requires a management application (MA) for at least one device on the loop. Several MAs may be implemented to cover any failure. The MA periodically polls the loop during normal loop operation or requires the device that detected the link error to report the accident. In polling mode, the cumulative status of all devices is used to look for marginal links. In reporting error, identification mode, the limit status links are searched for using the accumulated status from all devices that reported the error.

Separation of a single error source is possible, but not necessarily guaranteed, with this scheme.

The use of link status makes this scheme FC-4 independent. This is an advantage in multi-protocol loops. However, the disadvantage of using link status is that the overhead of polling or reporting error modes reduces loop efficiency.

The second method uses the error reporting function of FC-4 mapping. When using FC-4 reporting errors to isolate the error source on the loop, it is necessary to keep a log of the errors. Analyzing the log locates the error source and determines which device reports the error and which does not.

Using FC-4 reporting errors to isolate the error source on the loop eliminates the need for MA to maintain the link error history and poll the loop. Not polling the loop reduces loop overhead. Moreover, errors are only reported when they occur.

Using FC-4 reporting errors to isolate the error source on the loop works best in implementations where a single master device receives all reporting errors. An example of such an implementation is a single-initiator SCSI storage subsystem.

Relying solely on FC-4 error status has at least three drawbacks. The occurrence of a single error does not provide enough information to isolate the source of the error. In addition, the status must be accumulated to build history to isolate error sources. Finally, loops that support multiple protocols or multiple devices that receive FC-4 status are difficult to implement because errors are not reported to a common destination device.

A third technique for isolating marginal FC links uses link status and FC-4 error reporting to isolate problematic links. No polling is used and single error source isolation is possible.

Similar to the use of link status, the MA is needed to keep an error count of all error devices. When an FC-4 error is reported or the MA detects a link error, the MA reads the cumulative link status from all devices to determine the possible error source.

A drawback of implementations on loops with multiple FC-4s is that the MA must support all FC-4s.

Referring to FIG. 1, a diagram of a loop 105 including SCSI Fiber Channel Protocol (FCP) devices is illustrated. Loop is SCSI target device 1
It includes a SCSI initiator device 110 acting as a loop master in communication with 20, 130, 140. The link or interconnect 150 between device 120 and device 130 is marginal and / or broken.

Error detection and reporting provided by FC-4 may be used for marginal link isolation when available.

The limit link 150 causes the loop master 110 to experience command timeouts and data errors. Command timeouts are the result of errors on command, transfer ready, or response frames. These frames are discarded when received in error. The location of the bad link cannot be determined because the timeout results from abandoned frames to the target, commands or transfer readys and replies from the target.

In write data operations, device 120 does not experience errors on the data from loop master 110. Devices 120 and 130, however, detect the error introduced by the marginal link. The error for the write data is reported in the FCP response.

In read data operations, the loop master 110 does not detect errors in read data from the devices 130 and 140.

What is needed is loop error diagnostics that does not require knowledge of the topology of the loop, which reduces loop overhead traffic and increases diagnostic effectiveness.

SUMMARY OF THE INVENTION In a peer-to-peer method for separating error sources, a management application (MA
The function is distributed to all devices on the loop. Link status is used for error source isolation. In particular, each device holds its identity and its input, the link error status of the device connected upstream. When a device detects a link error on its input, it initiates a request for a link error count to the upstream device.

When the link status of the upstream device indicates that the device also detected a link error, the source of the error is a different link on the loop. If the link status from the upstream device does not indicate that an error is being detected, then the source of the error would be the interconnection between the upstream device and itself. The device then initiates a diagnostic transfer between itself and the upstream device to verify that the interconnection is marginal.

The loop error diagnosis of the present invention advantageously does not require knowledge of the complete topology of the loop. Since the error isolation is distributed to each of the devices in the loop,
The present invention also reduces loop overhead traffic. Moreover, the effectiveness of loop diagnostics is increased because the device closest to the source of the problem performs the diagnostics. in addition,
The present invention prevents the diagnostics from affecting the performance of the device during high priority tasks, since the diagnostics function of each device is biased to run when the device is idle. Minimize performance degradation.

Detailed Description of the Preferred Embodiments The following detailed description of the preferred embodiments forms a part of this specification and illustrates, by way of illustration, the accompanying drawings which illustrate specific embodiments for implementing the invention. refer. It should be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

The invention described herein is useful in all mechanical configurations of disk drives that have either rotary or linear drive. In addition, the present invention is also useful for all types of disk drives, including hard disk drives, zip drives, floppy disk drives, where unloading the converter and parking the converter from the surface are desirable. FIG. 2 is an exploded view of one type of disk drive 200 having a rotary actuator. The disk drive 200 includes a housing or base 212 and a cover 214. The base 212 and cover 214 form a disk enclosure. Rotatably mounted to base 212 on actuator shaft 218 is actuator assembly 220. The actuator assembly 220 includes a comb structure 2 having a plurality of arms 223.
Including 22. Load beams or load springs 224 are attached to separate arms 223 on the comb 222. The load beam or load spring is also called suspension. At the end of each load spring 224, the magnetic transducer 2
A slider 226 carrying 50 is mounted. The slider 226 with the transducer 250 forms a so-called head. Note that many sliders have one transducer 250, which is the one shown in the drawing. The invention also applies to sliders having more than one transducer, one transducer 250 being generally used for reading and the other generally being used for writing, so-called MR or magnetoresistive heads. It should be noted that it is applicable as well. At the end of the actuator arm assembly 220 facing the load spring 224 and slider 226 is a voice coil 228.

A first magnet 230 and a second magnet 231 are mounted in the base 212. As shown in FIG. 2, the second magnet 231 is associated with the cover 214. The first and second magnets 230, 231 and the voice coil 228 are important parts of the voice coil motor that applies force to the actuator assembly 220 for rotation about the actuator shaft 218. A spindle motor is also attached to the base 212.
The spindle motor includes a rotating part called a spindle hub 233. In this particular disk drive, the spindle motor is in the hub. In FIG. 2, multiple disks 234 are attached to the spindle hub 233. In other disc drives, a single disc or a different number of discs are attached to the hub. The invention described herein is equally applicable to disk drives having multiple disks as well as disk drives having a single disk. The invention described herein is equally applicable to disk drives that have a spindle motor within or below the hub 233.

Referring now to FIG. 3, a process diagram of a method 300 for loop error diagnosis is shown. The method 300 loops to determine 31 the identity of the upstream device.
Including 0. Thereafter, the method 300 includes saving the identity 320.
In one embodiment, the determining step 310 and the saving step 320 are performed during device initialization. In another embodiment, the loop upstream device's identity is retrieved from the loop map. Thereafter, method 300 includes a step 330 of requesting a link error count from an upstream device in the loop. Method 300 also includes step 340 of locally storing the link error count. Thereafter, method 300 includes a step 350 of monitoring for errors on the loop. Thereafter, the method 300 includes a step 360 of determining if there is an error in the device input. Otherwise, the method continues with operation 350. If there is an error, request 370 the current link error count from the loop upstream device. Thereafter, the method determines if the loop composition has changed.
If the loop composition has changed, the method continues with operation 310, otherwise the method continues with step 385 of determining if the current link error count has changed compared to the stored error count. . If the current link error count has changed compared to the stored error count, this indicates an error somewhere on the loop, but the method stores the link error count locally.
Continue with 40. If the current link error count has not changed compared to the stored error count, an error has occurred between the upstream device and the device that detected the error, and the method continues with the check link 390 and reports the error. 395.

The loop error diagnosis of the present invention does not require knowledge of the complete topology of the loop,
Loop overhead is reduced because error isolation is distributed to each of the devices in the loop. In addition, the effectiveness of loop diagnostics is increased because the device closest to the source of the problem performs the diagnostics. In addition, the diagnostic function of each device is activated to execute when the device is idle, and thus the diagnostic function of each device is activated to execute when the device is idle, and thus during high priority tasks. The present invention minimizes the degradation of the performance of each device on the loop, as it prevents the diagnostics from affecting the performance of the device.

Referring now to FIG. 4, a process diagram of a method 400 for loop error diagnosis is illustrated. Method 400 includes identifying 410 a link error condition recorded locally on the device in a distributed daisy chain peer-to-peer loop. This identification is described in more detail in connection with FIG. 5 below. In one embodiment, the distributed daisy chain peer-to-peer loop is a Fiber Channel Arbitrated Loop (FC-AL). In another embodiment, the device is a disk drive, such as disk drive 200 of FIG.

Fiber Channel (FC) devices detect and count errors received by the device. The count is stored in the link error status block (LESB).
The errors that may be encountered on the device are: link failure (eg loss of word sync for more than a specified time), loss of synchronization (eg loss of word sync for less than a specified time and incorrect transmission of more than a specified number of words), incorrect execution A parity error or an illegal character is detected and / or an incorrect transmission word of an incorrect cyclic redundancy check is included.

If any field in the LESB is increasing, the device has detected an error.

There are several techniques known to those skilled in the art for obtaining link status from devices on a loop. One technique uses the read link status (RLS) extended link service (ELS), which returns the LESB of the addressed device. RLS E
In one embodiment of LS, an RL that enables LESB for a device that receives the RLS.
The device supports the implementation of S. Another embodiment for obtaining link status from a device on the loop is a small computer system interface (SC
SI) via the use of the log sense command whereby the disk drive returns a LESB to the log page. This technology can be
For systems with device drivers that do not pass LS information. Yet another example of obtaining link status from a device on a loop is through the use of Enclosure Service Interface (ESI), which allows disk drives to comply with SFF Commission Industry Group Specification (SFF) 8067. Supports Enclosure Start ESI. One function is LESB of both devices
, Loop initialization, and present status to the enclosure processor. The enclosure processor may use this information for loop management or may provide this to other management entities. Yet another embodiment of obtaining link status from a device on the loop is through the use of a reporting device status (RPS) ELS, where the LESB by the RLS requesting device, the loop initialization count and the current status of the device are: is there.

The common element of each of these methods of obtaining link status from devices on the loop is the LESB.

The method 400 also includes a step 420 of diagnosing the error. The method 400 for loop error diagnosis does not require knowledge of the complete topology of the loop and reduces loop overhead traffic because the error isolation is distributed to each device in the loop. In addition, the effectiveness of loop diagnostics is increased because the device closest to the source of the problem performs the diagnostics. In addition, the method 400 of each device on the loop is prevented because the diagnostic function of each device is biased to execute when the device is idle, thus preventing it from affecting device performance during high priority tasks. Minimize performance degradation.

Referring now to FIG. 5, a distributed daisy chain chain, such as step 410 of FIG.
A process diagram of a method 500 for identifying locally recorded error conditions on a device other than a peer-to-peer loop is illustrated.

Method 500 includes receiving 510 a current error status count from a local source of a device directly upstream of a distributed daisy chain peer-to-peer loop.
Method 500 also includes receiving 520 a previous error status count from a local source of the device directly upstream of the distributed daisy chain peer-to-peer loop. In one embodiment, the receiving step 520 is performed during device initialization. In various embodiments, receiving stage 520 is performed before, at and / or after receiving stage 510. Thereafter, method 500 includes comparing 530 the current error status count to the previous error status count. The method 500 then includes a step 540 of determining that the comparison indicates an error.

Referring now to FIG. 6, a process diagram of a method 600 for determining, diagnosing and resolving errors is illustrated. In method 600, decision step 540 of FIG. 5 determines 610 that the current error status count is different than the previous error status count. Thereafter, in method 600, diagnostic stage 410 of FIG. 4 includes stage 620 of examining the link between the immediate upstream device and the device in a distributed daisy chain peer-to-peer loop. In one embodiment of the test phase 620, the test phase involves sending data on the loop from the device to the device through a distributed daisy chain peer-to-peer loop and whether the data was received by the device as it was sent. Includes determining if not done.

If an error is determined on the upstream link, an error report is generated indicating that the link between the device and the immediate upstream device of the distributed daisy chain peer-to-peer loop is suspected to be in error. It In various embodiments, the generating step 630 is performed before, during, and / or after the testing step 620.

[0043]   FIG. 7 is a block diagram of a peer device 700 in a loop.

Device 700 includes communication input / output component 710 operably coupled to loop 720.
The device determines errors in upstream devices and / or upstream links. In one embodiment,
Loop 720 is FC-AL. The rest of the loop 720 is the peer device 7
00 to at least one other device (not shown) upstream of the loop 720. In one embodiment, the other device in the loop is the peer device 700. Communication device 71
0 is operatively coupled to the loop error isolation management application 730.
In various embodiments, the loop error isolation management application 730 may use the method 300.
, 400, 500 and / or 600 steps.

The peer device 700 does not require knowledge of the complete topology of the loop. The peer device 700 reduces loop overhead traffic because the error isolation is distributed to each of the devices in the loop. In addition, the peer device 7 closest to the source of the problem
00 performs diagnostics, increasing the effectiveness of loop diagnostics. In addition, the peer device 700 is biased to perform the diagnostic function of each peer device 700 when idle, thus preventing the diagnostics from affecting the performance of the peer device 700 during high priority tasks. Minimizes the performance degradation of each device on the loop.

In one embodiment, peer device 700 includes a disk drive, such as disk drive 200 of FIG.

FIG. 8 is a block diagram of a loop error isolation management application (MA) 800 for a peer device, such as peer device 700. The MA 800 includes a determiner 810 of the upstream device's identity (not shown) in the loop. The determiner 810 is shown in FIG.
00 through communication input / output 710. The identity is stored locally on peer device 700 by local storage 820. Storage unit 8
20 is operatively coupled to the determiner. In one embodiment, the determiner 810 includes a searcher for upstream device identities from the loop map.

The MA 800 requests the link error count from the upstream device in the loop 830.
Also includes. Requester 830 is operatively coupled to a local store of link error count 840. The link error count local storage unit 840 stores the link error count for subsequent history comparison with the current link error count.

The MA 800 also includes a current link error count requester 850 from the upstream device in the loop. Requester 850 is coupled to communication input / output 710 of FIG.
Requester 850 receives the current count of link errors.

The MA 800 also includes a configuration loop change determiner 860. The determiner 860 is shown in FIG.
00 communication input / output 710.

Comparator 870 compares the current link error count received from requester 850 with
Compare the stored error count received from the storage unit 840 with the loop configuration change received from the determiner 860 and activate either the link error resolver 880 or the device error diagnostic request generator and transmitter 890 accordingly. To do. In one embodiment, requester 880 includes a link checker.

In one embodiment of the device 800, the initializer is operatively coupled to the identity determiner 810 of the device upstream of the loop, and the local identity store 840.
Operatively coupled to.

Another embodiment of apparatus 800 includes a loop error monitor operatively coupled to a local store of link error counts. Further, a detector of errors on the communication input of the peer device is coupled to the monitor.

The systems 700 and 800 components can be implemented as computer hardware circuitry or as a computer readable program, or a combination of both.

In particular, in computer readable program embodiments of devices 700 and 800,
The program can be structured object-oriented using an object-oriented language such as Java, SmallTalk or C ++, and the program is COBO
It can be procedure-oriented and structured using a procedure language such as L or C. The software component may be an application program interface (API) or remote procedure call (R.P.I.).
P. C. ), Common object request broker architecture (CORBA), component object model (COM), distributed component object model (DCOM), distributed system object model (DSOM)
Communication) and any of a number of means known to those skilled in the art such as interprocess communication techniques such as remote method invocation (RMI). The components execute on one computer, or on at least a number of computers on which the components reside.

FIG. 9 is a schematic diagram of a computer system. Advantageously, the present invention is suitable for use in computer system 2000, which comprises a communication device operatively coupled to an upstream device in a loop and a distributed daisy chain peer-to-peer. A device for identifying error conditions recorded locally on the device in a loop. Computer system 2000, also referred to as an electronic or information handling system, includes a central processing unit, memory and system bus. The information processing device
Central processing unit 2004, random access memory 2032, and central processing unit 2
System bus 20 for communicatively coupling 004 and random access memory 2032.
Including 30. The information processing system 2002 includes a disk drive device including the above-mentioned lamp. The information processing system 2002 also includes an input / output bus 2010 and 2012, 2014, 2016, 2018 attached to the input / output bus 2010.
It may also include some peripheral devices such as 2020 and 2022. Peripheral devices include hard disk drives, magneto-optical devices, floppy disk drives, monitors, keyboards and other such peripheral devices. Any type of disk drive may use the method of loading and unloading the slider on the disk surface as described above.

The present invention of loop error diagnosis does not require knowledge of the topology of the loop and reduces loop overhead traffic because the loop isolation is distributed to each of the devices in the loop. In addition, the effectiveness of loop diagnostics is increased because the device closest to the source of the problem performs the diagnostics. In addition, since the diagnostics function of each device is biased to execute when the device is idle, thus preventing the diagnostics from affecting the performance of the device during high priority tasks, the present invention provides Minimize degradation of equipment performance.

Conclusion In conclusion, in a method of managing interconnection errors, the method identifies 410 an error condition recorded locally on a device of a distributed daisy chain peer-to-peer loop 100, Diagnosing the error 420. In one embodiment, the method is performed by a device such as 110, 120, 130 and / or 140. In another embodiment, the distributed daisy chain peer-to-peer loop comprises FC-AL150. In yet another embodiment, the device is a disk drive 20.
It is 0.

In yet another embodiment, the identifying step 310 is a distributed daisy chain peer-to-peer loop 100, step 370 of receiving a current error status count from a local source of the upstream device 120 or 130, Distributed daisy chain
As in steps 330 and 375 of receiving a previous error status count from the local source of the upstream device 120 or 130 in the peer-to-peer loop 150,
It includes comparing the current error status count with a conventional error status count and determining 385 that the comparison indicates an error.
In yet another embodiment, receive stage 370 is performed after receive stage 520.

In another embodiment, the receiving step 330 is performed during initialization of the devices 110, 120, 130 and / or 140.

In yet another embodiment, the determining step 540 determines 61 that the current error status count is different from the previous error status count.
Including 0. When the error status counts are different, the upstream device also detects the error and the link between the upstream device and the device is not the source of the error.

In another embodiment, the diagnostic stage 420 includes a stage 630 of examining the link between the device and the immediate upstream device in the distributed daisy chain peer-to-peer loop. The checking step 630 also includes sending data from the upstream device to the device via a distributed daisy chain peer-to-peer loop and determining that the data was not received by the device as it was sent. Including.

In another embodiment, the diagnostic stage 420 is an error report indicating that the link between the device and the immediate upstream device in the distributed daisy chain peer-to-peer loop is suspected to be in error. Generating step 620.

The present invention is a communication device 710 operatively coupled to an upstream device in a loop 720 and a device for identifying error conditions recorded locally on the device in a distributed daisy-chain peer-to-peer loop. 730 and an information processing system 900 including.

The present invention also includes in peer 150 a peer device 700, which is a communication input 7.
Loop error isolation management application 73 operatively communicating with 10 and communication inputs
Including 0 and. One embodiment of the loop error isolation management application 730 is a loop upstream device identity determiner 810, an identity local store 820 in communication with the determiner, a link error count from the loop upstream device in communication with the store. Requester 830, a local store 840 of the link error count in communication with the requester 830, a requester 850 of the current link error count from an upstream device in the loop, a determiner 860 of the configuration loop change, a determiner 860. Current link error count comparator 870 for stored error count in communication with, link error count storage 840, current link error count storage 850
A link error resolver 880 in communication with the comparator, a comparator 870 and a device error diagnostic request transmitter 890 in communication with the identity store 820. In one embodiment of device 700, pier device 700 includes a disc drive 200 having a base and a disc rotatably mounted to the base. In another embodiment, the resolver 880 comprises a link checker. In yet another embodiment, the upstream device identity determiner 810 in the loop includes an upstream device identity retriever from the loop map. In yet another embodiment, the device includes an initializer in communication with the identity determiner 810 of the upstream device in the loop and with the local store of identity.

Information handling systems, such as disk drives, include controllers that communicate with other devices in the loop to perform distributed or peer-to-peer loop error diagnostics.
An example of a loop is a Fiber Channel Arbitrated Loop. Distributed or peer-to-peer loop error diagnostics identify and diagnose errors in the upstream device and the upstream link by monitoring the error count to determine if the error count is increasing. An increased error count or changed loop configuration indicates that the error source is not an upstream device, while an invariant error count and invariant loop configuration indicates that the error source is an upstream link.

It should be understood that the above description is illustrative and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Therefore, the scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[Brief description of drawings]

1 is a block diagram of a conventional loop including a SCSI FC channel protocol device.

FIG. 2 is an exploded view of a disk drive having a plurality of disk stacks and a ramp assembly for loading / unloading the converter on the disk surface.

[Figure 3]   The process figure of the method of a loop error diagnosis.

[Figure 4]   The process figure of the method of a loop error diagnosis.

FIG. 5 is a process diagram of a method for identifying locally recorded error conditions in a distributed daisy chain peer-to-peer loop.

[Figure 6]   A process diagram of how to determine, diagnose, and resolve errors.

FIG. 7 is a block diagram of a peer device in a loop that determines errors in upstream devices and / or upstream links.

[Figure 8]   FIG. 6 is a block diagram of a loop error isolation management application for a peer device.

[Figure 9]   1 is a schematic diagram of a computer system.

[Procedure for Amendment] Submission for translation of Article 34 Amendment of Patent Cooperation Treaty

[Submission date] June 14, 2001 (2001.6.14)

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be amended] Claims

[Correction method] Change

[Contents of correction]

[Claims]

─────────────────────────────────────────────────── ─── Continued front page    F-term (reference) 5B065 BA01 CE00 EC01                 5K031 AA08 EA01 EA12

Claims (10)

[Claims] 1. A method of loop error diagnosis in a distributed daisy chain peer-to-peer loop, comprising: (a) a distributed daisy chain peer-to-peer loop executed by a device in the distributed daisy chain peer-to-peer loop. A method of loop error diagnosis in a distributed daisy chain peer-to-peer loop, comprising: identifying error conditions recorded locally on the devices in the loop; and (b) diagnosing the error. 2. The method of claim 1, wherein the identifying step (a) comprises: (a) (1) obtaining a current error status count from a local source of an upstream device in a distributed daisy chain peer-to-peer loop. Receiving, (a) (2) receiving a previous error status count from a local source of an upstream device in a distributed daisy chain peer-to-peer loop, and (a) (3) previous error status. Comparing the current error status count against the count. 3. The method of claim 2, wherein the identifying step (a) is such that (a) (4) the comparison indicates an error and the current error status count is equal to the previous error status count. And a diagnostic step (b) (1) in which the error is distributed daisy chain peer-to-peer. A method comprising generating an error report indicating that the link between the device and the upstream device in the loop is suspected. 4. The method according to claim 3, wherein the diagnostic step (b) comprises: (b) (1) a link between the device and an upstream device in which the error source is a distributed daisy chain peer-to-peer loop. And (b) (2) inspecting the link between the device and the upstream device in the distributed daisy-chain peer-to-peer loop. . 5. The method of claim 4, wherein the testing step (b) (2) comprises: (b) (2) (i) upstream device to said device via a distributed daisy chain peer-to-peer loop. Transmitting the data, and (b) (2) (ii) determining that the data was not received by the device as transmitted. 6. In a peer device in a loop,   Communication input,   A loop error isolation management application operatively coupled to the communication input, Peer device including. 7. The peer device of claim 6, wherein the loop error isolation management application comprises a determiner of the identity of the upstream device in the loop and a local store of identity operatively coupled to the determiner. A requester for the link error count from the upstream device in the loop operatively coupled to the store, and a local store for the link error count operatively coupled to the requestor, A current link error count requester from an upstream device, a configuration loop change determiner, and a determiner, a link error count store, a current link error count store Compare current link error count to stored error count comparator and link error solver operatively coupled to the comparator, A peer device that includes a transmitter of the device error diagnostic request operably coupled to the container and an identity store. 8. The peer device of claim 6, wherein the resolver comprises a link checker, the upstream device identity determiner in the loop comprises an upstream device identity retriever from the loop map, and the peer A peer device, wherein the device includes an initializer operably coupled to an identity determiner of an upstream device in the loop and operably coupled to a local store of identity. 9. The peer device of claim 6, wherein the peer device further comprises a disk drive. 10. An information processing system for identifying a communication device operably coupled to an upstream device in a loop and an error condition locally recorded in a device in a distributed daisy chain peer-to-peer loop. And an information processing device including.