Methods and arrangements to handle non-queued commands for data storage devices

Methods and arrangements to handle non-queued commands for data storage devices, such as Parallel and Serial ATA hard drives, are disclosed. Embodiments may comprise a host and/or a data storage device. The host and data storage device may form, e.g., a handheld device such as an MP3 player, a cellular phone, or the like. The storage device may comprise a new method of responding to a non-queued command while the storage device may be processing a queue of commands. In many embodiments, the method involves processing queued commands until the drive receives a non-queued command that requires immediate processing by the drive. In many of these embodiments, the drive will respond in a new manner to process the non-queued command, the end result having no or minimal impact on host system operation.

FIELD

The present invention is in the field of data storage. More particularly, the present invention relates to methods and arrangements to handle non-queued commands for data storage devices, such as devices using Native Command Queuing for a Serial Advanced Technology Architecture (SATA) hard drive.

BACKGROUND

With each passing day consumers, business people, and manufacturers continually pressure computer and chip manufacturers to produce faster computer systems. Computer makers, to a great extent, have traditionally focused on improving processor designs and increasing processor throughput. Computer makers have also increased the speed and performance of chips that work in tandem with processors on a motherboard, such as input-output bridge chips. Additionally, they have improved motherboard bus systems as evidenced by higher speed buses and bus separation, such as separating the system bus from the input-output bus. The end result being that system performance bottlenecks have been reduced. One device that computer hardware manufacturers have improved, but which improvements pale in comparison to advancements made in purely electronic components, are computer hard disk drives and data storage devices.

Hard disks, as well as other data storage devices, remain critical bottlenecks in computer systems. One of the reasons for this stems from the nature of hard drives. Hard disks are electromechanical devices. When compared with other purely electronic devices, hard drives are slower by several orders of magnitude due to their mechanical nature. For example, while the performance or response time of a chip on the motherboard may be measured in microseconds or nanoseconds, hard drive performance parameters are generally measured in terms of milliseconds. Hard drive manufacturers have responded to consumer demands of faster data storage devices and improved the performance of such devices in a variety of different ways.

One technique hard drive manufacturers have employed is increasing the rotational speeds of the device platters. For example, hard drive manufacturers have increased the speeds of drives from 5400 rotations-per-minute (RPM) to 7200 RPM and 10,000 RPM. Additionally, they have increased the amount of hard drive cache memory to sizes that are now 8 and 16 megabytes (MB). Additionally, hard drive manufacturers are starting to employ command queuing techniques more and more often. One of the advantages of storing drive commands in a queue is the ability to improve the throughput of requests by reducing rotational and seek latencies associated with the requests. Another advantage of command queuing is the improvement of drive random input-output performance. Even so, existing queued command execution techniques have numerous limitations and undesirable side effects when a command that is outside the queue needs to be executed immediately, or ahead of the queued commands.

DETAILED DESCRIPTION OF EMBODIMENTS

Generally speaking, methods and arrangements to handle command queuing and non-queued commands for a data storage device, such as a Serial ATA hard drive, are contemplated. Embodiments generally comprise a host and a data storage device. The host and data storage device may form, e.g., a desktop computer, a computer workstation, a network server, as well as a handheld and/or portable computing device such as an MP3 or portable media player, a laptop or palm-held computer, or the like. The hard drive may employ a new method for handling queued and non-queued commands that may be transferred to the drive from the host. In many embodiments, the method involves processing queued commands until the drive receives a non-queued command that requires immediate processing by the drive. In several of these embodiments, the drive will respond in a new manner that satisfies the requirements for non-queued commands, yet fits within the existing command queuing protocol framework such that hardware changes may be unnecessary for either the host or the drive. To implement the enhanced functionality, software/firmware revisions may be the only changes necessary.

For example, after a non-queued command is received from the host, the drive may respond by indicating an error. However, in addition to indicating the error, the drive may also process the command in the background. When the host requests additional error information via a log page, the drive may report that the non-queued command was successfully completed. Since any queued commands may have been flushed upon receiving the non-queued command while one or more queued commands were being processed, the host may continue by re-issuing the flushed commands.

