KR20020050300A - Peer to peer interconnect diagnostics - Google Patents

Abstract

An information handling system, such as a disk drive, includes a controller that communicates with other devices in a loop and performs distributed or peer-to-peer loop error diagnosis. One example of a loop is a fiber channel connection loop (FC-AL). Distributed or peer-to-peer error diagnostics identify and diagnose errors in the upstream link in the immediate vicinity of the upstream device by monitoring the error count to determine if the error count is increasing. Increasing error count or changed loop configuration indicates that the source of the error is not an upstream device, and unchanged error count and unchanged loop configuration indicates that the source of the error is the upstream link. .

Description

Peer-to-Peer Interconnect Diagnostics {PEER TO PEER INTERCONNECT DIAGNOSTICS}

One key component of any computer system is a device for storing data. Computer systems have many other places where data can be stored. One common place for storing large amounts of data in computer systems is on disk drives. The most basic parts of a disc drive are the disc being rotated, the actuator moving the transducer to various positions on the disc, and the electrical circuitry used to write and read data to and from the disc. The disk drive also includes circuitry for encoding data so that data can be successfully retrieved and written from the disk surface. The microprocessor controls most of the operation of the disk drive as well as getting data back to the requesting computer and storing it on the disk from the requesting computer.

Representative data is stored on the surface of the storage disk. The disk drive system reads and writes information stored on tracks on a storage disk.

Fiber Channel (FC) is a serial data transmission structure standardized by ANSI. The famous FC standard is the Fiber Channel Arbitrated Loop (FC-AL). These standards form a distributed daisy-chained loop. FC provides peer to peer communication over the loop.

FC-AL is designed for new mass storage and other peripherals that require very high bandwidth. FC-AL supports the Small Computer System Interface (SCSI) command set in addition to other high level protocols. Mapping this higher level protocol to the FC is referred to as the FC-4 layer.

In FC-AL, information from an originating device may pass through a number of other devices and a link between the devices before reaching a recipient device. Passing information over multiple links adds complexity to isolating marginal and failing links that exist in point-to-point connections, and there are three ways to isolate marginal links: There is a prior art. One technique for isolating limit FC links is to use link state to isolate the offending link. The second approach uses the error-reporting feature of FC-4 mapping. The third approach combines the two methods.

The fundamental requirement for the three techniques is information about topology (ie, connection order). The phase information can be obtained from the loop position map during FC-AL forming loop initialization or by implicit means. One example of an inherent means is the exterior of a disk drive using hard addresses.

The first approach to using link state for isolation of marginal links requires a management application (MA) of at least one device on the loop. Several MAs can be implemented to compensate for the failure of anything. The MA may require an apparatus to detect link errors that periodically poll the loop or otherwise report an event during normal loop operation. In polling mode, the link state accumulated in all devices is used to locate the limit link. In the report error, the status, identification mode, accumulated from all devices reporting the error, is used to locate the limit link.

Isolating the source of an error is possible with this approach but is not guaranteed.

The use of link state makes the approach FC-4 independent. This is an advantage in multiple protocol loops. However, a drawback of using link state is polling or report error mode overhead, which reduces the efficiency of the loop.

The second approach uses the error-reporting nature of FC-4 mapping. Using the FC-4 reported error to isolate the source of the error on the loop requires keeping a log of the error. The source is located by analyzing the log to determine which device is reporting an error and which device is not.

Using FC-4 reported errors to isolate the source of the error on the loop removes the requirement for the MA to poll the loop and maintain the link error history. Not polling the loop reduces overhead on the loop. In addition, errors are only reported when they occur.

Using FC-4 reported errors to isolate the source of errors on the loop is best performed in an implementation where one master device receives all reported errors. One such implementation is a single initiator SCSI storage subsystem.

