Bug 9320 - _GTM complains - PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object
_GTM complains - PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond ...
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: BIOS
All Linux
: P1 normal
Assigned To: Tejun Heo
:
Depends on:
Blocks: 9243 9530
  Show dependency treegraph
 
Reported: 2007-11-07 13:34 UTC by Hans de Bruin
Modified: 2007-12-20 15:37 UTC (History)
6 users (show)

See Also:
Kernel Version: Linux version 2.6.24-rc2
Tree: Mainline
Regression: ---


Attachments
config (45.46 KB, text/plain)
2007-11-07 13:36 UTC, Hans de Bruin
Details
dmesg (15.43 KB, text/plain)
2007-11-07 13:37 UTC, Hans de Bruin
Details
dmesg with pata disk (16.18 KB, text/plain)
2007-11-08 12:44 UTC, Hans de Bruin
Details
acpidump (111.43 KB, application/octet-stream)
2007-11-08 12:52 UTC, Hans de Bruin
Details
dmidecode (9.26 KB, text/plain)
2007-11-28 13:21 UTC, Hans de Bruin
Details
bug9320-dbg0.patch (11.79 KB, patch)
2007-11-30 02:36 UTC, Tejun Heo
Details | Diff
bug9320-dbg1.patch (12.79 KB, patch)
2007-11-30 02:37 UTC, Tejun Heo
Details | Diff
dbg0_dmesg (15.43 KB, text/plain)
2007-12-02 11:40 UTC, Hans de Bruin
Details
dbg1_dmesg (14.88 KB, text/plain)
2007-12-02 11:54 UTC, Hans de Bruin
Details
bug9320-acpi-blist.patch (13.91 KB, patch)
2007-12-03 20:28 UTC, Tejun Heo
Details | Diff
bug9320-acpi-blist_dmesg (14.73 KB, text/plain)
2007-12-05 02:44 UTC, Hans de Bruin
Details
bug9320-dbg2.patch (14.27 KB, patch)
2007-12-09 22:14 UTC, Tejun Heo
Details | Diff
bug9320-dbg2-dmesg (14.74 KB, text/plain)
2007-12-10 13:28 UTC, Hans de Bruin
Details
lspci -vvvxxx (58.33 KB, text/plain)
2007-12-11 11:47 UTC, Torsten Kaiser
Details
DSDT from Bios v0208 (173.80 KB, text/plain)
2007-12-11 12:00 UTC, Torsten Kaiser
Details
bug9320-dbg4.patch (20.28 KB, patch)
2007-12-11 17:28 UTC, Tejun Heo
Details | Diff
bug9320-dbg4-dmesg (15.30 KB, text/plain)
2007-12-13 21:55 UTC, Hans de Bruin
Details
bug9320-dbg5.patch (15.58 KB, patch)
2007-12-13 22:21 UTC, Tejun Heo
Details | Diff
bug9320-dbg6.patch (22.41 KB, patch)
2007-12-14 05:06 UTC, Tejun Heo
Details | Diff
bug9320-dbg6-dmesg (15.22 KB, text/plain)
2007-12-14 13:58 UTC, Hans de Bruin
Details

Description Hans de Bruin 2007-11-07 13:34:59 UTC
Most recent kernel where this bug did not occur: 
  I rebuild daily, if rebuild script does not fail. The last errorless boot
was on october 29. The first boot after this was october 31

Distribution: slack
Hardware Environment: 

VIA C7, CN700 IDE interface: VT82C586A/B/VT82C686/A/B/VT823x/A/C 
Diskless PXE boot

Software Environment:
Problem Description:

dmesg:
ata3: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf900 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf908 irq 15
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_] (Node c1c0b420), AE_AML_PACKAGE_LIMIT
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.CHN0._GTM] (Node c1c0b228), AE_AML_PACKAGE_LIMIT
ata3: ACPI get timing mode failed (AE 0x300d)
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_] (Node c1c0b420), AE_AML_PACKAGE_LIMIT
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.CHN1._GTM] (Node c1c0b330), AE_AML_PACKAGE_LIMIT
ata4: ACPI get timing mode failed (AE 0x300d)
Comment 1 Hans de Bruin 2007-11-07 13:36:55 UTC
Created attachment 13445 [details]
config
Comment 2 Hans de Bruin 2007-11-07 13:37:58 UTC
Created attachment 13446 [details]
dmesg
Comment 3 Anonymous Emailer 2007-11-07 14:07:58 UTC
Reply-To: akpm@linux-foundation.org