One may note that even storage devices employing the techniques described herein may also generally reject the majority of non-queued commands issued when queued commands are outstanding. There may be several reasons for processing the non-queued commands differently. First, having non-queued commands outstanding at the same time as queued commands may complicate the protocol substantially. To avoid this complicated protocol scenario, a host may normally wait until all queued commands are completed before issuing non-queued commands. Second, storage devices may have difficulty maintaining the ordering requirements within data commands. For example, if a host program were to issue a queued write and then a non-queued read for the same Logical Block Address (LBA), the data returned for the non-queued read should include information from the uncompleted queued write. Third, error handling may be difficult. For example, a storage device may experience a failure due to receiving a non-queued command while processing queued commands, but the drive may have trouble indicating which non-queued command caused the failure if the host can continue issuing non-queued commands. Overall, one may conclude that supporting non-queued commands when queued commands are outstanding may cause problems and thus not be ideal. However, some cases may warrant immediately processing a non-queued command, such as needing to immediately process a non-queued ULOAD command to protect hardware in a system.

In light of these aforementioned issues and requirements, some embodiments comprise issuing a non-queued IDLE IMMEDIATE command to a data storage device with an UNLOAD feature specified, while queued commands are outstanding. In many embodiments, the data storage device may respond by executing the specified command and feature, as well as transmitting initial status and error information back to the host system indicating that the command failed. The data storage device may transmit this initial error indication in response to receiving the non-queued command while the device was still processing queued commands. The host may learn whether the non-queued command was successfully completed from information contained in a subsequently transmitted error log page. Such embodiments may have the advantage of providing consistent hardware architectures for both the hosts and the drives. In other words, these embodiments may provide a technique for processing non-queued commands when they may otherwise be rejected by data storage devices, or processed without communicating status information back to the hosts, in a manner that is compatible with existing command queuing protocols.

In many cases, where storage device command processing is not time-critical, the usual method may be to wait for the outstanding commands to complete. However, when command processing is time-critical, higher level software of the hosts may utilize the techniques described herein to issue particular commands to the storage devices regardless of whether the devices are processing queued commands. Additionally, in various embodiments higher level software programs that issue particular service commands, such as the UNLOAD command, may not know whether queued commands are outstanding or not. Therefore, providing a framework or system where non-queued commands may be issued regardless of having uncompleted queued commands may prove extremely beneficial.

While portions of the following detailed discussion describe embodiments with reference to specific configurations and protocols, persons of ordinary skill in the art will recognize that embodiments may be implemented with other configurations and other protocols. Additionally, while some portions of the discussion describe ATA hard drives, such as Parallel ATA and Serial ATA drives, other embodiments may easily be implemented for other drive technologies, such as digital versatile disc (DVD) drives and compact disc (CD) drives.

Turning now to the drawings,FIG. 1depicts a computing system100employing numerous data storage devices. Any and all of the data storage devices, also referred to as mass storage devices, in computing system100may employ methods and arrangements to handle queued and non-queued commands. Computing system100may comprise a processor105. Processor105may be coupled to a memory controller hub (MCH)120. Processor105may execute operating instructions, such as instructions of user applications, in memory115by interacting with MCH120. For example, MCH120may interface with memory115to receive and send operators, operands, and processing results between processor105and memory115. MCH120may also couple processor105with an input-output (I/O) controller hub (ICH)162. ICH162may allow processor105to interact with external peripheral devices, such as keyboards, scanners, and data storage devices.

