Wrong routing of timer interupt

[yoda]

MoBo: Asus A8N SLI Premium

Running TMRTEST:

G:\ecs\bin>tmrtest.exe rc=0 Resolution:1193167 Elapsed 0 sec. Must be 0 Elapsed 0 sec. Must be 2 Elapsed 0 sec. Must be 4 Elapsed 0 sec. Must be 6 Elapsed 15460320368992 sec. Must be 8 Elapsed 0 sec. Must be 10 Elapsed 0 sec. Must be 12 Elapsed 0 sec. Must be 14 Elapsed 0 sec. Must be 16 Elapsed 0 sec. Must be 18 Elapsed 0 sec. Must be 20 Elapsed 0 sec. Must be 22 Elapsed 0 sec. Must be 24 Elapsed 15460320368992 sec. Must be 26 Elapsed 15460320368992 sec. Must be 28

---

This MoBo needed the /TMR parameter with the older ACPI drivers, to avoid this problem.

[yoda]

BTW; David I assume you can reproduce this on your equal MoBo, so I didn't add any logs or else to this ticket.

[David Azarewicz]

It appears that there is an invalid entry in the MADT on this system. It looks like the vendor just copied a generic ACPI and did not make sure it actually matched the hardware they built.

The PSD is correctly processing the information from the MADT. There is clearly an entry regarding this interrupt in the MADT that is wrong and that is what is causing the problem. Therefore the problem is in the MADT and not in the PSD.

The most correct solution is to fix the ACPI tables, specifically to remove the incorrect entry in the MADT. Since the MADT is dynamically built by the BIOS there may be another solution and more investigation will be required to determine if there are other solutions.

[yoda]

Well, as mentioned, the /TMR switch fixed this issue in the Pavels builds. I don't know if it only worked for this MoBo, or it was a more generic workaround.

The A8N-? series from Asus did indeed give a lot of different feedback about ACPI from all the users - using the different versions - over the years.

Maybe they just used 1 common BIOS for alle the different (hw) versions.

Anyway, thanx for the the explanation - really nice to know the 'real' reasons for the problems.

Just out of curiosity - have you figured out why this system doen's work with OS2APIC ? Not that I need it - as ACPI has worked since v 1.x for this, just wondering.

[Yoda ACPI]

Tested with latest ACPI 3.21.03 - no change

[David Azarewicz]

The /WA switch in versions 3.21.04 and later has a mechanism to work around this defect in the ACPI tables. Specifically /WA=II0O. See the docs.

[David Azarewicz]

No response from reporter. Fixed in version 3.21.04 and later.