> On Wed,  7 Nov 2007 13:35:00 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9320
> 
>            Summary: PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is
>                     beyond end of object
>            Product: ACPI
>            Version: 2.5
>      KernelVersion: Linux version 2.6.24-rc2
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: acpi_other@kernel-bugs.osdl.org
>         ReportedBy: bruinjm@xs4all.nl
> 
> 
> Most recent kernel where this bug did not occur: 
>   I rebuild daily, if rebuild script does not fail. The last errorless boot
> was on october 29. The first boot after this was october 31
> 
> Distribution: slack
> Hardware Environment: 
> 
> VIA C7, CN700 IDE interface: VT82C586A/B/VT82C686/A/B/VT823x/A/C 
> Diskless PXE boot
> 
> Software Environment:
> Problem Description:
> 
> dmesg:
> ata3: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf900 irq 14
> ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf908 irq 15
> ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is
> beyond end of object [20070126]
> ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_]
> (Node c1c0b420), AE_AML_PACKAGE_LIMIT
> ACPI Error (psparse-0537): Method parse/execution failed
> [\_SB_.PCI0.PATA.CHN0._GTM] (Node c1c0b228), AE_AML_PACKAGE_LIMIT
> ata3: ACPI get timing mode failed (AE 0x300d)
> ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is
> beyond end of object [20070126]
> ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PATA.GTM_]
> (Node c1c0b420), AE_AML_PACKAGE_LIMIT
> ACPI Error (psparse-0537): Method parse/execution failed
> [\_SB_.PCI0.PATA.CHN1._GTM] (Node c1c0b330), AE_AML_PACKAGE_LIMIT
> ata4: ACPI get timing mode failed (AE 0x300d)
> 

Seems to be another post-2.6.23 regression.  Is it an acpi thing or an ata
thing, of just something which the new acpi+ata stuff exposed??

Comment 4 Anonymous Emailer 2007-11-07 14:25:11 UTC
Reply-To: mjg59@srcf.ucam.org

On Wed, Nov 07, 2007 at 02:07:54PM -0800, Andrew Morton wrote:

> Seems to be another post-2.6.23 regression.  Is it an acpi thing or an ata
> thing, of just something which the new acpi+ata stuff exposed??

I suspect that this is just because acpi is enabled by default on ata 
now. Is it actually causing any problems?

Comment 5 Robert Moore 2007-11-07 15:18:47 UTC
Please post the acpidump for this machine.
Comment 6 Hans de Bruin 2007-11-08 12:43:27 UTC
I's not causing any problems, the dmesg just looks different. Just to be sure I attached a disk, and it can be read from an written to.
Comment 7 Hans de Bruin 2007-11-08 12:44:37 UTC
Created attachment 13470 [details]
dmesg with pata disk
Comment 8 Hans de Bruin 2007-11-08 12:52:53 UTC
Created attachment 13471 [details]
acpidump
Comment 9 Robert Moore 2007-11-08 14:34:27 UTC
Here is the offending code (called from _GTM):

Method (GTM, 6, Serialized)
{
...
    Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg0, MTR, 
        0x00, 0x00), Local6)
    Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Local6)), 
        Local7)

It appears to me that the Match is failing and returning 0xFFFFFFFF, which in turn is blindly used as an index into a package in the second Store statement.

I seem to remember there was an issue where _STM (Set Timing Mode) was not being called before _GTM (in the ata driver), and things within the ASL/AML were not getting initialized properly.
Comment 10 Hans de Bruin 2007-11-11 02:45:56 UTC
Should I reasign this bug to:

product    : io/storage
component  : ide

?
Comment 11 Torsten Kaiser 2007-11-11 12:22:14 UTC
I see the same problem:
[   44.260000] scsi8 : pata_amd
[   44.260000] scsi9 : pata_amd
[   44.260000] ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
[   44.260000] ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
[   44.460000] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is beyond end of object [20070126]
[   44.460000] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTM_] (Node ffff81010031aa20), AE_AML_PACKAGE_LIMIT
[   44.460000] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0._GTM] (Node ffff81010031a7c0), AE_AML_PACKAGE_LIMIT
[   44.460000] ata9: ACPI get timing mode failed (AE 0x300d)
[   44.470000] ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
[   44.470000] ata9.01: 490234752 sectors, multi 16: LBA48
[   44.470000] ata9.01: limited to UDMA/33 due to 40-wire cable
[   44.510000] ata9.01: configured for UDMA/33
[   44.510000] ata10: port disabled. ignoring.

But my hardware is nothing like Hans':
It's an Opteron board with an nVidia MCP55 chipset, so this might be BIOS specific?
dmidecode says:
Vendor: American Megatrends Inc.
BIOS Revision: 8.12