In different embodiments, processor105, MCH120, and memory115may operate at relatively fast operating speeds when compared to the operating speed of the individual data storage devices. Accordingly, each storage device may improve both computing system100performance and the performance of the storage device by employing a technique referred to as command queuing. For example, one or more data storage devices within computing system100may employ such command queuing methods as Tagged Command Queuing and Native Command Queuing. [See Information technology 13 AT Attachment Packet Interface-7 (ATA/ATAPI-7), 7 Feb. 2005 ] [See Also Serial ATA Revision 2.5, 27 Oct., 2005] [See Also SCSI-3 Primary Commands (SPC) (formally ANSI X3.301-1997) International Committee for Information Technology Standards (formerly NCITS), 1 Jan. 1997] By employing command queuing, a data storage device, such as a hard drive, may accept numerous commands, place them in one or more queues, and dynamically reorder outstanding commands before executing them to reduce both rotational and seek latencies.

In some embodiments, ICH162may allow processor105to store and retrieve data from a Universal Serial Bus (USB) drive135via a Peripheral Component Interconnect (PCI) USB controller170and USB bus168. [See Universal Serial Bus Revision 2.0 specification, 21 Dec. 2000] [Also See PCI Local Bus Specification Revision 3.0, 3 Feb. 2004 ] For example, USB bus168may comprise a 33 MHz PCI bus coupled with a 480 megabits per second (Mbps) USB 2.0 PCI USB controller170, sending commands to USB drive135. In some embodiments, computing system100may comprise USB drive135employing command queuing for increased system performance. In other words, USB drive135may receive numerous commands, temporarily store them in a command queue, rearrange the command queue for increased execution efficiency, and execute the rearranged commands in the new order. Additionally, USB drive135may also receive a command from processor105, sent via MCH120and ICH162, which should be executed before any commands in the queue of USB drive135. Such commands may be alternatively referred to as non-queued commands in the various embodiments.

In addition to USB drive135, ICH162in computing system100may also control Advanced Technology Attachment (ATA) devices, such as ATA hard drives, CD drives, and DVD drives, that employ command queuing techniques. [See Information technology—AT Attachment Packet Interface-7 (ATA/ATAPI-7), 7 Feb. 2005, ] For example, ICH162may exchange information with a compact disc read only memory (CD ROM) drive178via a parallel Ultra ATA/100bus175. In alternative embodiments, parallel Ultra ATA/100bus175may comprise another bus type, such as an Ultra ATA/133IDE bus utilizing the ATA Packet Interface (ATAPI) protocol. Additionally, CD ROM drive178may vary in different embodiments. For example, in some embodiments CD ROM drive178may comprise a compact disc recordable (CD-R) drive, while in other embodiments it may comprise a CD rewritable (CD-RW) drive, a digital versatile disc (DVD) drive, a hard disk drive, or a tape drive. Information may be exchanged between the storage devices and other components in computing system100, such as processor105and memory115, using command queuing.

Similar to a parallel ATA bus and interface, computing system100may also have a Serial ATA (SATA) bus180which may couple a SATA drive, such as SATA hard drive185, to ICH162. [See Serial ATA Revision 2.5, 27 Oct. 2005] Also similar to the parallel ATA bus configuration, Serial ATA bus180may vary in bus operation speed and interface with numerous SATA devices. For example, in some embodiments Serial ATA bus180may comprise a 3.0 gigabit per second (Gbps) bus coupling SATA hard drive185to computing system100via ICH162. In other embodiments, Serial ATA bus180may comprise a 1.5 Gbps SATA bus coupling a SATA DVD+/−RW drive to ICH162.

SATA hard drive185may have Native Command Queuing (NCQ) enabled within its firmware. Additionally, SATA hard drive185may process transactional workloads and workloads within a multi-threading environment, such that processor105sends SATA hard drive185numerous commands, forming a queue of commands in memory of SATA hard drive185. As a result, SATA hard drive185may constantly analyze the commands for optimized, or altered, execution sequence, and reorder them such that SATA hard drive185may process the commands in a different order than the order they were received. For example, the SATA hard drive185may reorder the execution sequence of the commands in the queue based upon the individual command LBAs, which corresponds to location of data, or information, within the storage medium. In various embodiments, the number of queued commands may vary. For example, in some embodiments that employ NCQ, the command queue depth may be 32 commands, whereas in embodiments that employ SCSI the queue depth may be up to 256 commands.