There are at least three drawbacks to relying solely on the FC-4 error condition. An error occurrence does not provide enough information to isolate the source. Moreover, states must accumulate to form a history to isolate the source of the error. Finally, in a loop that supports multiple devices receiving multiple protocols or FC-4 status, implementation becomes difficult because the errors are not reported to a common destination device.

The third technique of isolating limit FC links uses link status and FC-4 error reporting to isolate the link in question. Polling is not used and one error source isolation is possible.

Regarding the use of any link state, the MA is needed to maintain the error count of all devices. When an FC-4 error is reported or the MA detects a link error, the MA reads the accumulated link status from all devices to determine all possible error sources.

The disadvantage of an on-loop implementation with multiple FC-4s is that the MA must support all FC-4s.

Referring to FIG. 1, a diagram of a loop 100 composed of SCSI Fiber Channel Protocol (FCP) is shown. The loop includes a SCSI initiator device 110, which is used as a loop master in communication with the SCSI target devices 120, 130, and 140. The link or interconnect 150 between device 120 and device 130 is limited and / or failed.

The error detection and reporting provided by FC-4 can be used for isolation of the limit link when available.

Due to limit link 150, loop master 110 will experience command time-outs and data errors. The command timeout is the result of an error during a command, transfer ready, or response frames. These frames are discarded when they are received in error. Since the time elapsed is from frames discarded for the target, command, or from the target, transmission ready and response, the location of the bad link cannot be determined.

During a write data operation, the device 120 does not experience errors on the data from the loop master 110. However, device 120 and device 130 will detect errors caused by the limit link. Errors in the data record are reported in the FCP response.

During a data read operation, loop master 110 does not detect errors in data reads from device 130 and device 140.

What is needed is a loop error diagnostic that does not require information about the phase of the loop, which reduces loop overhead traffic and increases the efficiency of the diagnostic.

The present invention relates to the field of loop diagnostics. More particularly, the present invention relates to peer-to-peer interface diagnostics.

1 is a block diagram of a conventional loop comprised of SCSI FC channel protocol devices.

2 is an exploded view of a disk drive having a plurality of disk stacks and a ramp assembly for loading and unloading transducers on and from the surface of the disks.

3 is a process diagram of a loop error diagnosis method.

4 is a process diagram of a loop error diagnosis method.

5 is a process diagram of a method of identifying locally written error conditions on a device in a distributed daisy chained peer to peer loop.

6 is a process diagram of a method for determining, diagnosing, and resolving errors.

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

8 is a block diagram of a loop error isolation management application of a peer device.

9 is a schematic diagram of a computer system.

In a peer-to-peer approach to error source isolation, management application (MA) functionality is distributed across all devices in the loop. Link status is used for error source isolation. In more detail, each device maintains the identity and link error status of the device connected to its input, upstream device. When a device detects a link error on its input, the device makes a request to the upstream device for a link error count.

When the link status for the upstream device indicates that the device is also detecting a link error, the source of the error is different from the link on the loop. If the link status from the upstream device does not indicate that it is detecting an error, the source of the error will be an interconnect between the upstream device and the device itself. The device then causes diagnostic transfers between the upstream device and itself to confirm that the interconnect is at marginal.

The present invention regarding loop error diagnostics has the advantage that it does not require information about the complete phase of the loop. The present invention also reduces loop overhead traffic because error isolation is distributed to each device in the loop. Moreover, the efficiency of the loop diagnostics is increased because the device closest to the source of the error in question performs the diagnostics. In addition, the present invention minimizes performance degradation of each device on a loop since the diagnostic function of each device can be performed when the device is idle, whereby the diagnostic method allows the device to run during higher priority tasks. To avoid affecting its performance.

In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings which form a part hereby, in a manner exemplifying the specific embodiments in which the invention may be implemented. Other embodiments may be used and structural changes may be made without departing from the scope of the present invention.

