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

Description

[0001]
(Related application)
This application is 35U. S. Claims priority of US Provisional Application Serial No. 60 / 166,805 filed Nov. 22, 2000 under C219 (e).
[0002]
(Technical field of the invention)
The present invention relates to the field of loop diagnosis. In particular, the present invention relates to peer-to-peer interface diagnostics.
[0003]
(Background of the Invention)
One important part of a computer system is a device that stores data. Computer systems have a number of different locations where data can be stored. A common place for storing large amounts of data in a computer system is on a disk drive. The most basic components of a disk drive are a rotating disk, actuators that move the transducer to various locations on the disk, and electronic circuitry used to read and write data from the disk. The disk drive also includes circuitry that encodes the data so that it can be retrieved and written successfully from the disk surface. The microprocessor controls the delivery of data to the requesting computer with most operations of the disk drive and the taking and storing of data from the requesting computer on the disk.
[0004]
Information representing data is stored on the surface of the storage disk. The disk drive system reads and writes information stored on the tracks of the storage disk.
[0005]
Fiber Channel (FC) is a serial data transfer system standardized by ANSI. The famous FC standard is Fiber Channel Arbitrated Loop (FC-AL). This standard defines a distributed daisy chain loop. FC provides peer-to-peer communication on this loop.
[0006]
FC-AL was designed for new mass storage devices and other peripheral devices that require very wide bandwidth. FC-AL supports other higher level protocols in addition to the Small Computer System Interface (SCSI) command set. The mapping of these higher level protocols to FC is called the FC-4 layer.
[0007]
In FC-AL, the information from the generating device can be passed through a plurality of other devices and links between the devices before arriving at the receiving device. While passing information on multiple links adds the complexity of isolating the limit and fault links over point-to-point connections, there are three prior art techniques for isolating the limit links. One technique for isolating marginal FC links uses link status to isolate problem links. The second method uses the error reporting function of FC-4 mapping. The third scheme is the first two combinations.
[0008]
The main 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 definition loop initialization or by implicit means. An example of an implicit means is a disk drive enclosure using hard addresses.
[0009]
The first scheme that uses link status for marginal link isolation requires a management application (MA) on 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 requests equipment reporting a link error to report an accident. In polling mode, the limit status link is searched using the status accumulated in all devices. In reporting error and identification mode, the limit link is searched using the status accumulated from all devices reporting the error.
[0010]
Although this method allows separation of a single error source, it is not always guaranteed.
[0011]
The use of link status makes this scheme FC-4 independent. This is advantageous in a multiple protocol loop. However, the disadvantage of using link status is that the polling or reporting error mode overhead reduces the efficiency of the loop.
[0012]
The second method uses the error reporting function of FC-4 mapping. When using FC-4 reporting errors to isolate error sources on the loop, it is necessary to maintain a log of errors. By analyzing the log, the error source is located to determine which devices report errors and which are not.
[0013]
Using FC-4 reporting errors to isolate error sources on the loop eliminates the need for MAs to maintain link error history and poll the loop. Without polling the loop, the loop overhead is reduced. In addition, errors are only reported when they occur.
[0014]
Using FC-4 reporting errors to isolate error sources 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.
[0015]
Relying only on the FC-4 error status has at least three drawbacks. The occurrence of a single error does not provide enough information to isolate the error source. In addition, status must be accumulated to build a history in order to isolate the error source. 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 target device.
[0016]
A third technique for isolating marginal FC links uses link status and FC-4 error reporting to isolate problem links. Polling is not used and single error sources can be isolated.
[0017]
Similar to the use of link status, an MA is required to maintain an error count for 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 possible error sources.
[0018]
A drawback of the implementation on a loop with multiple FC-4s is that the MA must support all FC-4s.
[0019]
Referring to FIG. 1, a diagram of a loop 105 that includes a SCSI Fiber Channel Protocol (FCP) device is illustrated. The loop includes a SCSI initiator device 110 operating as a loop master that communicates with the SCSI target devices 120, 130, 140. The link or interconnect 150 between device 120 and device 130 is limited and / or failed.
[0020]
Error detection and reporting provided by FC-4 may be used to isolate marginal links when available.
[0021]
Due to the limit link 150, the loop master 110 experiences command timeouts and data errors. A command timeout is the result of an error during a command, transfer ready, or response frame. These frames are discarded when received in error. Since the timeout is due to the abandoned frame to the target, the transfer ready and response from the command or the target, the location of the bad link cannot be determined.
[0022]
In a write data operation, device 120 does not experience an error on data from loop master 110. Devices 120 and 130, however, detect errors introduced by the limit link. An error for the write data is reported in the FCP response.
[0023]
In read data operations, the loop master 110 does not detect errors in the read data from the devices 130 and 140.
[0024]
What is needed is a loop error diagnosis that does not require knowledge of the topology of the loop, reducing loop overhead traffic and increasing the effectiveness of the diagnosis.
[0025]
(Summary of the Invention)
In peer-to-peer schemes that isolate error sources, management application (MA) functions are distributed across all devices on the loop. Link status is used for error source isolation. In particular, each device retains its identity, its input, and the link error status of the device connected upstream. When the device detects a link error on its input, the device initiates a request for a link error count to the upstream device.
[0026]
When the upstream device's link status indicates that the device has also detected a link error, the error source is a different link on the loop. If the link status from the upstream device does not indicate that an error has been detected, the error source will be the interconnection between the upstream device and the device itself. The device then initiates a diagnostic transfer between itself and the upstream device to verify that the interconnect is marginal.
[0027]
Advantageously, the loop error diagnosis of the present invention does not require knowledge of the complete topology of the loop. Since error isolation is distributed to each of the devices in the loop, the present invention also reduces loop overhead traffic. Furthermore, the effectiveness of the loop diagnosis increases because the device closest to the problem source performs the diagnosis. In addition, the diagnostic function of each device is energized to run when the device is idle, thus preventing diagnostics from affecting the performance of the device during high priority tasks, so that the present invention Minimize the performance degradation of each device.
[0028]
(Detailed description of preferred embodiments)
In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments for implementing the invention. 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.
[0029]
The invention described herein is useful in all mechanical configurations of disk drives that have either rotational 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 transducer unloading and transducer parking are desired from the surface. FIG. 2 is a development 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. Base 212 and cover 214 form a disk enclosure. Actuator assembly 220 is rotatably mounted on base 212 on actuator shaft 218. The actuator assembly 220 includes a comb structure 222 having a plurality of arms 223. Load beams or load springs 224 are attached to separate arms 223 on the comb 222. A load beam or load spring is also called a suspension. A slider 226 carrying the magnetic transducer 250 is attached to the end of each load spring 224. A slider 226 having a transducer 250 forms a so-called head. Note that many sliders have one transducer 250, which is what is shown in the drawing. The present invention also applies to a slider having one or more transducers, called a so-called MR or magnetoresistive head, where one transducer 250 is generally used for reading and the other is typically used for writing. It should also be noted that the same applies. There is a voice coil 228 at the end of the actuator arm assembly 220 opposite the load spring 224 and the slider 226.
[0030]
A first magnet 230 and a second magnet 231 are attached in the base 212. As shown in FIG. 2, the second magnet 231 is related to the cover 214. The first and second magnets 230 and 231 and the voice coil 228 are important components of a voice coil motor that applies a force to the actuator assembly 220 for rotation about the actuator shaft 218. The base 212 is also attached with a spindle motor. 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, a large number of disks 234 are attached to the spindle hub 233. In other disk drives, a single disk or a different number of disks are attached to the hub. The invention described herein is equally applicable to disk drives having a single disk as well as disk drives having multiple disks. The invention described herein is equally applicable to disk drives having a spindle motor that is in or under the hub 233.
[0031]
Referring now to FIG. 3, a process diagram of a loop error diagnosis method 300 is shown. The method 300 includes a step 310 of determining the identity of the upstream device in a loop. Thereafter, the method 300 includes a step 320 of storing the identity. In one embodiment, the decision step 310 and the save step 320 are performed at device initialization. In another embodiment, the identity of the upstream device of the loop is retrieved from the loop map. Thereafter, the method 300 includes a step 330 of requesting a link error count from an upstream device in the loop. The method 300 also includes storing 340 the link error count locally. Thereafter, the method 300 includes a step 350 of monitoring for errors on the loop. Thereafter, the method 300 includes a step 360 of determining whether there is an error in the input of the device. Otherwise, the method continues with operation 350. If there is an error, request 370 the current link error count from the upstream device in the loop. Thereafter, the method determines whether the loop configuration has changed. If the loop configuration has changed, the method continues with operation 310, otherwise the method continues with step 385 to determine 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 continues with operation 340 storing the link error count locally. To do. 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 test link 390 and the error is reported. 395.
[0032]
The loop error diagnosis of the present invention does not require knowledge of the complete topology of the loop and reduces loop overhead because error isolation is distributed to each of the devices in the loop. Furthermore, the effectiveness of the loop diagnosis increases because the device closest to the source of the problem performs the diagnosis. In addition, the diagnostic function of each device is activated to be executed when the device is idle, and thus the diagnostic function of each device is activated to be performed when the device is idle, and thus during a high priority task. The present invention minimizes the performance degradation of each device on the loop because it prevents diagnostics from affecting the performance of the device.
[0033]
Referring now to FIG. 4, a process diagram of a loop error diagnosis method 400 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 other embodiments, the device is a disk drive, such as disk drive 200 of FIG.
[0034]
The Fiber Channel (FC) device detects and counts errors received by the device. The count is stored in a link error status block (LESB). Errors that the device will encounter are link failure (eg loss of word synchronization over a specified time), loss of synchronization (eg loss of word synchronization below a specified time and illegal transmission of more than a specified number of words), illegal execution A parity error or illegal character is detected and / or an illegal cyclic redundancy check illegal transmission word is included.
[0035]
If any field in the LESB is increasing, the device has detected an error.
[0036]
There are several techniques known to those skilled in the art for obtaining link status from devices on a loop. One technique uses Read Link Status (RLS) Extended Link Service (ELS), which returns the LESB of the addressed device. In one embodiment of the RLS ELS, the device supports an RLS implementation that enables LESB to the device that received the RLS. Another example of obtaining link status from a device on the loop is through the use of a small computer system interface (SCSI) log sense command, whereby the disk drive returns a LESB in the log page. This technology is for systems with device drivers that do not pass FC ELS information to applications. Yet another embodiment for obtaining link status from devices on the loop is through the use of the Enclosure Service Interface (ESI), which indicates that the disk drive is compliant with SFF Committee Industry Group Specification (SFF) 8067. Supports enclosure start ESI. One function provides the enclosure processor with the LESB, loop initialization, and current status of both devices. The enclosure processor may use this information for loop management or may provide this to other management entities. Yet another embodiment for obtaining link status from a device on the loop is through the use of a reporting device status (RPS) ELS, where the RLS requesting device's LESB, loop initialization count and the current status of the device are is there.
[0037]
The common element of each of these methods for obtaining link status from devices on the loop is LESB.
[0038]
The method 400 also includes a step 420 for diagnosing errors. The loop error diagnostic method 400 does not require knowledge of the complete topology of the loop and reduces loop overhead traffic because error isolation is distributed among the devices in the loop. Furthermore, the effectiveness of the loop diagnosis increases because the device closest to the problem source performs the diagnosis. In addition, since the diagnostic function of each device is energized to be executed when the device is idle, thus preventing affecting the performance of the device during high priority tasks, the method 400 can be used for each device on the loop. Minimize performance degradation.
[0039]
Referring now to FIG. 5, a process diagram of a method 500 for identifying locally recorded error conditions on a device other than a distributed daisy chain peer-to-peer loop, such as step 410 of FIG. 4, is illustrated. .
[0040]
Method 500 includes receiving 510 a current error status count from a local source of a device immediately 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 upstream device in the distributed daisy chain peer-to-peer loop. In one embodiment, receive stage 520 is performed at device initialization. In various embodiments, the receive stage 520 is performed before, at and / or after the receive stage 510. Thereafter, the method 500 includes a step 530 of comparing the current error status count with the previous error status count. Thereafter, the method 500 includes a step 540 of determining that the comparison indicates an error.
[0041]
Referring now to FIG. 6, a process diagram of a method 600 for determining, diagnosing, and resolving errors is illustrated. In method 600, decision stage 540 of FIG. 5 determines 610 that the current error status count is different from the previous error status count. Thereafter, in the method 600, the diagnostic step 410 of FIG. 4 includes a step 620 of examining the link between the 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 includes transmitting data on the loop from the device to the device via a distributed daisy chain peer-to-peer loop, and whether the data was received by the device as transmitted. Including determining if it was not done.
[0042]
If an error is determined for the upstream link, an error report is generated indicating that the link between the device and the upstream upstream device of the distributed daisy chain peer-to-peer loop is suspected of being in error. In various embodiments, the generation stage 630 is performed before, at and / or after the inspection stage 620.
[0043]
FIG. 7 is a block diagram of the peer device 700 in a loop.
[0044]
Device 700 includes a communication input / output component 710 operably coupled to loop 720. The device determines an upstream device and / or upstream link error. In one embodiment, loop 720 is FC-AL. The remaining portion of loop 720 includes at least one other device (not shown) upstream from loop device 720 from peer device 700. In one embodiment, the other device in the loop is a peer device 700. Communication device 710 is operatively coupled to loop error isolation management application 730. In various embodiments, the loop error isolation management application 730 performs the steps of the methods 300, 400, 500, and / or 600.
[0045]
The peer device 700 does not require knowledge of the complete topology of the loop. Peer device 700 reduces loop overhead traffic because error isolation is distributed to each of the devices in the loop. Further, the effectiveness of the loop diagnosis is increased because the peer device 700 closest to the problem source performs the diagnosis. In addition, since the peer device 700 is energized to perform the diagnostic function of each peer device 700 when idle, thus preventing diagnostics from affecting the performance of the peer device 700 during high priority tasks. Minimizes the performance degradation of each device on the loop.
[0046]
In one embodiment, peer device 700 includes a disk drive, such as disk drive 200 of FIG.
[0047]
FIG. 8 is a block diagram of a loop error isolation management application (MA) 800 of a peer device such as peer device 700. MA 800 includes a determiner 810 for the identity (not shown) of the upstream device in the loop. The determiner 810 FIG. The identity is received through the communication input / output 710. The identity is stored locally in the peer device 700 by the local storage unit 820. Storage unit 820 is operatively coupled to the determiner. In one embodiment, the determiner 810 includes an upstream device identity retriever from a loop map.
[0048]
The MA 800 also includes a link error count requester 830 from the upstream device in the loop. Requester 830 is operatively coupled to a local storage 840 of link error counts. The link error count local storage unit 840 stores a link error count for subsequent history comparison with the current link error count.
[0049]
The MA 800 also includes a current link error count requester 850 from the upstream device in the loop. The requester 850 FIG. Are coupled to the communication input / output 710. Requester 850 receives the current count of link errors.
[0050]
The MA 800 also includes a configuration loop change determiner 860. The determiner 860 FIG. Is operatively coupled to the communication input / output 710 of the device.
[0051]
The comparator 870 compares the current link error count received from the requester 850, the stored error count received from the storage unit 840, and the change in the loop configuration received from the determiner 860, and accordingly, a link error resolver. Either 880 or a device error diagnostic request generator and transmitter 890 is activated. In one embodiment, requester 880 includes a link checker.
[0052]
In one embodiment of the device 800, the initializer is operably coupled to an identity determiner 810 of the upstream device of the loop and operably coupled to the local store 840 of the identity.
[0053]
Another embodiment of the apparatus 800 includes a loop error monitor operatively coupled to a local store of link error counts. In addition, a detector for errors on the communication input of the peer device is coupled to the monitor.
[0054]
The systems 700 and 800 components can be implemented as computer hardware circuits or as computer readable programs, or a combination of both.
[0055]
In particular, in the computer-readable program embodiments of devices 700 and 800, the program can be structured in an object-oriented manner using an object-oriented language such as Java, Small Talk or C ++, and the program can be a COBOL or C-like. It can be structured in a procedure-oriented manner using a procedure language. Software components include Application Program Interface (API) or Remote Procedure Call (RPC), common object request broker architecture (CORBA), Component Object Model (COM) Any of a number of means known to those skilled in the art, such as inter-process communication techniques such as Distributed Component Object Model (DCOM), Distributed System Object Model (DSOM) and Remote Method Invocation (RMI) connect. The component runs on one computer or at least a number of computers on which the component resides.
[0056]
FIG. 9 is a schematic diagram of a computer system. The present invention is advantageous in that it is suitable for use in a computer system 2000, which includes a communication device operably coupled to an upstream device in a loop and a distributed daisy chain peer-to-peer network. Identifying an error condition locally recorded on the device in a loop.
Computer system 2000, also referred to as an electronic system or information processing system, includes a central processing unit, memory, and a system bus. The information processing apparatus includes a central processing unit 2004, a random access memory 2032, and a system bus 2030 that communicatively couples the central processing unit 2004 and the random access memory 2032. The information processing system 2002 includes a disk drive device including the lamp described above. The information processing system 2002 may also include an input / output bus 2010 and a number of peripheral devices such as 2012, 2014, 2016, 2018, 2020 and 2022 attached to the input / output bus 2010. 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 onto the disk surface as described above.
[0057]
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 separation is distributed to each device in the loop. Furthermore, the effectiveness of the loop diagnosis increases because the device closest to the problem source performs the diagnosis. In addition, since the diagnostic function of each device is energized to run when the device is idle, thus preventing the diagnostic from affecting the performance of the device during high priority tasks, the present invention Minimize equipment performance degradation.
[0058]
(Conclusion)
In conclusion, in a method for managing interconnect errors, the method identifies 410 an error condition recorded locally on the device of the distributed daisy chain peer-to-peer loop 100 and diagnoses the error 420. Including. 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 includes FC-AL 150. In yet another embodiment, the device is a disk drive 200.
[0059]
In yet another embodiment, the identifying step 310 includes receiving a current error status count 370 from the local source of the upstream device 120 or 130 in the distributed daisy chain peer-to-peer loop 100; Receiving a previous error status count from the local source of the immediately upstream device 120 or 130 in the peer-to-peer loop 150; and, as in 375, the current error status count and the conventional error status count Comparing and determining 385 that the comparison indicates an error. In yet another embodiment, receive stage 370 is performed after receive stage 520.
[0060]
In another embodiment, the receiving stage 330 is performed at the initialization of the devices 110, 120, 130 and / or 140.
[0061]
In yet another embodiment, the determining step 540 includes determining 610 that the current error status count is different from the previous error status count. When the error status count is different, the upstream device also detects an error and the link between the upstream device and the device is not an error source.
[0062]
In another embodiment, the diagnostic stage 420 includes examining 630 a link between the device in the distributed daisy chain peer-to-peer loop and the upstream device. The test phase 630 also includes transmitting 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 as received. Including.
[0063]
In another embodiment, the diagnostic stage 420 generates an error report indicating that the link between the device and the upstream device in the distributed daisy chain peer-to-peer loop is suspected of having an error. Step 620 is included.
[0064]
The present invention includes a communication device 710 operably coupled to an upstream device in loop 720 and a device 730 that identifies error conditions recorded locally on the device in a distributed daisy chain peer-to-peer loop. An information processing system 900 is included.
[0065]
The present invention also includes a peer device 700 in the loop 150, which includes a communication input 710 and a loop error isolation management application 730 in operative communication with the communication input. One embodiment of the loop error isolation management application 730 includes a loop upstream device identity determiner 810, an identity local store 820 that communicates with the determiner, and a link error count from the loop upstream device that communicates with the store. Requester 830, link error count local storage 840 in communication with requester 830, current link error count requester 850 from upstream device in the loop, constituent loop change determiner 860, determiner 860 Current link error count comparator 870, link error count storage unit 840, current link error count storage unit 850, link error resolver 880 communicating with the comparator, comparator 870 communicates with the identity storage unit 820 And a transmitter 890 for error diagnosis request. In one embodiment of the apparatus 700, the peer apparatus 700 includes a disk drive 200 having a base and a disk rotatably mounted on the base. In other embodiments, the resolver 880 includes 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 apparatus includes an initializer that communicates with an identity determiner 810 of an upstream device in the loop and with a local store of identities.
[0066]
Information processing systems such as disk drives include controllers that communicate with other devices in the loop and perform distributed or peer-to-peer loop error diagnosis. An example of a loop is a fiber channel arbitrated loop. Distributed or peer-to-peer loop error diagnosis identifies and diagnoses 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 indicate that the error source is an upstream link.
[0067]
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. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are given.
[Brief description of the drawings]
FIG. 1 is a block diagram of a conventional loop including a SCSI FC channel protocol device.
FIG. 2 is a development view of a disk drive having a lamp assembly and a plurality of disk stacks for loading / unloading a converter to / from a disk surface.
FIG. 3 is a process diagram of a loop error diagnosis method.
FIG. 4 is a process diagram of a loop error diagnosis method.
FIG. 5 is a process diagram of a method for identifying locally logged error conditions in a distributed daisy chain peer-to-peer loop.
FIG. 6 is a process diagram of a method for determining, diagnosing and resolving errors.
FIG. 7 is a block diagram of a peer device in a loop that determines an upstream device and / or upstream link error.
FIG. 8 is a block diagram of a loop error isolation management application for a peer device.
FIG. 9 is a schematic diagram of a computer system.

