From: Tejun Heo <htejun@gmail.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
linux-acpi@vger.kernel.org, Jeff Garzik <jeff@garzik.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: ATA ACPI needs "Mr interpreter, would you please shut up?" flag
Date: Fri, 14 Dec 2007 15:28:47 +0900 [thread overview]
Message-ID: <4762229F.8020900@gmail.com> (raw)
In-Reply-To: <4762129F.6060209@shaw.ca>
Robert Hancock wrote:
>> Problem is that _GTM implementation on certain BIOSen crap themselves if
>> invoked on empty channels. However, as written above, because initial
>> _GTM caching is done before any actual operation is performed on the
>> port, libata can't determine whether the port is occupied or not when
>> trying to cache _GTM result. Unfortunately, VIA PATA is on both
>> categories - it needs _GTM caching but can't cope with _GTM invocation
>> on empty ports. Yay!
>
> I seem to have lost the thread/bug report where we decided that one
> board always choked on an empty channel. Maybe it's not that and it's
> just another case of the same issue where our resetting default timing
> values on the controller before calling _GTM would choke the _GTM method?
Could be. Hans' machine on bug 9320 is the affected one (PATA on via
CN700). I asked him to test the final version. If it indeed is caused
by the same problem, there won't be evaluation failures.
Anyways, table-based implementations like the NVidia and VIA ones are
bound to fail on certain conditions. libata reconfigures transfer mode
aggressively under certain failure conditions and _GTM invocation will
fail if the port is in a mode which is not on ACPI's mode table (which
doesn't seem to be too comprehensive anyway). So, there's always
possibility of _GTM failure for those boards, which in turn can fail
_GTF evaluation.
As _GTM, _STM and _GTF aren't strictly necessary for operation anyway, I
think it's better to print ATA ACPI evaluation failure messages using
KERN_DEBUG.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-12-14 6:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 5:02 ATA ACPI needs "Mr interpreter, would you please shut up?" flag Tejun Heo
2007-12-14 5:02 ` Tejun Heo
2007-12-14 5:20 ` Robert Hancock
2007-12-14 6:28 ` Tejun Heo [this message]
2007-12-14 12:17 ` Tejun Heo
2007-12-14 12:17 ` Tejun Heo
2007-12-14 14:02 ` 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=4762229F.8020900@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hancockr@shaw.ca \
--cc=jeff@garzik.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.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 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.