From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Gregor Jasny <gjasny@googlemail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ide@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Re: Linux v2.6.22-rc3
Date: Fri, 08 Jun 2007 17:02:24 +0900 [thread overview]
Message-ID: <46690D10.9040808@gmail.com> (raw)
In-Reply-To: <20070607224746.GA23290@havoc.gtf.org>
Hello,
Jeff Garzik wrote:
> On Thu, Jun 07, 2007 at 01:56:11PM -0700, Linus Torvalds wrote:
>> On Thu, 7 Jun 2007, Tejun Heo wrote:
>>> Ah.. okay. Now I see what's going on. Jeff, this is another device
>>> which doesn't set nsect and lbal to 1 after reset. Gregor, please try
>>> the attached patch.
>
>> Tejun, since Jeff is apparently traveling this week, and Gregor tested the
>> patch successfully (and it looks sane anyway - why in Gods name _would_ we
>> care what the initial setting of nsect/lbal is?), can you send this in
>> with the changelog and sign-off?
>
> Ack'ing the sata_promise change was easy, but with this one it would
> be nice to wait a bit before changing the core probe code that [now]
> every ATA setup goes through, based on a single bug report.
Yeap, I'm not so sure about the change either. The posted patch is more
of proof-of-concept.
Currently we have three related reports.
* this one
* IT8212 raid mode Alan is working on
* (likely) pata_pcmcia http://thread.gmane.org/gmane.linux.kernel/530099
> The values assist in detecting ghost devices (same device appearing
> on both master and slave) and TF register malfunctions, and I would
> appreciate not breaking _that_ so late in 2.6.22-rc for a single
> report. Thankfully we have -some- ghost device prevention code
> elsewhere, but this is part of it.
Upto 2.6.21, if the same condition triggers, it delays 30secs and just
continue, so I don't think it was a worthy protection against ghost
devices or TF malfunction. The only protection it offers is preventing
libata from accessing slave's status register too early. SRST sequence
looks like the following.
1. SRST raised, delay, and cleared
2. libata waits for master device readiness after 150ms pause. After
finishing reset, if slave is present, master waits for PDIAG- assert.
3. slave asserts PDIAG-, master asserts readiness. libata goes on to
check for the slave device nsect/lbal.
4. slave sets nsect/lbal, libata goes on to check readiness
5. slave asserts readiness, SRST complete.
So, the nsect/lbal check is meaningful iff 1. slave lies about device
readiness after releasing PDIAG- but before setting nsect/lbal, or 2.
master/slave register selection is flimsy.
I don't think the first one is probable considering BSY is supposed to
set when SRST is received. This is pretty fundamental in the protocol
and necessary for the device to work properly as master, so I think this
is one of few things we can rely upon.
To me, the second one sounds pretty far fetched too but, well, it's ATA.
Who knows?
How about limiting nsect/lbal wait duration? Say, 100ms or 500ms? That
can somewhat ease our paranoia and should show acceptable behavior for
braindead devices too.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-06-08 8:02 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LFD.0.98.0705252008210.26602@woody.linux-foundation.org>
2007-05-27 15:01 ` Linux v2.6.22-rc3 Gregor Jasny
2007-05-27 15:06 ` Jeff Garzik
2007-05-27 16:07 ` Gregor Jasny
2007-05-27 16:24 ` Linus Torvalds
2007-05-27 20:15 ` Gregor Jasny
2007-05-28 9:47 ` Tejun Heo
2007-05-28 14:07 ` Gregor Jasny
2007-05-29 9:28 ` Tejun Heo
2007-05-29 15:19 ` Gregor Jasny
2007-05-29 16:44 ` Linus Torvalds
2007-06-01 0:58 ` Tejun Heo
2007-06-01 1:37 ` Linus Torvalds
2007-06-01 2:19 ` Tejun Heo
2007-06-01 16:50 ` Jeff Garzik
2007-06-01 17:04 ` Linus Torvalds
2007-06-01 17:35 ` Jeff Garzik
2007-06-01 17:59 ` Linus Torvalds
2007-06-01 18:20 ` Dave Jones
2007-06-01 18:30 ` Linus Torvalds
2007-06-01 18:46 ` Dave Jones
2007-06-01 18:41 ` Jeff Garzik
2007-06-01 18:48 ` Jeff Garzik
2007-06-02 7:50 ` Tejun Heo
2007-05-28 21:50 ` Bill Davidsen
2007-06-02 16:11 ` [PATCH] " Jeff Garzik
2007-06-03 17:46 ` Gregor Jasny
2007-06-06 8:46 ` Tejun Heo
2007-06-07 6:22 ` Gregor Jasny
2007-06-07 7:27 ` Tejun Heo
2007-06-07 20:37 ` Gregor Jasny
2007-06-07 20:56 ` Linus Torvalds
2007-06-07 22:39 ` Alan Cox
2007-06-07 22:47 ` Jeff Garzik
2007-06-08 8:02 ` Tejun Heo [this message]
2007-06-08 11:27 ` Alan Cox
2007-06-08 11:32 ` Tejun Heo
2007-06-08 11:40 ` Alan Cox
2007-06-08 14:28 ` Jeff Garzik
2007-06-08 15:36 ` Alan Cox
2007-06-08 15:32 ` Jeff Garzik
2007-06-08 15:46 ` Alan Cox
2007-06-08 15:49 ` Jeff Garzik
2007-06-08 15:59 ` Alan Cox
2007-06-08 14:31 ` Jeff Garzik
2007-06-08 15:38 ` Alan Cox
2007-06-08 15:35 ` Jeff Garzik
2007-06-08 15:44 ` Alan Cox
2007-06-09 18:12 ` Linus Torvalds
2007-06-09 19:03 ` Jeff Garzik
2007-06-10 5:26 ` [PATCH] libata: limit post SRST nsect/lbal wait to ~100ms Tejun Heo
2007-06-10 16:23 ` Jeff Garzik
2007-06-11 4:59 ` Jeff Garzik
2007-06-08 15:55 ` [PATCH] Re: Linux v2.6.22-rc3 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=46690D10.9040808@gmail.com \
--to=htejun@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gjasny@googlemail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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).