While computing system100is operating, SATA hard drive185may be executing, or processing, a number of commands in the queue. For example, SATA hard drive may be processing six read commands, such as Read First Party Direct Memory Address (FPDMA) Queued, and two write commands, such as Write FPDMA Queued. While processing the queued commands, processor105may issue another non-queued command that requires immediate processing. For example, computing system100may comprise a laptop computer with an accelerometer, or acceleration sensor165coupled to ICH162. Such acceleration sensor165may detect when the laptop, computing system100, is being dropped and about to experience an abrupt deceleration that may damage SATA hard drive185. Accordingly, acceleration sensor165may cause ICH162to notify processor105of the impending incident, whereby processor105may respond by transmitting an “IDLE IMMEDIATE” command with an “UNLOAD” feature enabled. Once received and executed by SATA hard drive185, the unload command may cause SATA hard drive185to retract one or more internal read-write heads away from one or more internal platters to protect them from damage.

Aside from parallel and serial ATA bus configurations, computing system100may also employ other storage device bus configurations, such as a Small Computer Systems Interface (SCSI) bus190. Utilizing SCSI bus190, ICH162may interface with various data storage devices, such as a Redundant Array of Independent Disks (RAID) system195. In some embodiments, SCSI bus190may comprise a wide SCSI bus, such as a 68 pin-based bus, while in other embodiments SCSI bus190may comprise a narrow SCSI bus, such as a 50 pin-based bus. In even further embodiments, SCSI bus190may not be a SCSI bus but actually comprise a Serial ATA communication link coupled to RAID system195. As with the other bus technologies and interfaces, devices connected to computing system100may also vary in communication speed, communication technology, and format. In other words, differing embodiments may employ different SCSI bus formats and technologies, such as synchronous and asynchronous communication methods, fast, wide, Ultra, Ultra 2, and Ultra 3 SCSI formats.

While the storage devices for example embodiments depicted inFIG. 1are shown as USB, Parallel and Serial ATA, and SCSI devices, alternative embodiments may comprise storage devices employing other technologies. For example, some storage devices may couple to processor105via interface cards inserted in PCI Express® slots coupled to ICH162. Alternatively, ICH162and processor105may transfer information to and from a FireWire® hard drive for data storage and retrieval. In further embodiments, processor105may issue commands to a Network Attached Storage (NAS) drive by way of an Ethernet controller coupled to ICH162. That is to say, a FireWire® hard drive and/or a NAS drive may perform command queuing, receive a non-queued command, and properly handle the non-queued command.

While computing system100comprises a single processor105, alternative embodiments may comprise dual or multiple processors, including one or more multi-core processors. Additionally, while computing system100may utilize a single acceleration sensor165, alternative embodiments may utilize one or more alternative technology sensors, such as vibration sensors. Further embodiments may employ no sensors, but may experience certain operating conditions that require processor105to issue a non-queued command to a data storage device. Even further embodiments may have other devices coupled to computing system100sending non-queued commands to a data storage device, without involvement by processor105.

Additionally, while computing system100may comprise a laptop computer with an acceleration sensor165to cause ICH162to notify processor105of the impending incident and causing processor105to respond by transmitting an “IDLE IMMEDIATE” command with an “UNLOAD” feature enabled, other embodiments may not have such a sensor. That is to say, some embodiments may sense another type of computing system100event and cause processor105to transmit another type of command to SATA hard drive185, or another storage device. For example, computing system100may be coupled with a power sensor that detects or senses when power has been removed, or is in the process of being removed, from computing system100. Such may be the case where a computing system100battery charge is low, or an uninterruptible power supply for computing system100has been activated and is supplying backup power to computing system100. In such an alternative scenario, computing system100software and processor105may respond by transmitting a “FLUSH” command to SATA hard drive185to cause it to empty its dynamic random access memory (DRAM) to a storage medium of SATA hard drive185.

