linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Carlos Pardo <Carlos.Pardo@siliconimage.com>
Subject: Re: [PATCH] libata error handling fixes (ATAPI)
Date: Tue, 15 Nov 2005 09:11:14 -0500	[thread overview]
Message-ID: <4379EC82.1030509@pobox.com> (raw)
In-Reply-To: <4379E5F7.6000107@gmail.com>

Tejun Heo wrote:
> * prb->fis doesn't contain proper signature after phy reset.  I just 

This makes sense.  Each PRB slot in the card's RAM only contains 
something useful after you have submitted a PRB, and had some results 
returned.


> * As all commands hang after failed TUR, which BTW fails rightfully with 
> 06h (UNIT ATTENTION due to prior reset) and then 02h's (NOT READY), I 
> avoided TUR failures by issuing REQUEST SENSE first, which returns NO 
> SENSE but does clear UA condition, and then waiting for more than 10secs 
> to give the drive time to become ready.

10 seconds is certainly a long time.

grep for msleep(150) in libata code, though.


> * With above two changes, no command fails and I can mount the cdrom.
> 
> ------------------
> 
> And here are things that I've found out so far....
> 
> * ATAPI commands without data (TEST_UNIT_READY, ALLOW_MEDIUM_REMOVAL...) 
> work happily with any prb->ctrl flag (no flag, PRB_CTRL_PACKET_READ or 
> PRB_CTRL_PACKET_WRITE).

I suppose no-flag is the right answer, then...


> * Currently, sil24_reset_controller() is called on every error interrupt 
> to make sure the controller is ready for further operation. 
> Unfortunately, the current reset_controller() seems to reset PHY too. 
> The drive becomes NOT READY after reset_controller().  So, when TUR 
> fails, it falls into TUR, fail with NOT READY, reset which makes the 
> drive NOT READY again cycle.

Standard init sequence includes checking SStatus, then if a device is 
present, waiting until Port Ready (bit 31) of PORT_CTRL_STAT is set.  It 
doesn't look like sata_sil24 does that.


> * Wihtout sil24_reset_controller(), no further command can be issued. 
> The controller doesn't seem to be operating normally after DEV_ERR.

The port stops, when any error occurs.  For device errors, set 
PORT_CS_INIT bit in PORT_CTRL_STAT, then wait for Port Ready (bit 31, 
see above).


> So, what we need to know to make sil24 work happily with ATAPI devices.
> 
> * How to get device signature on initialization.

AFAICS, you _must_ send a soft reset PRB.  This will be needed anyway, 
for port multiplier support.


> * How to make the controller operational again after a DEV_ERR without 
> affecting the attached device.

Assert PORT_CS_INIT, then wait for Port Ready.  __ONLY__ do this for 
errors PORT_CERR_DEV and PORT_CERR_SDB.

	Jeff



  reply	other threads:[~2005-11-15 14:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-14 19:57 [PATCH] libata error handling fixes (ATAPI) Jeff Garzik
2005-11-15  7:41 ` Tejun Heo
2005-11-15  9:28   ` Jeff Garzik
2005-11-15 10:03     ` Tejun Heo
2005-11-15 11:02       ` Jeff Garzik
2005-11-15 12:00         ` Jens Axboe
2005-11-15 18:25           ` Mike Christie
2005-11-15 18:41             ` Jens Axboe
2005-11-16 12:40               ` Jens Axboe
2005-11-16 12:56                 ` Jeff Garzik
2005-11-16 13:13                   ` Jens Axboe
2005-11-16 13:23                     ` Jeff Garzik
2005-11-16 13:31                 ` Jeff Garzik
2005-11-16 13:47                   ` Jens Axboe
2005-11-16 15:04                 ` Bartlomiej Zolnierkiewicz
2005-11-16 15:31                   ` Jens Axboe
2005-11-16 16:06                     ` Bartlomiej Zolnierkiewicz
2005-11-16 17:10                       ` Jens Axboe
2005-11-16 19:11                         ` Bartlomiej Zolnierkiewicz
2005-11-16 19:22                           ` Jens Axboe
2005-11-16 19:45                             ` Jens Axboe
2005-11-16 19:46                             ` Bartlomiej Zolnierkiewicz
2005-11-16 19:55                               ` Bartlomiej Zolnierkiewicz
2005-11-16 20:02                                 ` Jens Axboe
2005-11-16 20:23                                   ` Bartlomiej Zolnierkiewicz
2005-11-16 20:40                                     ` Jens Axboe
2005-11-19 10:55                       ` Christoph Hellwig
2005-11-19 13:27                         ` Jens Axboe
2005-11-15 13:43     ` Tejun Heo
2005-11-15 14:11       ` Jeff Garzik [this message]
2005-11-16  3:04         ` Tejun Heo
2005-11-16  3:18           ` Jeff Garzik
2005-11-16  3:48             ` Mark Lord
2005-11-16  3:58               ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4379EC82.1030509@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=Carlos.Pardo@siliconimage.com \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).