Except for the message the drive works normal. Even the detection of the 40-wire cable is correct.

Form the disassembled ACPI:
             Device (CHN0)
             {
[snip]
                  Method (_GTM, 0, NotSerialized)
                  {
                      Store ("GTM_CHN0", Debug)
                      Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT))
                  }
[snip]
             Method (GTM, 6, Serialized)
             {
[snip]
                  Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg0, MTR,
                        Zero, Zero), Local6)
                  Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)),
                        Local7)
                  Store (Local7, DMA0)
                  Store (Local7, PIO0)
                  Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg3, MTR,
                        Zero, Zero), Local6)
                  Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)),
                        Local7)
                  Store (Local7, DMA1)
                  Store (Local7, PIO1)

... seems to be the same code.

Arg0 and Arg0 aka PMPT and PSPT seem only to be used in Method (_STM, 3, NotSerialized) as far as I can see...
Comment 12 Tejun Heo 2007-11-11 19:32:10 UTC
That was calling _GTF without calling _STM first.  _GTM doesn't have any prerequisite (it can't).  Can someone familiar with ACPI tell me why the method is failing?  At any rate, libata should work fine regardless of ACPI failures.  Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid those annoying messages during boot.
Comment 13 Fu Michael 2007-11-14 00:21:51 UTC
dup of bug# 7907? assign to yakui for investigation...
Comment 14 Hans de Bruin 2007-11-14 01:39:47 UTC
(In reply to comment #11)
> I see the same problem:
>...
> It's an Opteron board with an nVidia MCP55 chipset, so this might be BIOS
> specific?
> dmidecode says:
> Vendor: American Megatrends Inc.
> BIOS Revision: 8.12

BIOS Information
        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 05/18/2007
Comment 15 Tejun Heo 2007-11-21 22:45:55 UTC
Yakui, any ideas?
Comment 16 ykzhao 2007-11-26 23:04:00 UTC
The root cause of this bug is caused by calling _GTM. 
And according to ACPI 3.0 spec, there is no prerequisite for calling _GTM. (The _GTM method will be called to get the current channel time settings).
Maybe it will be appropriate that the ata is no longer associated with ACPI(setting libata_noacpi to 1) when the machine is detected.
Thanks. 
Comment 17 ykzhao 2007-11-27 01:02:30 UTC
This bug is not duplicate of bug 7907. 
The root cause of bug 7907 is that _GTF is called before calling _STM. And this bug is caused by the uncorrect _GTM function definition in BIOS.
The bug can be fixed by disable acpi for ATA when the machine is detected in the ATA blacklist.(setting libata_noacpi to 1).

Thanks.
Comment 18 Tejun Heo 2007-11-27 16:53:19 UTC
Okay, time to start yet another blacklist I guess.  Hans de Brin, please report the result of 'dmidecode'.  Thanks.
Comment 19 Fu Michael 2007-11-27 23:48:42 UTC
Hans de Brin, could you please post dmidecode info..thanks..
Comment 20 Hans de Bruin 2007-11-28 13:21:44 UTC
Created attachment 13782 [details]
dmidecode
Comment 21 Fu Michael 2007-11-28 23:32:56 UTC
hi, Tejun, would  you please help to add the quirk?
Comment 22 Tejun Heo 2007-11-28 23:44:19 UTC
I'm brewing patches.  I'll soon post the patch.  Please standby a bit.  Thanks.
Comment 23 Tejun Heo 2007-11-30 02:36:38 UTC
Created attachment 13806 [details]
bug9320-dbg0.patch

Please apply this patch on top of 2.6.24-rc3 and report kernel boot log.
Comment 24 Tejun Heo 2007-11-30 02:37:19 UTC
Created attachment 13807 [details]
bug9320-dbg1.patch

After that, unapply dbg0 and apply this one and report the boot log.  Thanks.
Comment 25 Hans de Bruin 2007-12-02 11:40:56 UTC
Created attachment 13832 [details]
dbg0_dmesg
Comment 26 Hans de Bruin 2007-12-02 11:54:39 UTC
Created attachment 13833 [details]
dbg1_dmesg
Comment 27 Tejun Heo 2007-12-03 20:28:02 UTC
Created attachment 13843 [details]
bug9320-acpi-blist.patch

Please test this patch and report boot log.  Thanks.
Comment 28 Hans de Bruin 2007-12-05 02:44:43 UTC
Created attachment 13860 [details]
bug9320-acpi-blist_dmesg

Since I am about to move, all spare pata disks are in boxes (on the bottom of the pile). so I did not test any disk actions.
Comment 29 Tejun Heo 2007-12-05 04:26:40 UTC
That's good enough.  Thanks.
Comment 30 Len Brown 2007-12-07 21:46:47 UTC
For all of the systems that get added to this blacklist,
it would be good to archive their acpidump here.
For we might discover by examining the acpidump
that there is some magic "Windows bug compatibility"
sequence of hoops that Linux could instead jump through
in order to run on the installed base of BIOS.
Comment 31 Robert Hancock 2007-12-09 15:16:39 UTC
Yes, can the reporters here please post their decompiled ACPI DSDT AML code as an attachment (as Torsten posted partially already)?
Comment 32 Robert Hancock 2007-12-09 19:23:29 UTC
We've found one case where the _GTM method execution fails if the PATA port has no devices connected due to register values on the controller in that case that the ASL code doesn't handle. This is likely something similar, although a different cause since the port is not empty here. Torsten, can you post your full DSDT ASL dump as well as the output of "lspci -vvvxxx" ?
Comment 33 Tejun Heo 2007-12-09 22:14:23 UTC
Created attachment 13932 [details]
bug9320-dbg2.patch

Hans, please test this patch.  It seems we won't need the blacklist after all.
Comment 34 tosn00j02 2007-12-10 10:14:27 UTC
FYI bug9320-dbg2.patch fixes hibernation on my Shuttle SK41G (pata_via) that previously failed without libata.noacpi=1.
Comment 35 Hans de Bruin 2007-12-10 13:28:18 UTC
Created attachment 13953 [details]
bug9320-dbg2-dmesg
Comment 36 Tejun Heo 2007-12-10 17:56:04 UTC
Cool, so it was the same problem.  Oh.. VIA.

Torsten, can you please post the DSDT ASL Robert asked?
Comment 37 Torsten Kaiser 2007-12-11 11:47:23 UTC
Created attachment 13976 [details]
lspci -vvvxxx

Didn't had time to check my mail, so I just only now read your requests.

Attached lspci is from 2.6.24-rc3-mm2

I did see only see the ACPI error message with 2.6.23-mm1, both 2.6.24-rc2-mm1 and 2.6.24-rc3-mm2 worked without it.

Bevor 2.6.23-mm1 I see: ata9: ACPI get timing mode failed (AE 0x1001)
On 2.6.23-mm1 I see: ata9: ACPI get timing mode failed (AE 0x300d)
Both 2.6.24-rc's say:
ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
ata9.01: 490234752 sectors, multi 16: LBA48
ata9: nv_mode_filter: 0x7f39f&0x701f->0x701f, BIOS=0x7000 (0xc00000) ACPI=0x701f (900:60:0x14)
ata9.01: configured for UDMA/33

All 2.6.23 correctly complained: ata9.01: limited to UDMA/33 due to 40-wire cable

DSDT will follow...
Comment 38 Torsten Kaiser 2007-12-11 12:00:08 UTC
Created attachment 13980 [details]
DSDT from Bios v0208

(In reply to comment #32)
> We've found one case where the _GTM method execution fails if the PATA port has
> no devices connected due to register values on the controller in that case that
> the ASL code doesn't handle.

I also have only one device attached to the pata port of the MCP55

Hmm... I just noticed this:
ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
[snip]
ata9.01: configured for UDMA/33
ata10: port disabled. ignoring

Shouldn't the second/slave drive be ata9.02?
This board does not have a second physical pata port and I think even the chipset only has one...

DSDT attached, I hope, I extracted/disassembled it correctly.
Comment 39 Robert Hancock 2007-12-11 16:06:32 UTC
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.
Comment 40 Tejun Heo 2007-12-11 17:09:21 UTC
Setting mode to PIO0 is done right after reset because we don't know the drive state at that point.  This caused problem w/ cable detection using ACPI or BIOS setting because programming PIO0 on pata_amd clobbers DMA mode setting too and we lose BIOS/ACPI setting before looking at them, so the fix was to cache _GTM value while initializing controller before initiating probing sequence (init_gtm).

It seems that Torsten's problem will be fixed by init_gtm but unfortunately that thing is queued for 2.6.25 merge as it involves a bunch of other changes.  I guess we'll have to backport init_gtm part to fix this one.  I'll get to it.
Comment 41 Tejun Heo 2007-12-11 17:28:55 UTC
Created attachment 13986 [details]
bug9320-dbg4.patch

Please apply the attached patch on top of -rc4 and report the result.  Thanks.
Comment 42 Torsten Kaiser 2007-12-12 11:33:33 UTC
OK, I tested with vanilla 2.6.24-rc4 and the dbg4 patch

relevant parts of the vanilla 2.6.24-rc4 dmesg:
ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFF) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTM_] (Node ffff81007ff188c0), AE_AML_PACKAGE_LIMIT
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0._GTM] (Node ffff81007ff18660), AE_AML_PACKAGE_LIMIT
ata9: ACPI get timing mode failed (AE 0x300d)
ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
ata9.01: 490234752 sectors, multi 16: LBA48
ata9.01: limited to UDMA/33 due to 40-wire cable
ata9.01: configured for UDMA/33
ata10: port disabled. ignoring.