Even more, while computing system100has numerous interface and bus technologies coupling different types of data storage devices to processor105, alternative embodiments may have only single hard drives using single bus formats. Other embodiments may employ one or two different bus formats connecting only a few data storage devices to processor105. Additionally, data storage devices may couple to computing system100with varying software register interfaces, such as an Advanced Host Controller Interface (AHCI), for example. [See Serial ATA Advanced Host Controller Interface (AHCI) Revision 1.1] The actual number of different storage device and bus configurations that may comprise different embodiments is almost limitless. All such configurations may benefit from the methods and arrangements to handle command queuing disclosed in the following figure discussions.

InFIG. 2there is shown an alternative embodiment of a computer system200having a Serial ATA drive265. Computer system200has an operating system205running multiple applications,210,212,214, and216. Operating system205may be Windows®, Unix®, Linux®, Solaris®, Macintosh® OS X, or some other operating system. Applications210,212,214, and216may comprise word processors, spreadsheet programs, database applications, web browsers, multimedia programs, or a variety of other applications that may be executing simultaneously under the control of operating system205.

Operating system205may utilize a combination of software and hardware devices to send information to, and retrieve information from, Serial ATA drive265. In the embodiment shown inFIG. 2, operating system205utilizes a software driver218to communicate with an interface220. By way of example, interface220may comprise a PCI interface chip on a motherboard of computer system200. Alternatively, interface220may comprise a section of a host bus adapter coupled with an AHCI interface of computer system200.

Interface220may further interact with a transaction manager225. Transaction manager225may comprise a multiplexing module, allowing operating system205to work with a number of devices for Serial ATA drives. One such device may be a first-in-first-out (FIFO) and direct memory access (DMA) engine230, which transfers information for Serial ATA drive265. FIFO & DMA engine230may acquire data from the operating system205and memory of computer system200, store the data in a FIFO buffer, and transfer the data from the FIFO buffer to Serial ATA drive265using DMA functions. Conversely, FIFO & DMA engine230may perform similar operations in retrieving information stored in Serial ATA drive265and transferring the information to computer system200memory and operating system205.

In sending information to Serial ATA drive265, Serial ATA transport/link layer235may receive information from FIFO & DMA engine230, construct a Frame Information Structure (FIS) based on the information, and present the FIS to the link layer so that it may be transmitted to physical interface240. Conversely, in receiving information from Serial ATA drive265and transmitting it to operating system205, Serial ATA transport/link layer235may receive an FIS from physical interface240and the link layer, determine the FIS type, and transmit the FIS content to FIFO & DMA engine230so that the content may be distributed to locations required by the FIS type. Additionally, Serial ATA transport/link layer235may also report good transmission results or transmission errors back to operating system205.

Physical interface240may take the FIS content, convert it into serialized data, and work in conjunction with host analog front end245to transmit the content to device analog front end255over serial cable250. Alternately, host analog front end245and physical interface240may receive serial data transmitted from device analog front end255, reconstruct FIS content based on the transmitted analog signal, and transmit the FIS content to Serial ATA transport/link layer235. Similar to the manner in which physical interface240and host analog front end245encode and decode serial information for the operating system205on the host side, device analog front end255and physical interface260may encode and decode serial information for Serial ATA drive265.

While not shown for the sake of simplicity, an embodiment of computer system200may also have Serial ATA transport and link layers, as well as a FIFO buffer and DMA engine contained in, and performed by, an electronics controller board280of Serial ATA drive265. Such control layers and electronics may serve to store and retrieve data from a storage medium in Serial ATA drive265, similar to the fashion that data is stored and retrieved from memory for operating system205. For example, after receiving and decoding data transmitted from operating system205in electronics controller board280, such data may be stored in a storage medium of platter274. Platter274may comprise a rigid circular magnetic media that is rotated at thousands of revolutions-per-minute around a center spindle276.

