http://bugzilla.kernel.org/show_bug.cgi?id=9320
------- Comment #39 from [EMAIL PROTECTED] 2007-12-11 16:06 -------
OK. So inside GTM, we do this:
Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg0, MTR,
Zero, Zero), Local6)
In other words, find the table inside TIM0 with index 1, then look up the value
in Arg0 in that table and store the found index in Local6. For CHN0 (the
failing one), this comes from PMPT, which is part of an operation region in the
controller's PCI config space. PMPT comes from config address 0x5B, whose value
in your config space dump is 0x99. Now the table with index 1 in TIM0 contains:
Package (0x05)
{
0x11,
0x20,
0x22,
0x47,
0xA8
},
0x99 is NOT in this table, and so Local6 gets 0xFFFFFFFF (not found), which the
code then uses to look up as the index into the table with index 0 in TIM0
(which seems to be the corresponding output cycle time values):
Package (0x05)
{
0x3C,
0x78,
0xB4,
0xF0,
0x0384
},
and causes the interpreter to blow up.
Question is how the value 0x99 got there. According to the AMD-766 IDE
controller docs (the closest thing we have to specs I think, except that NVIDIA
has their registers 16 bytes ahead), address 0x5B (which matches 0x4B in the
document) is the EIDE Controller Drive Timing Control value:
"The value in each 4-bit field, plus one, specifies a time period in 30
nanosecond PCI clocks. Note: The default state, A8h, results in a recovery time
of 270ns and an active pulse width of 330ns for a 30ns PCI clock (total cycle
time = 600ns) which corresponds to ATA PIO Mode 0."
So 0x99 means 300ns active and 300ns recovery time, or 600ns cycle time, which
I guess is PIO mode 0. There is no way the BIOS set primary master timing to
that value since the drive should be UDMA/133 capable. Tejun, wasn't there a
problem fixed somewhere in pata_amd where we would clobber the timing mode to
PIO0 before calling _GTM?
It seems this BIOS implementation is very non-tolerant of the controller having
been poked with values other than what it expects. (My Asus A8N-SLI Deluxe has
the same IDE controller, but I recall its _GTM implementation calculated the
actual values from the register settings rather than using a lookup table - a
much more robust implementation.) Calling _GTM on this BIOS if timings have
been modified (other than with _STM) seems unreliable unless the exact settings
the BIOS expects to be used are set. The approach used by pata_acpi (only use
ACPI methods to modify the timings) would likely be safer on such a system.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