with dbg4 applied the following lines are added to the dmesg:
+ata3: XXX skipping _GTM on empty channel
+ata4: XXX skipping _GTM on empty channel
+ata5: XXX skipping _GTM on empty channel
+ata6: XXX skipping _GTM on empty channel
+ata7: XXX skipping _GTM on empty channel
+ata8: XXX skipping _GTM on empty channel
+ata9: XXX skipping _GTM on empty channel
+ata10: XXX skipping _GTM on empty channel
The above ACPI error messages disappear, the detection is still identical.
Even if the XXX message claims that ata9 is empty the drive is still getting detected correctly...

Looking at the patch I think it is missing the addition of the ATA_FLAG_XXX to pata_amd, as I do not use pata_via.
But even with this flag added to all ata_port_info's I got no further output.
Comment 43 Torsten Kaiser 2007-12-12 12:27:39 UTC
PS: I just seen that the detection empty/not empty seems to be completely busted for the MCP55, as the ata devices do not start with ata0

ata1+2: sata_sil24 with two drives
ata3..8: sata_nv, only one port has a drive
ata9: pata_amd, one drive
ata10: ??? BIOS bug? Did someone think that there should always be two IDE channels?

ata3: XXX skipping _GTM on empty channel
ata4: XXX skipping _GTM on empty channel
ata3: SATA max UDMA/133 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 23
ata4: SATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 23
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133
ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata3.00: configured for UDMA/133
ata4: SATA link down (SStatus 0 SControl 300)