The invention described in this application is useful for all mechanical configurations of disc drives with either rotary actuation or linear actuation. In addition, the present invention also provides for unloading transducers from the surface and parking transducers, including hard disk drives, zip drives, floppy disk drives and any other drive type. This is useful for all types of disk drives that may be required. 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 the cover 214 form a disk enclosure. An actuator assembly 220 is rotatably attached to the base 212 on an actuator shaft 218. The actuator assembly 220 includes a comb-like structure 222 having a plurality of arms 223. Load beams or load springs 224 are attached to the separate arms 223 on the comb structure 222. Load beams or load springs are also referred to as suspensions. Attached to the distal end of each load spring 224 is a slider 226 carrying a magnetic transducer 250. The slider 226 with the transducer 250 forms what is often called a head. It should be noted that many sliders have one transducer 250, as shown in the figures. As the present invention refers to sliders having one or more transducers, for example one transducer 250 is generally referred to as an MR or magneto resistive head for reading and another transducer is generally used for writing. It should also be noted that it is equally applicable. A voice coil 228 is opposite the rod spring 224 and the slider 226, at the end of the actuator arm assembly 220.

The first magnet 230 and the second magnet 231 are attached to the base 212. As shown in FIG. 2, the second magnet 231 is connected to the cover 214. The first and second magnets 230, 231 and the voice coil 228 are key components of a voice coil motor, and the voice coil motor is adapted to rotate the actuator assembly about the actuator shaft 218. Force is applied to the actuator assembly 220. In addition, a spindle motor is installed in the base 212. The spindle motor includes a rotating portion called a spindle hub 233. In this particular disk drive, the spindle motor is in the hub. In FIG. 2, a large number of disks 234 are attached to the spindle hub 233. In other disk drives, one disk or another number of disks may be attached to the hub. The invention described herein is equally applicable to a disk drive having a plurality of disks as well as a disk drive having one disk. The invention described herein is equally applicable to a disk drive with a spindle motor in or under the hub 233.

Referring next to FIG. 3, a process diagram of a method of loop error diagnostics 300 is shown. The method 300 includes a step 310 of determining the identity of the upstream device of the loop. Thereafter, the method 300 includes storing 320 the identity. In one embodiment, the determining step 310 and the storing step 320 are performed during initialization of the device. In another embodiment, the identity of upstream devices in the loop is retrieved from a loop map. Subsequently, the method 300 includes a step 330 of requesting link error counts from the upstream device of the loop. The method 300 also includes a step 340 of locally storing the link error count. Subsequently, the method 300 includes monitoring 350 the loop for errors. Thereafter, the method 300 includes a step 360 of determining an error present on the input of the device. If no error exists, the method will continue at 350. If an error exists, then a current link error count from the upstream device of the loop is required (370). The method then determines if the configuration of the loop has changed. If the configuration of the loop has changed, then the method proceeds to step 310, and if the configuration of the loop does not change, the method determines whether the current link error count has changed compared to the stored error count. The determination is then continued (385). If the current link error count has changed compared to the stored error count, it indicates that there is an error elsewhere in the loop, and the method continues with locally storing the link error count (340). If the current link error count has not changed compared to the stored error count, an error has occurred on the link between the upstream device and the device that detects the error and the method continues on a test link 390 and the error Is reported (395).

The present invention regarding loop error diagnostics does not require information about the complete topology of the loop and loop overhead traffic because error isolation is distributed to each device in the loop. Decreases. Moreover, the efficiency of the loop diagnostics is increased because the device closest to the source of the error in question performs the diagnostics. In addition, the present invention minimizes performance degradation of each device on a loop since the diagnostic function of each device can be performed when the device is idle, whereby the diagnostic method allows the device to run during higher priority tasks. To avoid affecting its performance.

