Based on kernel version 4.10.8. Page generated on 2017-04-01 14:43 EST.
1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> 4 5 <book id="libataDevGuide"> 6 <bookinfo> 7 <title>libATA Developer's Guide</title> 8 9 <authorgroup> 10 <author> 11 <firstname>Jeff</firstname> 12 <surname>Garzik</surname> 13 </author> 14 </authorgroup> 15 16 <copyright> 17 <year>2003-2006</year> 18 <holder>Jeff Garzik</holder> 19 </copyright> 20 21 <legalnotice> 22 <para> 23 The contents of this file are subject to the Open 24 Software License version 1.1 that can be found at 25 <ulink url="http://fedoraproject.org/wiki/Licensing:OSL1.1">http://fedoraproject.org/wiki/Licensing:OSL1.1</ulink> 26 and is included herein by reference. 27 </para> 28 29 <para> 30 Alternatively, the contents of this file may be used under the terms 31 of the GNU General Public License version 2 (the "GPL") as distributed 32 in the kernel source COPYING file, in which case the provisions of 33 the GPL are applicable instead of the above. If you wish to allow 34 the use of your version of this file only under the terms of the 35 GPL and not to allow others to use your version of this file under 36 the OSL, indicate your decision by deleting the provisions above and 37 replace them with the notice and other provisions required by the GPL. 38 If you do not delete the provisions above, a recipient may use your 39 version of this file under either the OSL or the GPL. 40 </para> 41 42 </legalnotice> 43 </bookinfo> 44 45 <toc></toc> 46 47 <chapter id="libataIntroduction"> 48 <title>Introduction</title> 49 <para> 50 libATA is a library used inside the Linux kernel to support ATA host 51 controllers and devices. libATA provides an ATA driver API, class 52 transports for ATA and ATAPI devices, and SCSI<->ATA translation 53 for ATA devices according to the T10 SAT specification. 54 </para> 55 <para> 56 This Guide documents the libATA driver API, library functions, library 57 internals, and a couple sample ATA low-level drivers. 58 </para> 59 </chapter> 60 61 <chapter id="libataDriverApi"> 62 <title>libata Driver API</title> 63 <para> 64 struct ata_port_operations is defined for every low-level libata 65 hardware driver, and it controls how the low-level driver 66 interfaces with the ATA and SCSI layers. 67 </para> 68 <para> 69 FIS-based drivers will hook into the system with ->qc_prep() and 70 ->qc_issue() high-level hooks. Hardware which behaves in a manner 71 similar to PCI IDE hardware may utilize several generic helpers, 72 defining at a bare minimum the bus I/O addresses of the ATA shadow 73 register blocks. 74 </para> 75 <sect1> 76 <title>struct ata_port_operations</title> 77 78 <sect2><title>Disable ATA port</title> 79 <programlisting> 80 void (*port_disable) (struct ata_port *); 81 </programlisting> 82 83 <para> 84 Called from ata_bus_probe() error path, as well as when 85 unregistering from the SCSI module (rmmod, hot unplug). 86 This function should do whatever needs to be done to take the 87 port out of use. In most cases, ata_port_disable() can be used 88 as this hook. 89 </para> 90 <para> 91 Called from ata_bus_probe() on a failed probe. 92 Called from ata_scsi_release(). 93 </para> 94 95 </sect2> 96 97 <sect2><title>Post-IDENTIFY device configuration</title> 98 <programlisting> 99 void (*dev_config) (struct ata_port *, struct ata_device *); 100 </programlisting> 101 102 <para> 103 Called after IDENTIFY [PACKET] DEVICE is issued to each device 104 found. Typically used to apply device-specific fixups prior to 105 issue of SET FEATURES - XFER MODE, and prior to operation. 106 </para> 107 <para> 108 This entry may be specified as NULL in ata_port_operations. 109 </para> 110 111 </sect2> 112 113 <sect2><title>Set PIO/DMA mode</title> 114 <programlisting> 115 void (*set_piomode) (struct ata_port *, struct ata_device *); 116 void (*set_dmamode) (struct ata_port *, struct ata_device *); 117 void (*post_set_mode) (struct ata_port *); 118 unsigned int (*mode_filter) (struct ata_port *, struct ata_device *, unsigned int); 119 </programlisting> 120 121 <para> 122 Hooks called prior to the issue of SET FEATURES - XFER MODE 123 command. The optional ->mode_filter() hook is called when libata 124 has built a mask of the possible modes. This is passed to the 125 ->mode_filter() function which should return a mask of valid modes 126 after filtering those unsuitable due to hardware limits. It is not 127 valid to use this interface to add modes. 128 </para> 129 <para> 130 dev->pio_mode and dev->dma_mode are guaranteed to be valid when 131 ->set_piomode() and when ->set_dmamode() is called. The timings for 132 any other drive sharing the cable will also be valid at this point. 133 That is the library records the decisions for the modes of each 134 drive on a channel before it attempts to set any of them. 135 </para> 136 <para> 137 ->post_set_mode() is 138 called unconditionally, after the SET FEATURES - XFER MODE 139 command completes successfully. 140 </para> 141 142 <para> 143 ->set_piomode() is always called (if present), but 144 ->set_dma_mode() is only called if DMA is possible. 145 </para> 146 147 </sect2> 148 149 <sect2><title>Taskfile read/write</title> 150 <programlisting> 151 void (*sff_tf_load) (struct ata_port *ap, struct ata_taskfile *tf); 152 void (*sff_tf_read) (struct ata_port *ap, struct ata_taskfile *tf); 153 </programlisting> 154 155 <para> 156 ->tf_load() is called to load the given taskfile into hardware 157 registers / DMA buffers. ->tf_read() is called to read the 158 hardware registers / DMA buffers, to obtain the current set of 159 taskfile register values. 160 Most drivers for taskfile-based hardware (PIO or MMIO) use 161 ata_sff_tf_load() and ata_sff_tf_read() for these hooks. 162 </para> 163 164 </sect2> 165 166 <sect2><title>PIO data read/write</title> 167 <programlisting> 168 void (*sff_data_xfer) (struct ata_device *, unsigned char *, unsigned int, int); 169 </programlisting> 170 171 <para> 172 All bmdma-style drivers must implement this hook. This is the low-level 173 operation that actually copies the data bytes during a PIO data 174 transfer. 175 Typically the driver will choose one of ata_sff_data_xfer_noirq(), 176 ata_sff_data_xfer(), or ata_sff_data_xfer32(). 177 </para> 178 179 </sect2> 180 181 <sect2><title>ATA command execute</title> 182 <programlisting> 183 void (*sff_exec_command)(struct ata_port *ap, struct ata_taskfile *tf); 184 </programlisting> 185 186 <para> 187 causes an ATA command, previously loaded with 188 ->tf_load(), to be initiated in hardware. 189 Most drivers for taskfile-based hardware use ata_sff_exec_command() 190 for this hook. 191 </para> 192 193 </sect2> 194 195 <sect2><title>Per-cmd ATAPI DMA capabilities filter</title> 196 <programlisting> 197 int (*check_atapi_dma) (struct ata_queued_cmd *qc); 198 </programlisting> 199 200 <para> 201 Allow low-level driver to filter ATA PACKET commands, returning a status 202 indicating whether or not it is OK to use DMA for the supplied PACKET 203 command. 204 </para> 205 <para> 206 This hook may be specified as NULL, in which case libata will 207 assume that atapi dma can be supported. 208 </para> 209 210 </sect2> 211 212 <sect2><title>Read specific ATA shadow registers</title> 213 <programlisting> 214 u8 (*sff_check_status)(struct ata_port *ap); 215 u8 (*sff_check_altstatus)(struct ata_port *ap); 216 </programlisting> 217 218 <para> 219 Reads the Status/AltStatus ATA shadow register from 220 hardware. On some hardware, reading the Status register has 221 the side effect of clearing the interrupt condition. 222 Most drivers for taskfile-based hardware use 223 ata_sff_check_status() for this hook. 224 </para> 225 226 </sect2> 227 228 <sect2><title>Write specific ATA shadow register</title> 229 <programlisting> 230 void (*sff_set_devctl)(struct ata_port *ap, u8 ctl); 231 </programlisting> 232 233 <para> 234 Write the device control ATA shadow register to the hardware. 235 Most drivers don't need to define this. 236 </para> 237 238 </sect2> 239 240 <sect2><title>Select ATA device on bus</title> 241 <programlisting> 242 void (*sff_dev_select)(struct ata_port *ap, unsigned int device); 243 </programlisting> 244 245 <para> 246 Issues the low-level hardware command(s) that causes one of N 247 hardware devices to be considered 'selected' (active and 248 available for use) on the ATA bus. This generally has no 249 meaning on FIS-based devices. 250 </para> 251 <para> 252 Most drivers for taskfile-based hardware use 253 ata_sff_dev_select() for this hook. 254 </para> 255 256 </sect2> 257 258 <sect2><title>Private tuning method</title> 259 <programlisting> 260 void (*set_mode) (struct ata_port *ap); 261 </programlisting> 262 263 <para> 264 By default libata performs drive and controller tuning in 265 accordance with the ATA timing rules and also applies blacklists 266 and cable limits. Some controllers need special handling and have 267 custom tuning rules, typically raid controllers that use ATA 268 commands but do not actually do drive timing. 269 </para> 270 271 <warning> 272 <para> 273 This hook should not be used to replace the standard controller 274 tuning logic when a controller has quirks. Replacing the default 275 tuning logic in that case would bypass handling for drive and 276 bridge quirks that may be important to data reliability. If a 277 controller needs to filter the mode selection it should use the 278 mode_filter hook instead. 279 </para> 280 </warning> 281 282 </sect2> 283 284 <sect2><title>Control PCI IDE BMDMA engine</title> 285 <programlisting> 286 void (*bmdma_setup) (struct ata_queued_cmd *qc); 287 void (*bmdma_start) (struct ata_queued_cmd *qc); 288 void (*bmdma_stop) (struct ata_port *ap); 289 u8 (*bmdma_status) (struct ata_port *ap); 290 </programlisting> 291 292 <para> 293 When setting up an IDE BMDMA transaction, these hooks arm 294 (->bmdma_setup), fire (->bmdma_start), and halt (->bmdma_stop) 295 the hardware's DMA engine. ->bmdma_status is used to read the standard 296 PCI IDE DMA Status register. 297 </para> 298 299 <para> 300 These hooks are typically either no-ops, or simply not implemented, in 301 FIS-based drivers. 302 </para> 303 <para> 304 Most legacy IDE drivers use ata_bmdma_setup() for the bmdma_setup() 305 hook. ata_bmdma_setup() will write the pointer to the PRD table to 306 the IDE PRD Table Address register, enable DMA in the DMA Command 307 register, and call exec_command() to begin the transfer. 308 </para> 309 <para> 310 Most legacy IDE drivers use ata_bmdma_start() for the bmdma_start() 311 hook. ata_bmdma_start() will write the ATA_DMA_START flag to the DMA 312 Command register. 313 </para> 314 <para> 315 Many legacy IDE drivers use ata_bmdma_stop() for the bmdma_stop() 316 hook. ata_bmdma_stop() clears the ATA_DMA_START flag in the DMA 317 command register. 318 </para> 319 <para> 320 Many legacy IDE drivers use ata_bmdma_status() as the bmdma_status() hook. 321 </para> 322 323 </sect2> 324 325 <sect2><title>High-level taskfile hooks</title> 326 <programlisting> 327 void (*qc_prep) (struct ata_queued_cmd *qc); 328 int (*qc_issue) (struct ata_queued_cmd *qc); 329 </programlisting> 330 331 <para> 332 Higher-level hooks, these two hooks can potentially supercede 333 several of the above taskfile/DMA engine hooks. ->qc_prep is 334 called after the buffers have been DMA-mapped, and is typically 335 used to populate the hardware's DMA scatter-gather table. 336 Most drivers use the standard ata_qc_prep() helper function, but 337 more advanced drivers roll their own. 338 </para> 339 <para> 340 ->qc_issue is used to make a command active, once the hardware 341 and S/G tables have been prepared. IDE BMDMA drivers use the 342 helper function ata_qc_issue_prot() for taskfile protocol-based 343 dispatch. More advanced drivers implement their own ->qc_issue. 344 </para> 345 <para> 346 ata_qc_issue_prot() calls ->tf_load(), ->bmdma_setup(), and 347 ->bmdma_start() as necessary to initiate a transfer. 348 </para> 349 350 </sect2> 351 352 <sect2><title>Exception and probe handling (EH)</title> 353 <programlisting> 354 void (*eng_timeout) (struct ata_port *ap); 355 void (*phy_reset) (struct ata_port *ap); 356 </programlisting> 357 358 <para> 359 Deprecated. Use ->error_handler() instead. 360 </para> 361 362 <programlisting> 363 void (*freeze) (struct ata_port *ap); 364 void (*thaw) (struct ata_port *ap); 365 </programlisting> 366 367 <para> 368 ata_port_freeze() is called when HSM violations or some other 369 condition disrupts normal operation of the port. A frozen port 370 is not allowed to perform any operation until the port is 371 thawed, which usually follows a successful reset. 372 </para> 373 374 <para> 375 The optional ->freeze() callback can be used for freezing the port 376 hardware-wise (e.g. mask interrupt and stop DMA engine). If a 377 port cannot be frozen hardware-wise, the interrupt handler 378 must ack and clear interrupts unconditionally while the port 379 is frozen. 380 </para> 381 <para> 382 The optional ->thaw() callback is called to perform the opposite of ->freeze(): 383 prepare the port for normal operation once again. Unmask interrupts, 384 start DMA engine, etc. 385 </para> 386 387 <programlisting> 388 void (*error_handler) (struct ata_port *ap); 389 </programlisting> 390 391 <para> 392 ->error_handler() is a driver's hook into probe, hotplug, and recovery 393 and other exceptional conditions. The primary responsibility of an 394 implementation is to call ata_do_eh() or ata_bmdma_drive_eh() with a set 395 of EH hooks as arguments: 396 </para> 397 398 <para> 399 'prereset' hook (may be NULL) is called during an EH reset, before any other actions 400 are taken. 401 </para> 402 403 <para> 404 'postreset' hook (may be NULL) is called after the EH reset is performed. Based on 405 existing conditions, severity of the problem, and hardware capabilities, 406 </para> 407 408 <para> 409 Either 'softreset' (may be NULL) or 'hardreset' (may be NULL) will be 410 called to perform the low-level EH reset. 411 </para> 412 413 <programlisting> 414 void (*post_internal_cmd) (struct ata_queued_cmd *qc); 415 </programlisting> 416 417 <para> 418 Perform any hardware-specific actions necessary to finish processing 419 after executing a probe-time or EH-time command via ata_exec_internal(). 420 </para> 421 422 </sect2> 423 424 <sect2><title>Hardware interrupt handling</title> 425 <programlisting> 426 irqreturn_t (*irq_handler)(int, void *, struct pt_regs *); 427 void (*irq_clear) (struct ata_port *); 428 </programlisting> 429 430 <para> 431 ->irq_handler is the interrupt handling routine registered with 432 the system, by libata. ->irq_clear is called during probe just 433 before the interrupt handler is registered, to be sure hardware 434 is quiet. 435 </para> 436 <para> 437 The second argument, dev_instance, should be cast to a pointer 438 to struct ata_host_set. 439 </para> 440 <para> 441 Most legacy IDE drivers use ata_sff_interrupt() for the 442 irq_handler hook, which scans all ports in the host_set, 443 determines which queued command was active (if any), and calls 444 ata_sff_host_intr(ap,qc). 445 </para> 446 <para> 447 Most legacy IDE drivers use ata_sff_irq_clear() for the 448 irq_clear() hook, which simply clears the interrupt and error 449 flags in the DMA status register. 450 </para> 451 452 </sect2> 453 454 <sect2><title>SATA phy read/write</title> 455 <programlisting> 456 int (*scr_read) (struct ata_port *ap, unsigned int sc_reg, 457 u32 *val); 458 int (*scr_write) (struct ata_port *ap, unsigned int sc_reg, 459 u32 val); 460 </programlisting> 461 462 <para> 463 Read and write standard SATA phy registers. Currently only used 464 if ->phy_reset hook called the sata_phy_reset() helper function. 465 sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE. 466 </para> 467 468 </sect2> 469 470 <sect2><title>Init and shutdown</title> 471 <programlisting> 472 int (*port_start) (struct ata_port *ap); 473 void (*port_stop) (struct ata_port *ap); 474 void (*host_stop) (struct ata_host_set *host_set); 475 </programlisting> 476 477 <para> 478 ->port_start() is called just after the data structures for each 479 port are initialized. Typically this is used to alloc per-port 480 DMA buffers / tables / rings, enable DMA engines, and similar 481 tasks. Some drivers also use this entry point as a chance to 482 allocate driver-private memory for ap->private_data. 483 </para> 484 <para> 485 Many drivers use ata_port_start() as this hook or call 486 it from their own port_start() hooks. ata_port_start() 487 allocates space for a legacy IDE PRD table and returns. 488 </para> 489 <para> 490 ->port_stop() is called after ->host_stop(). Its sole function 491 is to release DMA/memory resources, now that they are no longer 492 actively being used. Many drivers also free driver-private 493 data from port at this time. 494 </para> 495 <para> 496 ->host_stop() is called after all ->port_stop() calls 497 have completed. The hook must finalize hardware shutdown, release DMA 498 and other resources, etc. 499 This hook may be specified as NULL, in which case it is not called. 500 </para> 501 502 </sect2> 503 504 </sect1> 505 </chapter> 506 507 <chapter id="libataEH"> 508 <title>Error handling</title> 509 510 <para> 511 This chapter describes how errors are handled under libata. 512 Readers are advised to read SCSI EH 513 (Documentation/scsi/scsi_eh.txt) and ATA exceptions doc first. 514 </para> 515 516 <sect1><title>Origins of commands</title> 517 <para> 518 In libata, a command is represented with struct ata_queued_cmd 519 or qc. qc's are preallocated during port initialization and 520 repetitively used for command executions. Currently only one 521 qc is allocated per port but yet-to-be-merged NCQ branch 522 allocates one for each tag and maps each qc to NCQ tag 1-to-1. 523 </para> 524 <para> 525 libata commands can originate from two sources - libata itself 526 and SCSI midlayer. libata internal commands are used for 527 initialization and error handling. All normal blk requests 528 and commands for SCSI emulation are passed as SCSI commands 529 through queuecommand callback of SCSI host template. 530 </para> 531 </sect1> 532 533 <sect1><title>How commands are issued</title> 534 535 <variablelist> 536 537 <varlistentry><term>Internal commands</term> 538 <listitem> 539 <para> 540 First, qc is allocated and initialized using 541 ata_qc_new_init(). Although ata_qc_new_init() doesn't 542 implement any wait or retry mechanism when qc is not 543 available, internal commands are currently issued only during 544 initialization and error recovery, so no other command is 545 active and allocation is guaranteed to succeed. 546 </para> 547 <para> 548 Once allocated qc's taskfile is initialized for the command to 549 be executed. qc currently has two mechanisms to notify 550 completion. One is via qc->complete_fn() callback and the 551 other is completion qc->waiting. qc->complete_fn() callback 552 is the asynchronous path used by normal SCSI translated 553 commands and qc->waiting is the synchronous (issuer sleeps in 554 process context) path used by internal commands. 555 </para> 556 <para> 557 Once initialization is complete, host_set lock is acquired 558 and the qc is issued. 559 </para> 560 </listitem> 561 </varlistentry> 562 563 <varlistentry><term>SCSI commands</term> 564 <listitem> 565 <para> 566 All libata drivers use ata_scsi_queuecmd() as 567 hostt->queuecommand callback. scmds can either be simulated 568 or translated. No qc is involved in processing a simulated 569 scmd. The result is computed right away and the scmd is 570 completed. 571 </para> 572 <para> 573 For a translated scmd, ata_qc_new_init() is invoked to 574 allocate a qc and the scmd is translated into the qc. SCSI 575 midlayer's completion notification function pointer is stored 576 into qc->scsidone. 577 </para> 578 <para> 579 qc->complete_fn() callback is used for completion 580 notification. ATA commands use ata_scsi_qc_complete() while 581 ATAPI commands use atapi_qc_complete(). Both functions end up 582 calling qc->scsidone to notify upper layer when the qc is 583 finished. After translation is completed, the qc is issued 584 with ata_qc_issue(). 585 </para> 586 <para> 587 Note that SCSI midlayer invokes hostt->queuecommand while 588 holding host_set lock, so all above occur while holding 589 host_set lock. 590 </para> 591 </listitem> 592 </varlistentry> 593 594 </variablelist> 595 </sect1> 596 597 <sect1><title>How commands are processed</title> 598 <para> 599 Depending on which protocol and which controller are used, 600 commands are processed differently. For the purpose of 601 discussion, a controller which uses taskfile interface and all 602 standard callbacks is assumed. 603 </para> 604 <para> 605 Currently 6 ATA command protocols are used. They can be 606 sorted into the following four categories according to how 607 they are processed. 608 </para> 609 610 <variablelist> 611 <varlistentry><term>ATA NO DATA or DMA</term> 612 <listitem> 613 <para> 614 ATA_PROT_NODATA and ATA_PROT_DMA fall into this category. 615 These types of commands don't require any software 616 intervention once issued. Device will raise interrupt on 617 completion. 618 </para> 619 </listitem> 620 </varlistentry> 621 622 <varlistentry><term>ATA PIO</term> 623 <listitem> 624 <para> 625 ATA_PROT_PIO is in this category. libata currently 626 implements PIO with polling. ATA_NIEN bit is set to turn 627 off interrupt and pio_task on ata_wq performs polling and 628 IO. 629 </para> 630 </listitem> 631 </varlistentry> 632 633 <varlistentry><term>ATAPI NODATA or DMA</term> 634 <listitem> 635 <para> 636 ATA_PROT_ATAPI_NODATA and ATA_PROT_ATAPI_DMA are in this 637 category. packet_task is used to poll BSY bit after 638 issuing PACKET command. Once BSY is turned off by the 639 device, packet_task transfers CDB and hands off processing 640 to interrupt handler. 641 </para> 642 </listitem> 643 </varlistentry> 644 645 <varlistentry><term>ATAPI PIO</term> 646 <listitem> 647 <para> 648 ATA_PROT_ATAPI is in this category. ATA_NIEN bit is set 649 and, as in ATAPI NODATA or DMA, packet_task submits cdb. 650 However, after submitting cdb, further processing (data 651 transfer) is handed off to pio_task. 652 </para> 653 </listitem> 654 </varlistentry> 655 </variablelist> 656 </sect1> 657 658 <sect1><title>How commands are completed</title> 659 <para> 660 Once issued, all qc's are either completed with 661 ata_qc_complete() or time out. For commands which are handled 662 by interrupts, ata_host_intr() invokes ata_qc_complete(), and, 663 for PIO tasks, pio_task invokes ata_qc_complete(). In error 664 cases, packet_task may also complete commands. 665 </para> 666 <para> 667 ata_qc_complete() does the following. 668 </para> 669 670 <orderedlist> 671 672 <listitem> 673 <para> 674 DMA memory is unmapped. 675 </para> 676 </listitem> 677 678 <listitem> 679 <para> 680 ATA_QCFLAG_ACTIVE is cleared from qc->flags. 681 </para> 682 </listitem> 683 684 <listitem> 685 <para> 686 qc->complete_fn() callback is invoked. If the return value of 687 the callback is not zero. Completion is short circuited and 688 ata_qc_complete() returns. 689 </para> 690 </listitem> 691 692 <listitem> 693 <para> 694 __ata_qc_complete() is called, which does 695 <orderedlist> 696 697 <listitem> 698 <para> 699 qc->flags is cleared to zero. 700 </para> 701 </listitem> 702 703 <listitem> 704 <para> 705 ap->active_tag and qc->tag are poisoned. 706 </para> 707 </listitem> 708 709 <listitem> 710 <para> 711 qc->waiting is cleared & completed (in that order). 712 </para> 713 </listitem> 714 715 <listitem> 716 <para> 717 qc is deallocated by clearing appropriate bit in ap->qactive. 718 </para> 719 </listitem> 720 721 </orderedlist> 722 </para> 723 </listitem> 724 725 </orderedlist> 726 727 <para> 728 So, it basically notifies upper layer and deallocates qc. One 729 exception is short-circuit path in #3 which is used by 730 atapi_qc_complete(). 731 </para> 732 <para> 733 For all non-ATAPI commands, whether it fails or not, almost 734 the same code path is taken and very little error handling 735 takes place. A qc is completed with success status if it 736 succeeded, with failed status otherwise. 737 </para> 738 <para> 739 However, failed ATAPI commands require more handling as 740 REQUEST SENSE is needed to acquire sense data. If an ATAPI 741 command fails, ata_qc_complete() is invoked with error status, 742 which in turn invokes atapi_qc_complete() via 743 qc->complete_fn() callback. 744 </para> 745 <para> 746 This makes atapi_qc_complete() set scmd->result to 747 SAM_STAT_CHECK_CONDITION, complete the scmd and return 1. As 748 the sense data is empty but scmd->result is CHECK CONDITION, 749 SCSI midlayer will invoke EH for the scmd, and returning 1 750 makes ata_qc_complete() to return without deallocating the qc. 751 This leads us to ata_scsi_error() with partially completed qc. 752 </para> 753 754 </sect1> 755 756 <sect1><title>ata_scsi_error()</title> 757 <para> 758 ata_scsi_error() is the current transportt->eh_strategy_handler() 759 for libata. As discussed above, this will be entered in two 760 cases - timeout and ATAPI error completion. This function 761 calls low level libata driver's eng_timeout() callback, the 762 standard callback for which is ata_eng_timeout(). It checks 763 if a qc is active and calls ata_qc_timeout() on the qc if so. 764 Actual error handling occurs in ata_qc_timeout(). 765 </para> 766 <para> 767 If EH is invoked for timeout, ata_qc_timeout() stops BMDMA and 768 completes the qc. Note that as we're currently in EH, we 769 cannot call scsi_done. As described in SCSI EH doc, a 770 recovered scmd should be either retried with 771 scsi_queue_insert() or finished with scsi_finish_command(). 772 Here, we override qc->scsidone with scsi_finish_command() and 773 calls ata_qc_complete(). 774 </para> 775 <para> 776 If EH is invoked due to a failed ATAPI qc, the qc here is 777 completed but not deallocated. The purpose of this 778 half-completion is to use the qc as place holder to make EH 779 code reach this place. This is a bit hackish, but it works. 780 </para> 781 <para> 782 Once control reaches here, the qc is deallocated by invoking 783 __ata_qc_complete() explicitly. Then, internal qc for REQUEST 784 SENSE is issued. Once sense data is acquired, scmd is 785 finished by directly invoking scsi_finish_command() on the 786 scmd. Note that as we already have completed and deallocated 787 the qc which was associated with the scmd, we don't need 788 to/cannot call ata_qc_complete() again. 789 </para> 790 791 </sect1> 792 793 <sect1><title>Problems with the current EH</title> 794 795 <itemizedlist> 796 797 <listitem> 798 <para> 799 Error representation is too crude. Currently any and all 800 error conditions are represented with ATA STATUS and ERROR 801 registers. Errors which aren't ATA device errors are treated 802 as ATA device errors by setting ATA_ERR bit. Better error 803 descriptor which can properly represent ATA and other 804 errors/exceptions is needed. 805 </para> 806 </listitem> 807 808 <listitem> 809 <para> 810 When handling timeouts, no action is taken to make device 811 forget about the timed out command and ready for new commands. 812 </para> 813 </listitem> 814 815 <listitem> 816 <para> 817 EH handling via ata_scsi_error() is not properly protected 818 from usual command processing. On EH entrance, the device is 819 not in quiescent state. Timed out commands may succeed or 820 fail any time. pio_task and atapi_task may still be running. 821 </para> 822 </listitem> 823 824 <listitem> 825 <para> 826 Too weak error recovery. Devices / controllers causing HSM 827 mismatch errors and other errors quite often require reset to 828 return to known state. Also, advanced error handling is 829 necessary to support features like NCQ and hotplug. 830 </para> 831 </listitem> 832 833 <listitem> 834 <para> 835 ATA errors are directly handled in the interrupt handler and 836 PIO errors in pio_task. This is problematic for advanced 837 error handling for the following reasons. 838 </para> 839 <para> 840 First, advanced error handling often requires context and 841 internal qc execution. 842 </para> 843 <para> 844 Second, even a simple failure (say, CRC error) needs 845 information gathering and could trigger complex error handling 846 (say, resetting & reconfiguring). Having multiple code 847 paths to gather information, enter EH and trigger actions 848 makes life painful. 849 </para> 850 <para> 851 Third, scattered EH code makes implementing low level drivers 852 difficult. Low level drivers override libata callbacks. If 853 EH is scattered over several places, each affected callbacks 854 should perform its part of error handling. This can be error 855 prone and painful. 856 </para> 857 </listitem> 858 859 </itemizedlist> 860 </sect1> 861 </chapter> 862 863 <chapter id="libataExt"> 864 <title>libata Library</title> 865 !Edrivers/ata/libata-core.c 866 </chapter> 867 868 <chapter id="libataInt"> 869 <title>libata Core Internals</title> 870 !Idrivers/ata/libata-core.c 871 </chapter> 872 873 <chapter id="libataScsiInt"> 874 <title>libata SCSI translation/emulation</title> 875 !Edrivers/ata/libata-scsi.c 876 !Idrivers/ata/libata-scsi.c 877 </chapter> 878 879 <chapter id="ataExceptions"> 880 <title>ATA errors and exceptions</title> 881 882 <para> 883 This chapter tries to identify what error/exception conditions exist 884 for ATA/ATAPI devices and describe how they should be handled in 885 implementation-neutral way. 886 </para> 887 888 <para> 889 The term 'error' is used to describe conditions where either an 890 explicit error condition is reported from device or a command has 891 timed out. 892 </para> 893 894 <para> 895 The term 'exception' is either used to describe exceptional 896 conditions which are not errors (say, power or hotplug events), or 897 to describe both errors and non-error exceptional conditions. Where 898 explicit distinction between error and exception is necessary, the 899 term 'non-error exception' is used. 900 </para> 901 902 <sect1 id="excat"> 903 <title>Exception categories</title> 904 <para> 905 Exceptions are described primarily with respect to legacy 906 taskfile + bus master IDE interface. If a controller provides 907 other better mechanism for error reporting, mapping those into 908 categories described below shouldn't be difficult. 909 </para> 910 911 <para> 912 In the following sections, two recovery actions - reset and 913 reconfiguring transport - are mentioned. These are described 914 further in <xref linkend="exrec"/>. 915 </para> 916 917 <sect2 id="excatHSMviolation"> 918 <title>HSM violation</title> 919 <para> 920 This error is indicated when STATUS value doesn't match HSM 921 requirement during issuing or execution any ATA/ATAPI command. 922 </para> 923 924 <itemizedlist> 925 <title>Examples</title> 926 927 <listitem> 928 <para> 929 ATA_STATUS doesn't contain !BSY && DRDY && !DRQ while trying 930 to issue a command. 931 </para> 932 </listitem> 933 934 <listitem> 935 <para> 936 !BSY && !DRQ during PIO data transfer. 937 </para> 938 </listitem> 939 940 <listitem> 941 <para> 942 DRQ on command completion. 943 </para> 944 </listitem> 945 946 <listitem> 947 <para> 948 !BSY && ERR after CDB transfer starts but before the 949 last byte of CDB is transferred. ATA/ATAPI standard states 950 that "The device shall not terminate the PACKET command 951 with an error before the last byte of the command packet has 952 been written" in the error outputs description of PACKET 953 command and the state diagram doesn't include such 954 transitions. 955 </para> 956 </listitem> 957 958 </itemizedlist> 959 960 <para> 961 In these cases, HSM is violated and not much information 962 regarding the error can be acquired from STATUS or ERROR 963 register. IOW, this error can be anything - driver bug, 964 faulty device, controller and/or cable. 965 </para> 966 967 <para> 968 As HSM is violated, reset is necessary to restore known state. 969 Reconfiguring transport for lower speed might be helpful too 970 as transmission errors sometimes cause this kind of errors. 971 </para> 972 </sect2> 973 974 <sect2 id="excatDevErr"> 975 <title>ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION)</title> 976 977 <para> 978 These are errors detected and reported by ATA/ATAPI devices 979 indicating device problems. For this type of errors, STATUS 980 and ERROR register values are valid and describe error 981 condition. Note that some of ATA bus errors are detected by 982 ATA/ATAPI devices and reported using the same mechanism as 983 device errors. Those cases are described later in this 984 section. 985 </para> 986 987 <para> 988 For ATA commands, this type of errors are indicated by !BSY 989 && ERR during command execution and on completion. 990 </para> 991 992 <para>For ATAPI commands,</para> 993 994 <itemizedlist> 995 996 <listitem> 997 <para> 998 !BSY && ERR && ABRT right after issuing PACKET 999 indicates that PACKET command is not supported and falls in 1000 this category. 1001 </para> 1002 </listitem> 1003 1004 <listitem> 1005 <para> 1006 !BSY && ERR(==CHK) && !ABRT after the last 1007 byte of CDB is transferred indicates CHECK CONDITION and 1008 doesn't fall in this category. 1009 </para> 1010 </listitem> 1011 1012 <listitem> 1013 <para> 1014 !BSY && ERR(==CHK) && ABRT after the last byte 1015 of CDB is transferred *probably* indicates CHECK CONDITION and 1016 doesn't fall in this category. 1017 </para> 1018 </listitem> 1019 1020 </itemizedlist> 1021 1022 <para> 1023 Of errors detected as above, the followings are not ATA/ATAPI 1024 device errors but ATA bus errors and should be handled 1025 according to <xref linkend="excatATAbusErr"/>. 1026 </para> 1027 1028 <variablelist> 1029 1030 <varlistentry> 1031 <term>CRC error during data transfer</term> 1032 <listitem> 1033 <para> 1034 This is indicated by ICRC bit in the ERROR register and 1035 means that corruption occurred during data transfer. Up to 1036 ATA/ATAPI-7, the standard specifies that this bit is only 1037 applicable to UDMA transfers but ATA/ATAPI-8 draft revision 1038 1f says that the bit may be applicable to multiword DMA and 1039 PIO. 1040 </para> 1041 </listitem> 1042 </varlistentry> 1043 1044 <varlistentry> 1045 <term>ABRT error during data transfer or on completion</term> 1046 <listitem> 1047 <para> 1048 Up to ATA/ATAPI-7, the standard specifies that ABRT could be 1049 set on ICRC errors and on cases where a device is not able 1050 to complete a command. Combined with the fact that MWDMA 1051 and PIO transfer errors aren't allowed to use ICRC bit up to 1052 ATA/ATAPI-7, it seems to imply that ABRT bit alone could 1053 indicate transfer errors. 1054 </para> 1055 <para> 1056 However, ATA/ATAPI-8 draft revision 1f removes the part 1057 that ICRC errors can turn on ABRT. So, this is kind of 1058 gray area. Some heuristics are needed here. 1059 </para> 1060 </listitem> 1061 </varlistentry> 1062 1063 </variablelist> 1064 1065 <para> 1066 ATA/ATAPI device errors can be further categorized as follows. 1067 </para> 1068 1069 <variablelist> 1070 1071 <varlistentry> 1072 <term>Media errors</term> 1073 <listitem> 1074 <para> 1075 This is indicated by UNC bit in the ERROR register. ATA 1076 devices reports UNC error only after certain number of 1077 retries cannot recover the data, so there's nothing much 1078 else to do other than notifying upper layer. 1079 </para> 1080 <para> 1081 READ and WRITE commands report CHS or LBA of the first 1082 failed sector but ATA/ATAPI standard specifies that the 1083 amount of transferred data on error completion is 1084 indeterminate, so we cannot assume that sectors preceding 1085 the failed sector have been transferred and thus cannot 1086 complete those sectors successfully as SCSI does. 1087 </para> 1088 </listitem> 1089 </varlistentry> 1090 1091 <varlistentry> 1092 <term>Media changed / media change requested error</term> 1093 <listitem> 1094 <para> 1095 <<TODO: fill here>> 1096 </para> 1097 </listitem> 1098 </varlistentry> 1099 1100 <varlistentry><term>Address error</term> 1101 <listitem> 1102 <para> 1103 This is indicated by IDNF bit in the ERROR register. 1104 Report to upper layer. 1105 </para> 1106 </listitem> 1107 </varlistentry> 1108 1109 <varlistentry><term>Other errors</term> 1110 <listitem> 1111 <para> 1112 This can be invalid command or parameter indicated by ABRT 1113 ERROR bit or some other error condition. Note that ABRT 1114 bit can indicate a lot of things including ICRC and Address 1115 errors. Heuristics needed. 1116 </para> 1117 </listitem> 1118 </varlistentry> 1119 1120 </variablelist> 1121 1122 <para> 1123 Depending on commands, not all STATUS/ERROR bits are 1124 applicable. These non-applicable bits are marked with 1125 "na" in the output descriptions but up to ATA/ATAPI-7 1126 no definition of "na" can be found. However, 1127 ATA/ATAPI-8 draft revision 1f describes "N/A" as 1128 follows. 1129 </para> 1130 1131 <blockquote> 1132 <variablelist> 1133 <varlistentry><term>3.2.3.3a N/A</term> 1134 <listitem> 1135 <para> 1136 A keyword the indicates a field has no defined value in 1137 this standard and should not be checked by the host or 1138 device. N/A fields should be cleared to zero. 1139 </para> 1140 </listitem> 1141 </varlistentry> 1142 </variablelist> 1143 </blockquote> 1144 1145 <para> 1146 So, it seems reasonable to assume that "na" bits are 1147 cleared to zero by devices and thus need no explicit masking. 1148 </para> 1149 1150 </sect2> 1151 1152 <sect2 id="excatATAPIcc"> 1153 <title>ATAPI device CHECK CONDITION</title> 1154 1155 <para> 1156 ATAPI device CHECK CONDITION error is indicated by set CHK bit 1157 (ERR bit) in the STATUS register after the last byte of CDB is 1158 transferred for a PACKET command. For this kind of errors, 1159 sense data should be acquired to gather information regarding 1160 the errors. REQUEST SENSE packet command should be used to 1161 acquire sense data. 1162 </para> 1163 1164 <para> 1165 Once sense data is acquired, this type of errors can be 1166 handled similarly to other SCSI errors. Note that sense data 1167 may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR 1168 && ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such 1169 cases, the error should be considered as an ATA bus error and 1170 handled according to <xref linkend="excatATAbusErr"/>. 1171 </para> 1172 1173 </sect2> 1174 1175 <sect2 id="excatNCQerr"> 1176 <title>ATA device error (NCQ)</title> 1177 1178 <para> 1179 NCQ command error is indicated by cleared BSY and set ERR bit 1180 during NCQ command phase (one or more NCQ commands 1181 outstanding). Although STATUS and ERROR registers will 1182 contain valid values describing the error, READ LOG EXT is 1183 required to clear the error condition, determine which command 1184 has failed and acquire more information. 1185 </para> 1186 1187 <para> 1188 READ LOG EXT Log Page 10h reports which tag has failed and 1189 taskfile register values describing the error. With this 1190 information the failed command can be handled as a normal ATA 1191 command error as in <xref linkend="excatDevErr"/> and all 1192 other in-flight commands must be retried. Note that this 1193 retry should not be counted - it's likely that commands 1194 retried this way would have completed normally if it were not 1195 for the failed command. 1196 </para> 1197 1198 <para> 1199 Note that ATA bus errors can be reported as ATA device NCQ 1200 errors. This should be handled as described in <xref 1201 linkend="excatATAbusErr"/>. 1202 </para> 1203 1204 <para> 1205 If READ LOG EXT Log Page 10h fails or reports NQ, we're 1206 thoroughly screwed. This condition should be treated 1207 according to <xref linkend="excatHSMviolation"/>. 1208 </para> 1209 1210 </sect2> 1211 1212 <sect2 id="excatATAbusErr"> 1213 <title>ATA bus error</title> 1214 1215 <para> 1216 ATA bus error means that data corruption occurred during 1217 transmission over ATA bus (SATA or PATA). This type of errors 1218 can be indicated by 1219 </para> 1220 1221 <itemizedlist> 1222 1223 <listitem> 1224 <para> 1225 ICRC or ABRT error as described in <xref linkend="excatDevErr"/>. 1226 </para> 1227 </listitem> 1228 1229 <listitem> 1230 <para> 1231 Controller-specific error completion with error information 1232 indicating transmission error. 1233 </para> 1234 </listitem> 1235 1236 <listitem> 1237 <para> 1238 On some controllers, command timeout. In this case, there may 1239 be a mechanism to determine that the timeout is due to 1240 transmission error. 1241 </para> 1242 </listitem> 1243 1244 <listitem> 1245 <para> 1246 Unknown/random errors, timeouts and all sorts of weirdities. 1247 </para> 1248 </listitem> 1249 1250 </itemizedlist> 1251 1252 <para> 1253 As described above, transmission errors can cause wide variety 1254 of symptoms ranging from device ICRC error to random device 1255 lockup, and, for many cases, there is no way to tell if an 1256 error condition is due to transmission error or not; 1257 therefore, it's necessary to employ some kind of heuristic 1258 when dealing with errors and timeouts. For example, 1259 encountering repetitive ABRT errors for known supported 1260 command is likely to indicate ATA bus error. 1261 </para> 1262 1263 <para> 1264 Once it's determined that ATA bus errors have possibly 1265 occurred, lowering ATA bus transmission speed is one of 1266 actions which may alleviate the problem. See <xref 1267 linkend="exrecReconf"/> for more information. 1268 </para> 1269 1270 </sect2> 1271 1272 <sect2 id="excatPCIbusErr"> 1273 <title>PCI bus error</title> 1274 1275 <para> 1276 Data corruption or other failures during transmission over PCI 1277 (or other system bus). For standard BMDMA, this is indicated 1278 by Error bit in the BMDMA Status register. This type of 1279 errors must be logged as it indicates something is very wrong 1280 with the system. Resetting host controller is recommended. 1281 </para> 1282 1283 </sect2> 1284 1285 <sect2 id="excatLateCompletion"> 1286 <title>Late completion</title> 1287 1288 <para> 1289 This occurs when timeout occurs and the timeout handler finds 1290 out that the timed out command has completed successfully or 1291 with error. This is usually caused by lost interrupts. This 1292 type of errors must be logged. Resetting host controller is 1293 recommended. 1294 </para> 1295 1296 </sect2> 1297 1298 <sect2 id="excatUnknown"> 1299 <title>Unknown error (timeout)</title> 1300 1301 <para> 1302 This is when timeout occurs and the command is still 1303 processing or the host and device are in unknown state. When 1304 this occurs, HSM could be in any valid or invalid state. To 1305 bring the device to known state and make it forget about the 1306 timed out command, resetting is necessary. The timed out 1307 command may be retried. 1308 </para> 1309 1310 <para> 1311 Timeouts can also be caused by transmission errors. Refer to 1312 <xref linkend="excatATAbusErr"/> for more details. 1313 </para> 1314 1315 </sect2> 1316 1317 <sect2 id="excatHoplugPM"> 1318 <title>Hotplug and power management exceptions</title> 1319 1320 <para> 1321 <<TODO: fill here>> 1322 </para> 1323 1324 </sect2> 1325 1326 </sect1> 1327 1328 <sect1 id="exrec"> 1329 <title>EH recovery actions</title> 1330 1331 <para> 1332 This section discusses several important recovery actions. 1333 </para> 1334 1335 <sect2 id="exrecClr"> 1336 <title>Clearing error condition</title> 1337 1338 <para> 1339 Many controllers require its error registers to be cleared by 1340 error handler. Different controllers may have different 1341 requirements. 1342 </para> 1343 1344 <para> 1345 For SATA, it's strongly recommended to clear at least SError 1346 register during error handling. 1347 </para> 1348 </sect2> 1349 1350 <sect2 id="exrecRst"> 1351 <title>Reset</title> 1352 1353 <para> 1354 During EH, resetting is necessary in the following cases. 1355 </para> 1356 1357 <itemizedlist> 1358 1359 <listitem> 1360 <para> 1361 HSM is in unknown or invalid state 1362 </para> 1363 </listitem> 1364 1365 <listitem> 1366 <para> 1367 HBA is in unknown or invalid state 1368 </para> 1369 </listitem> 1370 1371 <listitem> 1372 <para> 1373 EH needs to make HBA/device forget about in-flight commands 1374 </para> 1375 </listitem> 1376 1377 <listitem> 1378 <para> 1379 HBA/device behaves weirdly 1380 </para> 1381 </listitem> 1382 1383 </itemizedlist> 1384 1385 <para> 1386 Resetting during EH might be a good idea regardless of error 1387 condition to improve EH robustness. Whether to reset both or 1388 either one of HBA and device depends on situation but the 1389 following scheme is recommended. 1390 </para> 1391 1392 <itemizedlist> 1393 1394 <listitem> 1395 <para> 1396 When it's known that HBA is in ready state but ATA/ATAPI 1397 device is in unknown state, reset only device. 1398 </para> 1399 </listitem> 1400 1401 <listitem> 1402 <para> 1403 If HBA is in unknown state, reset both HBA and device. 1404 </para> 1405 </listitem> 1406 1407 </itemizedlist> 1408 1409 <para> 1410 HBA resetting is implementation specific. For a controller 1411 complying to taskfile/BMDMA PCI IDE, stopping active DMA 1412 transaction may be sufficient iff BMDMA state is the only HBA 1413 context. But even mostly taskfile/BMDMA PCI IDE complying 1414 controllers may have implementation specific requirements and 1415 mechanism to reset themselves. This must be addressed by 1416 specific drivers. 1417 </para> 1418 1419 <para> 1420 OTOH, ATA/ATAPI standard describes in detail ways to reset 1421 ATA/ATAPI devices. 1422 </para> 1423 1424 <variablelist> 1425 1426 <varlistentry><term>PATA hardware reset</term> 1427 <listitem> 1428 <para> 1429 This is hardware initiated device reset signalled with 1430 asserted PATA RESET- signal. There is no standard way to 1431 initiate hardware reset from software although some 1432 hardware provides registers that allow driver to directly 1433 tweak the RESET- signal. 1434 </para> 1435 </listitem> 1436 </varlistentry> 1437 1438 <varlistentry><term>Software reset</term> 1439 <listitem> 1440 <para> 1441 This is achieved by turning CONTROL SRST bit on for at 1442 least 5us. Both PATA and SATA support it but, in case of 1443 SATA, this may require controller-specific support as the 1444 second Register FIS to clear SRST should be transmitted 1445 while BSY bit is still set. Note that on PATA, this resets 1446 both master and slave devices on a channel. 1447 </para> 1448 </listitem> 1449 </varlistentry> 1450 1451 <varlistentry><term>EXECUTE DEVICE DIAGNOSTIC command</term> 1452 <listitem> 1453 <para> 1454 Although ATA/ATAPI standard doesn't describe exactly, EDD 1455 implies some level of resetting, possibly similar level 1456 with software reset. Host-side EDD protocol can be handled 1457 with normal command processing and most SATA controllers 1458 should be able to handle EDD's just like other commands. 1459 As in software reset, EDD affects both devices on a PATA 1460 bus. 1461 </para> 1462 <para> 1463 Although EDD does reset devices, this doesn't suit error 1464 handling as EDD cannot be issued while BSY is set and it's 1465 unclear how it will act when device is in unknown/weird 1466 state. 1467 </para> 1468 </listitem> 1469 </varlistentry> 1470 1471 <varlistentry><term>ATAPI DEVICE RESET command</term> 1472 <listitem> 1473 <para> 1474 This is very similar to software reset except that reset 1475 can be restricted to the selected device without affecting 1476 the other device sharing the cable. 1477 </para> 1478 </listitem> 1479 </varlistentry> 1480 1481 <varlistentry><term>SATA phy reset</term> 1482 <listitem> 1483 <para> 1484 This is the preferred way of resetting a SATA device. In 1485 effect, it's identical to PATA hardware reset. Note that 1486 this can be done with the standard SCR Control register. 1487 As such, it's usually easier to implement than software 1488 reset. 1489 </para> 1490 </listitem> 1491 </varlistentry> 1492 1493 </variablelist> 1494 1495 <para> 1496 One more thing to consider when resetting devices is that 1497 resetting clears certain configuration parameters and they 1498 need to be set to their previous or newly adjusted values 1499 after reset. 1500 </para> 1501 1502 <para> 1503 Parameters affected are. 1504 </para> 1505 1506 <itemizedlist> 1507 1508 <listitem> 1509 <para> 1510 CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used) 1511 </para> 1512 </listitem> 1513 1514 <listitem> 1515 <para> 1516 Parameters set with SET FEATURES including transfer mode setting 1517 </para> 1518 </listitem> 1519 1520 <listitem> 1521 <para> 1522 Block count set with SET MULTIPLE MODE 1523 </para> 1524 </listitem> 1525 1526 <listitem> 1527 <para> 1528 Other parameters (SET MAX, MEDIA LOCK...) 1529 </para> 1530 </listitem> 1531 1532 </itemizedlist> 1533 1534 <para> 1535 ATA/ATAPI standard specifies that some parameters must be 1536 maintained across hardware or software reset, but doesn't 1537 strictly specify all of them. Always reconfiguring needed 1538 parameters after reset is required for robustness. Note that 1539 this also applies when resuming from deep sleep (power-off). 1540 </para> 1541 1542 <para> 1543 Also, ATA/ATAPI standard requires that IDENTIFY DEVICE / 1544 IDENTIFY PACKET DEVICE is issued after any configuration 1545 parameter is updated or a hardware reset and the result used 1546 for further operation. OS driver is required to implement 1547 revalidation mechanism to support this. 1548 </para> 1549 1550 </sect2> 1551 1552 <sect2 id="exrecReconf"> 1553 <title>Reconfigure transport</title> 1554 1555 <para> 1556 For both PATA and SATA, a lot of corners are cut for cheap 1557 connectors, cables or controllers and it's quite common to see 1558 high transmission error rate. This can be mitigated by 1559 lowering transmission speed. 1560 </para> 1561 1562 <para> 1563 The following is a possible scheme Jeff Garzik suggested. 1564 </para> 1565 1566 <blockquote> 1567 <para> 1568 If more than $N (3?) transmission errors happen in 15 minutes, 1569 </para> 1570 <itemizedlist> 1571 <listitem> 1572 <para> 1573 if SATA, decrease SATA PHY speed. if speed cannot be decreased, 1574 </para> 1575 </listitem> 1576 <listitem> 1577 <para> 1578 decrease UDMA xfer speed. if at UDMA0, switch to PIO4, 1579 </para> 1580 </listitem> 1581 <listitem> 1582 <para> 1583 decrease PIO xfer speed. if at PIO3, complain, but continue 1584 </para> 1585 </listitem> 1586 </itemizedlist> 1587 </blockquote> 1588 1589 </sect2> 1590 1591 </sect1> 1592 1593 </chapter> 1594 1595 <chapter id="PiixInt"> 1596 <title>ata_piix Internals</title> 1597 !Idrivers/ata/ata_piix.c 1598 </chapter> 1599 1600 <chapter id="SILInt"> 1601 <title>sata_sil Internals</title> 1602 !Idrivers/ata/sata_sil.c 1603 </chapter> 1604 1605 <chapter id="libataThanks"> 1606 <title>Thanks</title> 1607 <para> 1608 The bulk of the ATA knowledge comes thanks to long conversations with 1609 Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA 1610 and SCSI specifications. 1611 </para> 1612 <para> 1613 Thanks to Alan Cox for pointing out similarities 1614 between SATA and SCSI, and in general for motivation to hack on 1615 libata. 1616 </para> 1617 <para> 1618 libata's device detection 1619 method, ata_pio_devchk, and in general all the early probing was 1620 based on extensive study of Hale Landis's probe/reset code in his 1621 ATADRVR driver (www.ata-atapi.com). 1622 </para> 1623 </chapter> 1624 1625 </book>