The drive on port ata3 works normal...
Comment 44 Tejun Heo 2007-12-13 20:17:32 UTC
<rant>Gees... the initial _GTM value should be collected after device presence detection (for crap VIA ACPI implementations) but before configuration is changed.</rant>

Will prep another patch soon.  Thanks for you patience.
Comment 45 Tejun Heo 2007-12-13 20:26:24 UTC
Okay, we can't do that.  I think what we should do here is telling the ACPI interpreter to shut up even if something blows up.  I'm forwarding patches upstream now.  Other than annoying messages, everything should work fine.
Comment 46 Robert Hancock 2007-12-13 20:30:28 UTC
I thought that Torsten was saying that the ACPI errors went away with the latest patch?
Comment 47 Tejun Heo 2007-12-13 20:39:22 UTC
Yeah, but that would break acpi cable detection for pata_amd.  I'll write about it in detail to lkml, linux-ide and linux-acpi and cc you.  Thanks.
Comment 48 Hans de Bruin 2007-12-13 21:55:28 UTC
Created attachment 14014 [details]
bug9320-dbg4-dmesg
Comment 49 Tejun Heo 2007-12-13 22:21:24 UTC
Created attachment 14015 [details]
bug9320-dbg5.patch

Hans, can you please give a shot at this patch?  This is the final revision and already posted for inclusion in mainline.  You might see evaluation failure messages but everything else should be fine.

Thanks.
Comment 50 Tejun Heo 2007-12-14 05:06:44 UTC
Created attachment 14030 [details]
bug9320-dbg6.patch

Okay, one more revision.  This should be it.  Please test this.

Thanks.
Comment 51 Hans de Bruin 2007-12-14 13:58:59 UTC
Created attachment 14043 [details]
bug9320-dbg6-dmesg
Comment 52 Tejun Heo 2007-12-14 15:11:14 UTC
Great, it works.  Thanks.
Comment 53 Tejun Heo 2007-12-14 22:18:50 UTC
Patchset posted.  Resolving as CODE_FIX.  Thanks a lot for all the testing.

  http://thread.gmane.org/gmane.linux.ide/26379
Comment 54 Rafael J. Wysocki 2007-12-20 15:37:08 UTC
Fixed by:

commit ededa4d396b15c282aa60d6aacddfc07f0142dbf
Merge: 64396ac... 140b5e5...
Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
Date:   Mon Dec 17 19:29:32 2007 -0800

    Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ededa4d396b15c282aa60d6aacddfc07f0142dbf

Note You need to log in before you can comment on or make changes to this bug.