Hello, all.
During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there
have been a lot of regression reports stemming from it. I have patchset
ready to fix most of the problems. With these patches applied, libata
should be able to cope with most failures pretty well. There is one
remaining issue tho.
libata caches the result of _GTM during controller for later use. The
primary use is to peek at how BIOS configured the controller. Some
controllers (pata_via and pata_amd) lack proper cable detection and BIOS
configured values are used as reference. This caching is done before
any other operation is performed on the port to avoid caching corrupted
data.
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!
libata doesn't need _GTM to succeed. If the information can be
acquired, it will use it. If not, it will do just fine without it and
for pata_via, this works perfectly well because the information is
available when actually needed (device present). The only problem is
that _GTM evaluation failure will print ugly messages during boot.
We can twist ATA probing such that _GTM caching is done between device
detection but before mode is reset to PIO0 but I don't think that's a
good idea for two reasons. 1. That would require pushing PIO0
enforcement after reset. IMHO, it's wiser to put controller into PIO0
before initiating reset. 2. Presence detection sometimes requires
actually issuing IDENTIFY DEVICE command which in turn needs PIO0
configuration.
So, I think the logical solution here is to tell ACPI interpreter that
the _GTM evaluation may fail and there's no need to alert the user about
that. Maybe printing with KERN_DEBUG is good enough. libata can print
additional message after failure (again w/ KERN_DEBUG) telling the user
that there's nothing to worry about.
Thanks.
--
tejun
Tejun Heo wrote:
> Hello, all.
>
> During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there
> have been a lot of regression reports stemming from it. I have patchset
> ready to fix most of the problems. With these patches applied, libata
> should be able to cope with most failures pretty well. There is one
> remaining issue tho.
>
> libata caches the result of _GTM during controller for later use. The
> primary use is to peek at how BIOS configured the controller. Some
> controllers (pata_via and pata_amd) lack proper cable detection and BIOS
> configured values are used as reference. This caching is done before
> any other operation is performed on the port to avoid caching corrupted
> data.
>
> 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?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
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
I take it back. I found how to satisfy neurotic BIOSen.
Thanks.
--
tejun
Tejun Heo wrote:
> I take it back. I found how to satisfy neurotic BIOSen.
..
Aaaa.. excellent!