Operating system205and Serial ATA drive265ofFIG. 2may employ a command queuing technique to improve the overall operation of computer system200. Command queuing may be used by computer system200, when operating system205is multi-threading or processing multi-threaded software. Since threads are generally designed to run in parallel, various commands may reach Serial ATA drive265simultaneously. To handle such multi-threading, computer system200and Serial ATA drive265may employ a form of command queuing known as Native Command Queuing (NCQ). [See Serial ATA Revision 2.5, 27 Oct. 2005] As referenced above, NCQ is a SATA command protocol allowing for increased drive performance. NCQ involves using algorithms to route hard disk heads in a more intelligent and efficient manner when numerous blocks of data need to be read or written. Stated differently, NCQ may allow Serial ATA drive265to reorder outstanding commands to reduce mechanical overhead and improve I/O latencies.

While operating system205and Serial ATA drive265ofFIG. 2may employ NCQ to improve the overall operation of computer system200, computer system200may need to override the NCQ operation by issuing a priority or immediate command that needs to be processed before the remaining commands in the queue. For example, computer system200may comprise a laptop containing Serial ATA drive265. A sensor within laptop computer system200may detect that the laptop is being dropped. Since read-write head285may be riding on a relatively thin layer of air above platter274, leaving the head positioned above platter274may allow read-write head285to damage the surface of platter274upon laptop impact.

In response to sensing such a condition, operating system205may try to protect platter274from being damaged by immediately issuing a non-queued IDLE IMMEDIATE command with the UNLOAD feature specified, to Serial ATA drive265. The operating system may be unaware of whether queued commands are outstanding but nonetheless consistently issue the non-queued UNLOAD command. If carried out immediately, the IDLE IMMEDIATE/UNLOAD command may cause Serial ATA drive265to activate an actuator and swing actuator arm272around actuator axis270until read-write head285and actuator arm272are positioned in a parking bay, or unloading spot282, away from the surface of platter274. Consequently, the data content stored within platter274may be protected.

However, since Serial ATA drive265may be processing a queue of commands and only expecting more queued commands, it may respond by initially reporting an error to operating system205. When Serial ATA drive265is processing queued commands, operating system205may not normally issue any non-queued or legacy commands. [See Serial ATA Revision 2.5, 27 Oct. 2005] In other words, operating system205may not normally mix non-queued commands with queued commands while Serial ATA drive265is processing queued commands. Serial ATA drive265may signal the error condition to the operating system205upon receiving the non-queued command, abort any outstanding queued commands, and return Serial ATA drive265to a non-queued operating mode. Unless Serial ATA drive265is properly configured to both process the non-queued command and report whether it was successfully completed, operating system205may not know how to respond to the error and protect the data stored in Serial ATA drive265. Accordingly, Serial ATA drive265may be configured to initially respond with an error, indicating the non-queued command failed, yet still attempt execution of the non-queued command. Serial ATA drive265may be further configured to communicate the actual completion status by setting one or more error and data bits in an error log page, transmitted to operating system205in response to a READ LOG EXT command issued by operating system205. Serial ATA drive265may be configured to perform theses tasks in a manner consistent with NCQ protocol requirements, requiring no hardware changes in computer system200, including Serial ATA drive265.

We turn now toFIG. 3.FIG. 3illustrates how a storage device may receive a queue of commands, start processing the queue of commands, receive a non-queued command prior to processing all of the commands in the queue, and indicate whether a non-queued command has been successfully completed or not.FIG. 3depicts a system300having a host305coupled to a data storage device350. Host305may comprise memory310coupled to a host controller315. Host305may utilize host controller315to write and read information to and from data storage device350via a serial link345. The information may include data, such as data stored in storage medium375, as well as commands and status information associated with processing those commands.

