As additional input consider the drawing below from Multiprocessor Specification 1.4. According to this drawing the SMI# signal are directly connected to the CPUs. Some sources on internet says that the error interrupts are generated by the I/O APIC, but since there are no SMI# connection external to the CPUs, how can the internal chipset SMI# generate an error interrupt for each CPU on periodic events?
How are the APICs routed in Bay Trail? Perhaps there are some chipset register for the settings as the PMU may be an external source of SMI#?
Thanks for your updates.
The information that may help you is stated in the erratum VLI54, on page 30 of the Intel(R) Atom(TM) Processor E3800 Product Family Specification Update.
Please let us know if this information is useful to you.
Unfortunately it doesn't help me. The thing is that when the SMM periodic timer is enabled a SMI will be generated when the period expires. The default period is 64 seconds. When the timer expires the SMI will trigger all CPUs to enter the SMM. However, as a side effect the I/O APIC error interrupt will also be triggered for each CPU, causing 4 interrupts for each SMI.
The I/O APIC error interrupt may also be triggered by other SMIs, but in my case the only the SMM periodic timer is active when Linux is running. It's used for monitoring CPU temperatures when ACPI is enabled. When active it triggers a SMI every minute and thus every minute the Linux ERR counter in proc/interrupts is incremented by 4, which is the number of cores in the E3845 board I use.
So the question is, how can I use chipset SMIs without triggering I/O APIC errors? As I assume that Linux does a good job programming the local APICs and the I/O APIC, I think the problem needs to be solved on the firmware level.