From: Mark Lord <liml@rtr.ca>
To: Tejun Heo <tj@kernel.org>
Cc: Michael Guntsche <mike@it-loops.com>,
linux-ide@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jeff Garzik <jeff@garzik.org>
Subject: Re: Fwd: [PATCH #upstream-fixes 1/4] libata: fix device iteration bugs
Date: Mon, 10 Nov 2008 23:01:15 -0500 [thread overview]
Message-ID: <4919038B.8020407@rtr.ca> (raw)
In-Reply-To: <4918F1BC.2070602@kernel.org>
Tejun Heo wrote:
> Mark Lord wrote:
>>> On Michael's real old ata_piix, somehow the ERR bit is set on phantom
>>> device defeating our phantom device detection logic. We can relax
>>> phantom device condition but that increases the risk of misdetection on
>>> actual IDENTIFY errors. Any ideas how we can nicely work around this
>>> one?
>> ..
>>
>> Mmm.. I'm way out of the loop on this now,
>> so please pardon me suggesting things known not to work, but..
>>
>> 1. Pay attention to ATA status register on this chipset?
>> Eg. if it has BUSY, or reads 0x7f, then don't IDENTIFY?
>> 2. Check for device signature before trying IDENTIFY?
>> 3. Try a r/w test on the data register first, to see if there's
>> really hardware attached to it?
>
> We already do 1, 2 and 3. The problem with phantom device is that the
> existent device on the channel replies to acesses to the other
> non-existent device and the NODEV_HINT detection is the last line of
> defense which successfully evades all the other mechanisms. And now
> we have this controller/device combination which successfully tricks
> it too. :-(
..
Mmm.. but he's using "really old ata_piix" hardware, as in what Intel
once called the "Triton" (or Triton II) chipset. Which I wrote support
for in drivers/ide, way back when.. and we never had this problem.
Something weird here.
next prev parent reply other threads:[~2008-11-11 4:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6ca8fe89c868f95831328d31c27f9cdb@localhost>
2008-10-27 15:45 ` Fwd: [PATCH #upstream-fixes 1/4] libata: fix device iteration bugs Guntsche Michael
2008-11-10 6:52 ` Tejun Heo
2008-11-10 10:10 ` Michael Guntsche
2008-11-10 10:21 ` Tejun Heo
2008-11-10 15:07 ` Mark Lord
2008-11-11 2:45 ` Tejun Heo
2008-11-11 4:01 ` Mark Lord [this message]
2008-11-11 9:19 ` Sergei Shtylyov
2008-11-11 13:34 ` Michael Guntsche
2008-11-11 14:29 ` Mark Lord
2008-11-11 15:03 ` Guntsche Michael
2008-11-12 1:20 ` Mark Lord
2008-11-12 2:34 ` Tejun Heo
2008-11-12 7:22 ` Michael Guntsche
2008-11-12 8:15 ` Tejun Heo
2008-11-12 9:16 ` Michael Guntsche
2008-11-12 9:27 ` Tejun Heo
2008-11-12 9:43 ` Michael Guntsche
2008-11-12 9:48 ` Tejun Heo
2008-11-12 9:55 ` Michael Guntsche
2008-11-14 2:38 ` Mark Lord
2008-11-14 6:59 ` Michael Guntsche
2008-11-14 17:21 ` Mark Lord
2008-11-14 17:24 ` Mark Lord
2008-11-14 22:26 ` Guntsche Michael
2008-11-15 4:13 ` Mark Lord
2008-11-15 4:17 ` Mark Lord
2008-11-15 9:29 ` Guntsche Michael
2008-11-15 10:22 ` Guntsche Michael
2008-11-15 20:43 ` Mark Lord
2008-11-16 5:14 ` Tejun Heo
2008-11-16 5:49 ` Mark Lord
2008-11-16 8:41 ` Michael Guntsche
2008-11-16 9:15 ` Michael Guntsche
2008-11-16 10:48 ` Sergei Shtylyov
2008-11-16 11:23 ` Alan Cox
2008-11-11 14:27 ` Fwd: " Mark Lord
2008-11-11 14:34 ` Alan Cox
2008-11-12 1:18 ` Mark Lord
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=4919038B.8020407@rtr.ca \
--to=liml@rtr.ca \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=mike@it-loops.com \
--cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.