Both host305and data storage device350may support native command queuing. In other words, host305may use command register325to send numerous Read FPDMA Queued and Write FPDMA Queued commands to data storage device350over serial link345, whereupon data storage device350may store the commands in a command queue370within storage device memory365. Before sending each of the queued commands, though, host305may first verify that data storage device350is not already busy and is ready to accept a command for processing. Host305may verify that data storage device350is not busy by verifying that a BSY bit in a status register330located in host controller315is set to zero. After verifying the BSY bit is set to zero, but before sending individual native queued commands, host controller315may set individual bits of host controller SActive register340, wherein the individual bits correspond to tag values for respective queue commands.

As shown in more detail inFIG. 4A, SActive register340may comprise a 32-bit register. Host305, working in conjunction with host controller315, may set the individual bits of SActive register340by performing write operations to update SActive register340. For example, bits348,346,344, and342may correspond to tags0,1,2, and3, respectively, for queued commands that have been issued to data storage device350, stored in command queue370, and which remain uncompleted. Data storage device350processor360may have evaluated the individual commands stored in command queue370, rearranged their order for execution efficiency, and be in the process of executing them. As depicted inFIG. 3, for example, processor360may have determined that an optimal execution order for the commands is command0, command3, command1, and finally command2.

Data storage device350may proceed with processing command0, which may be for example a Read DMA Queued command, by issuing a DMA Setup FIS for tag0to host controller315. Host controller315may respond by loading the Physical Region Descriptor (PRD) pointer corresponding to tag0into DMA engine320. Data storage device350may then send a Data FIS, potentially several Data FISes, corresponding to tag0. Host controller315DMA engine320may direct the incoming data sent from data storage device350into a host memory region of memory310corresponding to the command with tag0. To complete the command0execution, data storage device350may then send a Set Device Bits FIS to host controller315. As depicted inFIG. 4B, Set Device Bits FIS450with “I” interrupt bit455and SActive register bit460for tag0set to1may indicate to host controller315that the command associated with tag0is complete. SActive register340bit348may be consequently cleared in host controller315and an interrupt may be triggered.

Data storage device350may then proceed with executing the queued command associated with tag3. At this point host305may need to issue a non-queued command that needs to be processed immediately, before the remaining queued commands. In other words, host305may need to issue a command other than Read FPDMA Queued or Write FPDMA Queued. Since NCQ may not normally support such commands while queued commands are outstanding, the non-queued command may be erred when transmitted to data storage device350, causing data storage device350to halt processing the queued commands. That is to say, to conform to the NCQ protocol, data storage device350must report an error after receiving a non-queued command when a queued command is outstanding. However, firmware355in data storage device350may be configured to respond even further in an unconventional way, causing data storage device350to execute the non-queued command, and yet provide information to host305concerning completion of the non-queued command in response to a READ LOG request such that host305may continue operating after taking appropriate actions.

Host305may place the non-queued command in command register325and issue the command to data storage device350. Upon receiving the non-queued command, data storage device350may respond with error, per protocol. More specifically, data storage device350may signal the error condition to host305by transmitting a Register FIS to host305with the ERR and ABRT bits set to one, clear the BSY bit to zero in the status field of the FIS, and halt queued command processing. Data storage device350may also attempt to execute the non-queued command.

Host305, in response to receiving the error indication, may issue a READ LOG EXT command to data storage device350. In responding to the READ LOG EXT command, or similar retrieve command, data storage device350may transmit an error log like the one shown inFIG. 5. As depicted inFIG. 5, error log page500shows that byte520may contain a single UNL bit510which may be set to one to indicate that the error condition was a result of receiving an “IDLE IMMEDIATE” command with the UNLOAD feature specified. If cleared to zero, the reason for the error may not be due to reception of an IDLE IMMEDIATE command with the UNLOAD feature specified. When set to one, however, the value of the Status field530and the Error field540in error log page500may indicate whether the unload was successful, still in progress, or unsuccessful. Completing the unload operation may take, for example, 100 milliseconds to complete. Due to this time for completion, data storage device350may still be executing it when host305issues the READ LOG EXT command. For indication of success in this case, host305may again issue the unload command. Since there may be no queue at this point, data storage device350may only indicate success upon completing or finishing the command, assuming there is no error while processing the command.