Referring next to FIG. 4, a process diagram of a loop error diagnostic method 400 is shown. The method 400 includes a step 410 of identifying locally logged link error conditions on devices in a distributed daisy-chained peer-to-peer loop. The identification step is described in more detail with respect to FIG. 5 below. In one embodiment, the distributed daisy chained 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 that the device receives. The counts are stored in a Link Error Status Block (LESB). Errors that may occur at the device include link failure (e.g. loss of word synchronization for more than a specified time), loss of synchronization (e.g. loss of word synchronization for a specified time or less) Invalid transmission of more than a number of words, a running disparity error or an invalid transmission word for which invalid characters are detected, and / or an invalid cyclic redundancy check.

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

There are several methods known to those skilled in the art for obtaining the link state from the devices on the loop. One way is to use read link status (RLS) extended link service (ELS), which returns the LESB to an addressed device. In one embodiment for RLS ELS, the device supports the execution of RLS to allow the LESB for the device receiving the RLS. Another embodiment of obtaining the link state from device devices on a loop is through the use of a Small Computer System Interface (SCSI) log sense command. On that, the disk drive returns the LESB of the log page. This method is for systems with device drivers that do not convey FC ELS information to applications. Another embodiment relates to obtaining the link status from device devices on a loop enclosure services interface; will through the use of (enclosure services interface ESI), in that the disk drive is S FF Board Industry Group specification (SFF Committee industry group specification (SFF) 8067 supports formed enclosure-initiated ESI. One function provides the enclosure processor with the LESB, loop initialization count, and current status for both devices. The enclosure processor may use this information for loop management or provide it to another management entity. Another embodiment of obtaining the link status from device devices on a loop is through the use of a report device status (RPS) ELS, in which the LESB is associated with the RLS device, loop initialization count. , And the current state of the device.

A common component of each of these methods for obtaining the link from device devices on a loop is LESB.

The method 400 also includes a step 420 of diagnosing the error. The loop error diagnostic method 400 does not require information about the complete phase of the loop and reduces loop overhead traffic because error isolation is distributed to each device in the loop. Moreover, the efficiency of the loop diagnostics is increased because the device closest to the source of the error in question performs the diagnostics. In addition, since the diagnostic function of each device is enabled when the device is idle, the method 400 minimizes the degradation of the performance of each device on the loop, whereby the diagnostic method of the device during the higher priority operation. Prevents performance impact.

Referring next to FIG. 5, as in step 410 of FIG. 4, a method 500 for identifying locally recorded error conditions on a device that differs in that it is a distributed daisy chained peer to peer loop. The process diagram is shown.

The method 500 includes a step 510 of receiving a current error status count from a local source for an upstream device immediately near the distributed daisy chained peer to peer loop. The method 500 also includes a step 520 of receiving a previous error condition from a local source for the upstream device in the immediate vicinity of the distributed daisy chained peer to peer loop. In one embodiment, step 520 of receiving the previous error condition is performed during initialization of the device. In another embodiment, the step 520 of receiving a previous error state is performed before, during and / or after step 510 of receiving the current error state. Thereafter, the method 500 includes a step 530 of comparing the current error state count to a previous error state count. Subsequently, the method 500 includes a step 540 of determining that the comparison indicates an error.

Referring next to FIG. 6, a process diagram of a method 600 for determining, diagnosing, and resolving errors is shown. In method 600, decision step 540 of FIG. 5 determines that the current error state count is different from the previous error state count (610). Subsequently, in the method 600, the diagnostic step 420 of FIG. 4 includes testing 620 a link between the device and an upstream device in the immediate vicinity in a distributed daisy chained peer to peer loop. In one embodiment with respect to test step 620, the test step includes transmitting data around the loop from the device to the device via the distributed daisy chained peer-to-peer loop and sending the data to it. Determining whether the device has received or not.

If an error was determined on the upstream link, an error report is generated indicating that the error is presumed to be present in the link between the device and the upstream device in the immediate vicinity in the distributed daisy chained peer to peer loop. do. In other embodiments, the generating step 630 is performed before, during, and / or after the testing step 620.

7 is a block diagram of a peer apparatus 700 in a loop.

The apparatus 700 includes a communication input / output component 710 operatively connected with a loop 720. The device determines an error in the upstream device and / or the upstream link. In one embodiment, the loop 720 is FC-AL. The remainder of the loop 720 includes at least one other device (not shown), upstream from the peer device 700 in the loop 720. In one embodiment, the rest of the devices in the loop are peer devices 700. The communication device 710 is operatively connected to a loop error isolation management application 730. In another embodiment, the loop error isolation management application 730 performs the steps of methods 300, 400, 500, and / or 600.

The peer device 700 does not require information about the complete phase of the loop. The peer device 700 reduces loop overhead traffic because error isolation is distributed to each device in the loop. Moreover, the efficiency of the loop diagnostics is increased because the peer device 700 closest to the source of error in question performs the diagnostics. In addition, since the diagnostic function of each peer device can be performed when the peer device 700 is idle, the present invention minimizes the degradation of the performance of each device on the loop, whereby the diagnostic method is available for higher priority tasks. It is prevented from affecting the performance of the peer device 700.

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

8 is a block diagram of a loop error isolation management application (MA) 800 of a peer device, such as peer device 700. The MA 800 includes a determiner 810 of an upstream device of the loop. The determination device 800 receives identity through the communication input / output 710 of FIG. The identity is stored locally on the peer device 700 by a local store 820. The memory device 820 is operably connected to the determination device. In one embodiment, the determining device 810 includes a retriever that retrieves the identity of the upstream device from the loop map.

The MA 800 also includes a requester 830 that requests a link error count from an upstream device in the loop. The request device 830 is operatively connected to the local memory 840 of the link error count. The local memory device 840 of the link error count stores the link error count for a recent history comparison with the current link error count.

The MA 800 also includes a device 850 that requests a current link error count from the upstream device of the loop. The requesting device 850 is connected to the communication input / output 710 of FIG. The requesting device 850 receives a current count of link errors.

The MA 800 also includes an apparatus 860 for determining a configuration loop change. The determining device 860 is operatively connected to the communication input / output of FIG.

Comparator 870 compares the current link error count received from requesting device 850, the stored error count received from storage 840, and the change to the loop configuration received from decision device 860, and accordingly the link error. The device 880 or the device for generating the device error diagnosis request and the transmission device 890 are executed. In one embodiment, the requesting device 880 includes a link tester.

In one embodiment of the device 800, an initializer is operably connected to the identity determining device 810 of the upstream device in the loop and operatively connected to the local storage device 840 of the same. .

In another embodiment of apparatus 800, a loop error monitor is operably connected to local storage of link error counts. Moreover, the error detection device on the communication input of the peer device is connected to the monitor.

Components of systems 700 and 800 may be implemented as computer hardware circuitry or computer-readable programs, or a combination of both.

More specifically, in a computer-readable program embodiment of the apparatus 700, 800, the program is object oriented using an object-oriented language such as Java, Smalltalk or C ^++. The program may be configured procedurally using a procedural language such as COBOL or C. The software components can be used in a number of ways well known to those skilled in the art, for example, an application program interface (API) or remote procedure call (RPC), common object request broker architecture (CORBA). , Component Object Model (COM), Distributed Component Object Model (DCOM), Distributed System Object Model (DSOM), and Remote Method Invocation (RMI) Communicate in any of interprocess communication techniques, such as: The components run on as few computers as one, or on at least as many computers as there are components.

9 is a schematic diagram of a computer system. Advantageously, the present invention is suitable for use in computer system 2000, where computer system 2000 is on a device of a distributed daisy chained peer-to-peer loop and a communication device operably connected to an upstream device of the loop. Means for identifying a locally recorded error condition.

The computer system 2000 may also be referred to as an electronic system or information handling system and includes a central processing unit, a memory and a system bus. The information processing system includes a central processing unit 2004, a random access memory 2032, and a system bus 2030 for communicatively coupling the central processing unit 2004 and the random access memory 2032. The information processing system 2002 includes a disk drive device including the ramp described above. The information processing system 2002 also includes an input / output bus 2010 and several devices peripheral devices, such as 2012, 2014, 2016, 2018, 2020, and 2022. (2010). Peripherals may include hard disk drives, magneto optical drives, floppy disk drives, monitors, keyboards, and other such peripherals. Any type of disc drive may use a method for loading or unloading sliders on the disc surface as described above.

The present invention regarding loop error diagnostics does not require information about the phase of the loop, and reduces loop overhead traffic since error isolation is distributed to each device in the loop. Moreover, the efficiency of the loop diagnostics is increased because the device closest to the source of error in question performs the diagnostics. In addition, since the diagnostic function of each device is enabled when the device is idle, the present invention minimizes the degradation of the performance of each device on the loop, whereby the diagnostic method may affect the performance of the device during higher priority tasks. Prevent impact.

Conclusion

Finally, a method for dealing with interconnect errors includes identifying a locally logged error condition on a device of the distributed daisy chained peer to peer loop 100 (410) and diagnosing the error (420). It includes. In one embodiment, the method is performed by an apparatus such as 110, 120, 130, and / or 140. In another embodiment, the distributed daisy chained peer to peer loop comprises an FC-AL 150. In another embodiment, the device is a disk drive 200.

In another embodiment, the identifying step 310 includes receiving a current error status count from a local source for the upstream device 120 or 130 in the vicinity of the distributed daisy chained peer to peer loop 100 ( 370, receiving a previous error status count from a local source for the upstream device 120 or 130 in the immediate vicinity of the distributed daisy-chained peer-to-peer loop 150 and receiving the current error status count as in step 375. Comparing to a previous error state count, and determining 385 that the comparison indicates an error. In another embodiment, the step 370 of receiving the current error status count is performed after the step 520 of receiving the previous error status count.

In an additional embodiment, the step 330 of receiving the link error count is performed during the initialization of the device 110, 120, 130 and / or 140.

In another embodiment, the determining step 540 includes determining 610 whether the current error state count is different from a previous error state count. When the error state count is different, the upstream device also detects an error and the link between the upstream device and the device is not the source of the error.

In an additional embodiment, the diagnostic step 420 includes testing 620 a link between the device in the distributed daisy chained peer to peer loop and an upstream device in the immediate vicinity. The testing step 620 also includes transmitting data from the upstream device to the device in close proximity to the device via the distributed daisy chained peer to peer loop and the device does not receive the data when the data is transmitted. Determining a step.

In an additional embodiment, the diagnostic step 420 generates an error report indicating that the error is presumed to be in a link between the upstream device and the device in close proximity to the device in a distributed daisy chained peer-to-peer loop ( 630).

The present invention includes an information processing system 900, which comprises a communication device 710 operatively connected to an upstream device of a loop 720 and devices on a distributed daisy chained peer to peer loop. Means 730 for identifying locally recorded error conditions.

The present invention also includes a peer device 700 of loop 150, which includes a communication input 710 and a loop error isolation processing application 730 in operative communication with the communication input. One embodiment of the loop error isolation processing unit 730 of the loop includes a device 810 for determining identity of an upstream device in a loop, a local storage 820 of identity in communication with the determining device, and A device 830 for requesting a link error count from an upstream device in the loop communicating with the storage device, a local memory device 840 for a link error count communicating with the requesting device 830, and a current link from an upstream device in the loop. An apparatus 850 for requesting an error count, an apparatus 860 for determining a configuration loop change, an apparatus 870 for communicating with the determining apparatus 860 and comparing a current link error count with a stored error count, a link error count A memory device 840, a memory device 850 of the current link error count, a device 880 for resolving link errors communicating with the comparison device, and the same as the comparison device And a device 890 for transmitting a device error diagnosis request in communication with the storage device 820. In one embodiment of the device 700, the peer device 700 includes a disk drive 200 having a base and a disk rotatably attached to the base. In another embodiment, the resolution device 880 includes a link tester. In another embodiment, the device 810 for determining the identity of the upstream device of the loop comprises a device for retrieving the identity of the upstream device from the loop map. In another embodiment, the device includes an initialization device in communication with an identity determining device 810 of an upstream device in the loop and in communication with a local storage of the same.

Information processing systems, such as disk drives, include a controller in communication with other devices in a loop, and perform distributed or peer to peer loop error diagnostics. One example of a loop is a fiber channel connection loop (FC-AL). Distributed or peer-to-peer loop error diagnostics identify and diagnose errors in the upstream device at hand and in the upstream link at hand by monitoring the error count to determine whether the error count is increasing. An increasing error count or modified loop configuration indicates that the source of the error is not the upstream device, whereas an unchanging error count and an unchanged loop configuration indicate that the source of the error is the upstream link.

The foregoing description is by way of example only and does not limit the invention. Many other embodiments will be apparent to those of skill in the art upon reading the above description. Therefore, the scope of the present invention should be determined with reference to the appended claims, and the claims should be determined in accordance with the full range of equivalent patented.

Claims (10)

As a loop error diagnosis method of a distributed daisy-chained peer-to-peer loop, The method is performed by the apparatus of the distributed daisy chained peer to peer loop, the method being: (a) identifying locally written error conditions on devices in a distributed daisy chained peer to peer loop; And and (b) diagnosing the error. The method of claim 1, The identifying step (a) is: (a) (1) receiving a current error status count from a local source for an upstream device of the distributed daisy chained peer to peer loop; (a) (2) receiving a prior error status count from a local source for the upstream device of the distributed daisy chained peer to peer loop; And (a) (3) comparing the current error state count with the previous error state count. The method of claim 2, Wherein said identifying step (a) determines that said comparison indicates an error and said current error state count is selected from the group consisting of: equal to a previous error state count and not equal to a previous error state count ( a) (4) further; The diagnostic step (b) generating an error report indicating that the error is assumed to be present in a link between the device and the upstream device in a distributed daisy chained peer to peer loop. Loop error diagnosis method comprising a. The method of claim 3, wherein The diagnostic step (b) is: (b) (1) determining that the error source is assumed to be present in a link between the device and the upstream device of the distributed daisy chained peer to peer loop; And (b) (2) testing a link between the device and the upstream device of the distributed daisy chained peer-to-peer loop. The method of claim 4, wherein The test step (b) (2) is: (b) (2) (iii) transmitting data from the upstream device to the device via the distributed daisy chained peer to peer loop; And (b) (2) (ii) determining that the device did not receive the data when the data was transmitted. As a peer apparatus in a loop, Communication input; And And a loop error isolation management application operatively connected to the communication input. The method of claim 6, The loop error isolation management application: A determiner for determining the identity of the upstream device of the loop; A local store operatively connected to said determining device, said local store storing said identity; A requester requesting a link error count from said upstream device in said loop operably connected to said storage device; A local storage of the link error count, operatively connected to the requesting device; A device for requesting a current link error count from the upstream device in the loop; A device for determining configuration loop changes; A comparator for comparing a current link error count with the stored error count operatively connected with the determining device, the link error count storage device, and the current link error count storage device; A link error resolver, operatively connected to the comparison device; And And a device for transmitting a device error diagnosis request, operatively connected to said comparison device and said identity memory. The method of claim 6, The solution device comprises a link tester; The identity determining device of the upstream device of the loop comprises a retriever for retrieving the identity of the upstream device from a loop map; And And the device comprises an initializer operably connected to an identity determining device of an upstream device in the loop and operatively connected to a local storage device of the same. The method of claim 6, And the peer device further comprises a disk drive. As an information handling system, A communication device operably connected to an upstream device in the loop; And Means for identifying locally recorded error conditions on devices in a distributed daisy chained peer-to-peer loop.