Opened 7 years ago

Closed 6 years ago

#554 closed defect (fixed)

Wrong routing of timer interupt

Reported by: yoda Owned by: dazarewicz
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 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by dazarewicz

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 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by Yoda

  • Version changed from 3.20.04 to 3.21.03

Tested with latest ACPI 3.21.03 - no change

comment:5 Changed 6 years ago by dazarewicz

  • Milestone changed from Release Version 4.0.0 to Feedback pending

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.

Last edited 6 years ago by dazarewicz (previous) (diff)

comment:6 Changed 6 years ago by dazarewicz

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.