By having data storage device350report error information in this manner, host305may determine that the issued non-queued command was actually completed or in the process of being completed. Since all queued commands may have been flushed after receiving the command, host305may reissue the commands that were not processed so that data storage device350may finish processing them after the drop condition or other emergency condition has been addressed. As mentioned, this method of responding to a mix of queued and non-queued commands may have the advantage of only requiring software or firmware changes. An embodiment of a system300configured in the aforementioned manner may provide a consistent hardware architecture for both host305and data storage device350. Additionally, such a configuration may allow higher level software within host305to issue the non-queued command to data storage device350regardless of whether a queued command is outstanding not.

FIG. 6depicts a flowchart600of an embodiment of a computer system, such as the computer system inFIG. 2, wherein a host and a device are processing queued commands. Flow chart600begins with executing a number of outstanding commands in a queue by the host and the device (element610). For example, the host and device may process queued commands using Tagged Command Queuing, Native Command Queuing, or another queuing method. The host may then issue a non-queued command, such that the command is not in the format of being queued and may require immediate processing (element620).

After issuing the non-queued command by the host, the device may receive the command and indicate an error in response to receiving the non-queued command (element630). In some embodiments, the device may indicate the error after a short delay. The device may then execute the non-queued command and flush any commands that may have been in the queue (element640). After receiving the error notification from the device, the host may then transmit or issue another command back to the device, requesting more information about the error (650). For example, the command that the host issues to the device may be a “Read Log” command.

Once the device receives the new command from the host, requesting more information about the error, the device may transmit error information to the host indicating that the error was due to successfully completing the non-queued command (element660). As a result, the host may receive the error information and conclude that the device is operating properly. The host may then proceed operating normally, or the host may take some type of action in response to the error information. For example, the device may have cleared the command queue when executing the non-queued command. In this case, the host may then reissue the outstanding commands so that the device may execute them after the abnormal condition has passed.

FIG. 7depicts a flowchart700of an embodiment of a laptop, such as the computer system ofFIG. 2, interacting with a hard drive. In some embodiments, the hard drive may be a Serial ATA hard drive, while in other embodiments it may instead be a DVD drive or some other drive coupled to a Parallel ATA connecter of a computer system. Flowchart700begins with the laptop and the hard drive executing Native Command Queuing commands (element710). At a point in time when some commands are outstanding, that is they have not been completed by the hard drive, the laptop may detect that the laptop is being dropped (elements710and720). After detecting that the laptop is being dropped, the laptop may issue an “unload” command to the hard drive (element730). In different embodiments, the “unload” command may vary. For example, in some embodiments, the unload command may comprise an “idle immediate with unload” command. In other embodiments, the unload command may comprise a “park heads” command.

In response to receiving the unload command, the hard drive may report an error since the unload command is a non-queued command (element740). Responding with an error in this manner may ensure that any hardware acceleration or automation for NCQ protocol processing is not compromised. The hard drive may also unload or park the heads to protect the drive elements (element750). Upon the laptop receiving the error command from the hard drive, the laptop may issue a command to read the error log associated with the error (element760). The hard drive may respond to this read error log command by indicating that the NCQ error was due to a successfully completed, or still in progress, unload operation (element770). Processing and responding to a non-queued unload command in this manner, while the hard drive is in the process of executing a queue of commands, may allow all externally visible behavior to the hard drive to remain the same, except for the error log.

Another embodiment of the invention is implemented as a program product for use with a system to perform processes, such as the processes described in conjunction with computer system200as illustrated in FIG2. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of data media. Illustrative data media include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); and (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive). Such data media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

It will be apparent to those skilled in the art having the benefit of this disclosure that the present invention contemplates methods and arrangements for handling non-queued commands for data storage devices. It is understood that the form of the invention shown and described in the detailed description and the drawings are to be taken merely as examples. It is intended that the following claims be interpreted broadly to embrace all the variations of the embodiments disclosed.