From: Tejun Heo <htejun@gmail.com>
Cc: Gary Hade <garyhade@us.ibm.com>,
Kovid Goyal <kovid@theory.caltech.edu>,
linux-ide@vger.kernel.org, lcm@us.ibm.com,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [2.6.18,19] SATA boot problems (ICH6/ICH6W)
Date: Wed, 20 Dec 2006 13:30:22 +0900 [thread overview]
Message-ID: <4588BC5E.6020205@gmail.com> (raw)
In-Reply-To: <4588B3D5.4030406@gmail.com>
Tejun Heo wrote:
> I would be surprised if Kovid's sda not detected case is caused by this.
> For GoVault (that's SATAPI right?), yeah, maybe. For an ATA disk, no
> way (hopefully).
>
> Can you consult with quantum about it? If they verify your fix (ie,
> GoVault sometimes take more than 150ms to transmit the first D2H Reg FIs
> after SRST), I'll push similar patch upstream.
>
> Hmm.. or do we have to wait !BSY here as old IDE did?
More thoughts.
* IIRC, ata_piix reports 0xff if SATA link is broken. 0x80 or something
similar if link established && waiting for the first FIS. Not sure
whether this always holds but it tends to work that way. So, 0xff
status means phy link broken, which shouldn't happen after SRST. Hmmm..
* Recently in ata_bus_softreset() and waiting functions, we've added the
assumption status==0xff indicates empty port. This is taken from the
IDE layer and proven to work for PATA devices. I'm not sure we can
safely use this to SATA devices tho. If PHY is broken or the first FIS
isn't received, arbitrary value (sometimes accidentally) chosen by the
controller is used which may as well be 0xff. But, then again, many
controllers do mean that there is no devices by 0xff status including
ata_piix w/ its now infamous phantom device problems.
I think we should honor 0xff iff SCR on/offline status is not available.
How does that sound?
--
tejun
next prev parent reply other threads:[~2006-12-20 4:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-11 18:03 [2.6.18,19] SATA boot problems (ICH6/ICH6W) Kovid Goyal
2006-12-20 0:44 ` Tejun Heo
2006-12-20 2:00 ` Kovid Goyal
2006-12-20 2:13 ` Tejun Heo
2006-12-20 4:56 ` Kovid Goyal
2007-01-11 23:32 ` Kovid Goyal
2007-01-13 2:19 ` Tejun Heo
2006-12-20 3:29 ` Gary Hade
2006-12-20 3:53 ` Tejun Heo
2006-12-20 4:30 ` Tejun Heo [this message]
2006-12-21 17:10 ` Gary Hade
2007-01-30 1:55 ` Gary Hade
2007-01-30 7:32 ` Tejun Heo
2007-01-30 23:37 ` Gary Hade
2007-01-31 0:54 ` Jeff Garzik
2007-01-31 11:00 ` Tejun Heo
2007-01-31 12:20 ` Alan
2007-01-31 13:16 ` Tejun Heo
2007-01-31 15:24 ` Jeff Garzik
2007-01-31 15:30 ` Mark Lord
2007-01-31 10:44 ` Tejun Heo
2007-01-31 10:47 ` Jeff Garzik
2007-01-31 11:00 ` Tejun Heo
2007-02-01 0:49 ` Gary Hade
2007-02-17 0:34 ` Gary Hade
2007-02-21 12:40 ` Tejun Heo
2007-02-22 0:41 ` Gary Hade
2007-02-23 0:32 ` Gary Hade
2007-01-23 21:49 ` danieljzhang
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=4588BC5E.6020205@gmail.com \
--to=htejun@gmail.com \
--cc=garyhade@us.ibm.com \
--cc=jgarzik@pobox.com \
--cc=kovid@theory.caltech.edu \
--cc=lcm@us.ibm.com \
--cc=linux-ide@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).