Opened 12 years ago
Closed 12 years ago
#554 closed defect (fixed)
Wrong routing of timer interupt
Reported by: | yoda | Owned by: | David Azarewicz |
---|---|---|---|
Priority: | major | Milestone: | Feedback pending |
Component: | ACPI PSD | Version: | 3.21.03 |
Keywords: | Cc: | yoda |
Description
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.
Change History (6)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
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.
comment:3 by , 12 years ago
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.
comment:5 by , 12 years ago
Milestone: | Release Version 4.0.0 → Feedback pending |
---|
The /WA switch in versions 3.21.04 and later has a mechanism to work around this defect in the ACPI tables.
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
No response from reporter. Fixed in version 3.21.04 and later.
BTW; David I assume you can reproduce this on your equal MoBo, so I didn't add any logs or else to this ticket.