libata.tmpl

linux 内核源代码

	<itemizedlist>

	<listitem>
	<para>
	ICRC or ABRT error as described in <xref linkend="excatDevErr"/>.
	</para>
	</listitem>

	<listitem>
	<para>
	Controller-specific error completion with error information
	indicating transmission error.
	</para>
	</listitem>

	<listitem>
	<para>
	On some controllers, command timeout.  In this case, there may
	be a mechanism to determine that the timeout is due to
	transmission error.
	</para>
	</listitem>

	<listitem>
	<para>
	Unknown/random errors, timeouts and all sorts of weirdities.
	</para>
	</listitem>

	</itemizedlist>

	<para>
	As described above, transmission errors can cause wide variety
	of symptoms ranging from device ICRC error to random device
	lockup, and, for many cases, there is no way to tell if an
	error condition is due to transmission error or not;
	therefore, it's necessary to employ some kind of heuristic
	when dealing with errors and timeouts.  For example,
	encountering repetitive ABRT errors for known supported
	command is likely to indicate ATA bus error.
	</para>

	<para>
	Once it's determined that ATA bus errors have possibly
	occurred, lowering ATA bus transmission speed is one of
	actions which may alleviate the problem.  See <xref
	linkend="exrecReconf"/> for more information.
	</para>

     </sect2>

     <sect2 id="excatPCIbusErr">
        <title>PCI bus error</title>

	<para>
	Data corruption or other failures during transmission over PCI
	(or other system bus).  For standard BMDMA, this is indicated
	by Error bit in the BMDMA Status register.  This type of
	errors must be logged as it indicates something is very wrong
	with the system.  Resetting host controller is recommended.
	</para>

     </sect2>

     <sect2 id="excatLateCompletion">
        <title>Late completion</title>

	<para>
	This occurs when timeout occurs and the timeout handler finds
	out that the timed out command has completed successfully or
	with error.  This is usually caused by lost interrupts.  This
	type of errors must be logged.  Resetting host controller is
	recommended.
	</para>

     </sect2>

     <sect2 id="excatUnknown">
        <title>Unknown error (timeout)</title>

	<para>
	This is when timeout occurs and the command is still
	processing or the host and device are in unknown state.  When
	this occurs, HSM could be in any valid or invalid state.  To
	bring the device to known state and make it forget about the
	timed out command, resetting is necessary.  The timed out
	command may be retried.
	</para>

	<para>
	Timeouts can also be caused by transmission errors.  Refer to
	<xref linkend="excatATAbusErr"/> for more details.
	</para>

     </sect2>

     <sect2 id="excatHoplugPM">
        <title>Hotplug and power management exceptions</title>

	<para>
	&lt;&lt;TODO: fill here&gt;&gt;
	</para>

     </sect2>

  </sect1>

  <sect1 id="exrec">
     <title>EH recovery actions</title>

     <para>
     This section discusses several important recovery actions.
     </para>

     <sect2 id="exrecClr">
        <title>Clearing error condition</title>

	<para>
	Many controllers require its error registers to be cleared by
	error handler.  Different controllers may have different
	requirements.
	</para>

	<para>
	For SATA, it's strongly recommended to clear at least SError
	register during error handling.
	</para>
     </sect2>

     <sect2 id="exrecRst">
        <title>Reset</title>

	<para>
	During EH, resetting is necessary in the following cases.
	</para>

	<itemizedlist>

	<listitem>
	<para>
	HSM is in unknown or invalid state
	</para>
	</listitem>

	<listitem>
	<para>
	HBA is in unknown or invalid state
	</para>
	</listitem>

	<listitem>
	<para>
	EH needs to make HBA/device forget about in-flight commands
	</para>
	</listitem>

	<listitem>
	<para>
	HBA/device behaves weirdly
	</para>
	</listitem>

	</itemizedlist>

	<para>
	Resetting during EH might be a good idea regardless of error
	condition to improve EH robustness.  Whether to reset both or
	either one of HBA and device depends on situation but the
	following scheme is recommended.
	</para>

	<itemizedlist>

	<listitem>
	<para>
	When it's known that HBA is in ready state but ATA/ATAPI
	device is in unknown state, reset only device.
	</para>
	</listitem>

	<listitem>
	<para>
	If HBA is in unknown state, reset both HBA and device.
	</para>
	</listitem>

	</itemizedlist>

	<para>
	HBA resetting is implementation specific.  For a controller
	complying to taskfile/BMDMA PCI IDE, stopping active DMA
	transaction may be sufficient iff BMDMA state is the only HBA
	context.  But even mostly taskfile/BMDMA PCI IDE complying
	controllers may have implementation specific requirements and
	mechanism to reset themselves.  This must be addressed by
	specific drivers.
	</para>

	<para>
	OTOH, ATA/ATAPI standard describes in detail ways to reset
	ATA/ATAPI devices.
	</para>

	<variablelist>

	   <varlistentry><term>PATA hardware reset</term>
	   <listitem>
	   <para>
	   This is hardware initiated device reset signalled with
	   asserted PATA RESET- signal.  There is no standard way to
	   initiate hardware reset from software although some
	   hardware provides registers that allow driver to directly
	   tweak the RESET- signal.
	   </para>
	   </listitem>
	   </varlistentry>

	   <varlistentry><term>Software reset</term>
	   <listitem>
	   <para>
	   This is achieved by turning CONTROL SRST bit on for at
	   least 5us.  Both PATA and SATA support it but, in case of
	   SATA, this may require controller-specific support as the
	   second Register FIS to clear SRST should be transmitted
	   while BSY bit is still set.  Note that on PATA, this resets
	   both master and slave devices on a channel.
	   </para>
	   </listitem>
	   </varlistentry>

	   <varlistentry><term>EXECUTE DEVICE DIAGNOSTIC command</term>
	   <listitem>
	   <para>
	   Although ATA/ATAPI standard doesn't describe exactly, EDD
	   implies some level of resetting, possibly similar level
	   with software reset.  Host-side EDD protocol can be handled
	   with normal command processing and most SATA controllers
	   should be able to handle EDD's just like other commands.
	   As in software reset, EDD affects both devices on a PATA
	   bus.
	   </para>
	   <para>
	   Although EDD does reset devices, this doesn't suit error
	   handling as EDD cannot be issued while BSY is set and it's
	   unclear how it will act when device is in unknown/weird
	   state.
	   </para>
	   </listitem>
	   </varlistentry>

	   <varlistentry><term>ATAPI DEVICE RESET command</term>
	   <listitem>
	   <para>
	   This is very similar to software reset except that reset
	   can be restricted to the selected device without affecting
	   the other device sharing the cable.
	   </para>
	   </listitem>
	   </varlistentry>

	   <varlistentry><term>SATA phy reset</term>
	   <listitem>
	   <para>
	   This is the preferred way of resetting a SATA device.  In
	   effect, it's identical to PATA hardware reset.  Note that
	   this can be done with the standard SCR Control register.
	   As such, it's usually easier to implement than software
	   reset.
	   </para>
	   </listitem>
	   </varlistentry>

	</variablelist>

	<para>
	One more thing to consider when resetting devices is that
	resetting clears certain configuration parameters and they
	need to be set to their previous or newly adjusted values
	after reset.
	</para>

	<para>
	Parameters affected are.
	</para>

	<itemizedlist>

	<listitem>
	<para>
	CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
	</para>
	</listitem>

	<listitem>
	<para>
	Parameters set with SET FEATURES including transfer mode setting
	</para>
	</listitem>

	<listitem>
	<para>
	Block count set with SET MULTIPLE MODE
	</para>
	</listitem>

	<listitem>
	<para>
	Other parameters (SET MAX, MEDIA LOCK...)
	</para>
	</listitem>

	</itemizedlist>

	<para>
	ATA/ATAPI standard specifies that some parameters must be
	maintained across hardware or software reset, but doesn't
	strictly specify all of them.  Always reconfiguring needed
	parameters after reset is required for robustness.  Note that
	this also applies when resuming from deep sleep (power-off).
	</para>

	<para>
	Also, ATA/ATAPI standard requires that IDENTIFY DEVICE /
	IDENTIFY PACKET DEVICE is issued after any configuration
	parameter is updated or a hardware reset and the result used
	for further operation.  OS driver is required to implement
	revalidation mechanism to support this.
	</para>

     </sect2>

     <sect2 id="exrecReconf">
        <title>Reconfigure transport</title>

	<para>
	For both PATA and SATA, a lot of corners are cut for cheap
	connectors, cables or controllers and it's quite common to see
	high transmission error rate.  This can be mitigated by
	lowering transmission speed.
	</para>

	<para>
	The following is a possible scheme Jeff Garzik suggested.
	</para>

	<blockquote>
	<para>
	If more than $N (3?) transmission errors happen in 15 minutes,
	</para>	
	<itemizedlist>
	<listitem>
	<para>
	if SATA, decrease SATA PHY speed.  if speed cannot be decreased,
	</para>
	</listitem>
	<listitem>
	<para>
	decrease UDMA xfer speed.  if at UDMA0, switch to PIO4,
	</para>
	</listitem>
	<listitem>
	<para>
	decrease PIO xfer speed.  if at PIO3, complain, but continue
	</para>
	</listitem>
	</itemizedlist>
	</blockquote>

     </sect2>

  </sect1>

  </chapter>

  <chapter id="PiixInt">
     <title>ata_piix Internals</title>
!Idrivers/ata/ata_piix.c
  </chapter>

  <chapter id="SILInt">
     <title>sata_sil Internals</title>
!Idrivers/ata/sata_sil.c
  </chapter>

  <chapter id="libataThanks">
     <title>Thanks</title>
  <para>
  The bulk of the ATA knowledge comes thanks to long conversations with
  Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA
  and SCSI specifications.
  </para>
  <para>
  Thanks to Alan Cox for pointing out similarities 
  between SATA and SCSI, and in general for motivation to hack on
  libata.
  </para>
  <para>
  libata's device detection
  method, ata_pio_devchk, and in general all the early probing was
  based on extensive study of Hale Landis's probe/reset code in his
  ATADRVR driver (www.ata-atapi.com).
  </para>
  </chapter>

</book>