linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-ide@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] libata-core: Don't have screaming fits over DF/ERR combinations
Date: Mon, 15 Oct 2007 16:09:52 -0400	[thread overview]
Message-ID: <4713C910.1070909@pobox.com> (raw)
In-Reply-To: <4713C821.6090303@ru.mvista.com>

Sergei Shtylyov wrote:
> Jeff Garzik wrote:
> 
>>>> Some hardware seems to get this wrong in a non-harmful way, and 
>>>> there are
>>>> some devices that seem to do it deliberately for various reasons.
> 
>>>> Just take it as a device error not a catastrophic state machine
>>>> explosion. 
> 
>>>> Signed-off-by: Alan Cox <alan@redhat.com>
> 
>>>> diff -u --exclude-from /usr/src/exclude --new-file --recursive 
>>>> linux.vanilla-2.6.23-mm1/drivers/ata/libata-core.c 
>>>> linux-2.6.23-mm1/drivers/ata/libata-core.c
>>>> --- linux.vanilla-2.6.23-mm1/drivers/ata/libata-core.c    2007-10-15 
>>>> 15:03:26.000000000 +0100
>>>> +++ linux-2.6.23-mm1/drivers/ata/libata-core.c    2007-10-15 
>>>> 15:13:49.000000000 +0100
>>>> @@ -5258,7 +5319,15 @@
>>>>          if (unlikely(status & (ATA_ERR | ATA_DF))) {
>>>>              ata_port_printk(ap, KERN_WARNING, "DRQ=1 with device "
>>>>                      "error, dev_stat 0x%X\n", status);
>>>> -            qc->err_mask |= AC_ERR_HSM;
>>>> +            /* Some devices muck this up. Some follow an ATA
>>>> +               non-standard that permits the damaged sector to
>>>> +               be retrieved at this point. The ATA spec says
>>>> +               we should jump up and down on DRQ + ERR, reality
> 
>>>    I've always thought that setting both DRQ and ERR is perfectly 
>>> valid (well, maybe it's become invalid since ATAPI-4 where all these 
>>> state transition flow charts have made its first appearance, to be 
>>> quickly replaced by the state diagrams :-) -- I'm too lazy to check 
>>> now... :-)
> 
>> DRQ+ERR is valid, and SRST (or hard reset) is defined as the method of 
>> kicking the device out of that state.
> 
>    Well, in the times of old, reading a sector (or group of them for 
> multiple mode) was valid for that purpose, wasn't it?

Yes, hence the recent FIFO drain patches.

But that doesn't make sense for SATA devices, where the FIFO is really 
emulated, and it works on older PATA devices.

	Jeff




  reply	other threads:[~2007-10-15 20:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-15 18:23 [PATCH] libata-core: Don't have screaming fits over DF/ERR combinations Alan Cox
2007-10-15 19:53 ` Sergei Shtylyov
2007-10-15 20:02   ` Jeff Garzik
2007-10-15 20:05     ` Sergei Shtylyov
2007-10-15 20:09       ` Jeff Garzik [this message]
2007-10-15 20:58         ` Alan Cox
2007-10-25  6:04 ` 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=4713C910.1070909@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-ide@vger.kernel.org \
    --cc=sshtylyov@ru.mvista.com \
    /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).