Claims (17)

In a method of error diagnosis in a distributed daisy chain peer-to-peer loop, the method is performed by a device in a distributed daisy chain peer-to-peer loop;
(a) identifying a local error condition of the device, the identification step comprising:
(a) (1) receiving a current error status count from a local source of an upstream device in the distributed daisy chain peer-to-peer loop;
(a) (2) receiving a previous error status count from a local source of an upstream device in the distributed daisy chain peer-to-peer loop; and
(a) (3) comparing the current error status count against the previous error status count; and
(b) diagnosing the error;
For diagnosing loop errors in a distributed daisy chain peer-to-peer loop including   The method of claim 1, wherein the distributed daisy chain peer-to-peer loop comprises a Fiber Channel arbitrated loop.   The method of claim 1, wherein the method is performed by an apparatus that detects an error.   The method according to claim 1, wherein the receiving step (a) (1) is performed after the receiving step (a) (2).   5. The method according to claim 4, wherein the receiving step (a) (2) is performed during initialization of the device. The method of claim 1, further comprising:
(a) (4) determining that the comparison indicates an error;
Including methods. The method of claim 6, wherein said determining step (a) (4) comprises:
(a) (4) (i) determining whether the current error status count is equal to the previous error status count;
Including methods. The method according to claim 6, wherein the diagnostic step (b) comprises:
(b) (1) generating an error report indicating that there is an error in the link between the device in the distributed daisy chain peer-to-peer loop and the upstream device;
Including methods. The method of claim 6, wherein said determining step (a) (4) comprises:
(a) (4) (i) determining that the current error status count is not equal to the previous error status count;
Including methods. The method of claim 9, wherein the diagnosing step (b) comprises:
(b) (1) determining that there is no suspicion that there is an error source on the link between the device and the upstream device in a distributed daisy chain peer-to-peer loop;
Including methods. The method of claim 9, wherein the diagnosing step (b) comprises:
(b) (1) testing a link between the device and the upstream device in a distributed daisy chain peer-to-peer loop;
Including methods. 12. The method of claim 11, wherein the testing step (b) (1) comprises: (b) (1) (i) passing data upstream through the distributed daisy chain peer-to-peer loop. Transmitting from said device to said device; and
(b) (1) (ii ) if the data is Ru is transmitted, the step of the data to determine whether or not received by the device,
Including methods.   The method of claim 1, wherein the apparatus further comprises a disk drive. In the peer device in the loop,
Communication input,
A loop error isolation management application actively coupled to the communication input,
The loop error isolation management application
An upstream device identity determiner in the loop;
Local storage of identities actively coupled to the determiner;
A link error count requestor from an upstream device in the loop actively coupled to the memory;
Local storage of the link error count actively coupled to the requestor;
A requester of a current link error count from the upstream device of the loop;
A composition loop change determiner;
A current error link count comparator of saved error count actively connected to the determiner, a link error count store, and a store of the current link error count;
A link error resolver actively coupled to the comparator; and a device error diagnostic request transmitter actively coupled to the comparator and an identity store;
Device with.   15. The peer device of claim 14, wherein the peer device comprises a disk drive having a base and a disk rotatably attached to the base. 15. The peer device of claim 14, wherein the resolver includes a link tester;
The upstream device identity determiner of the loop includes an upstream device identity retriever from a loop map, and the device is actively coupled to an upstream device identity determiner in the loop; and An initializer actively coupled to the local store of identities;
Pier device.   15. The peer device of claim 14, wherein the peer device further comprises a disk drive.

Images