High Interrupt Latency - SMM?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

QNX 6.2.0
x86 (NS Geode GX-1 300 MHz) - Advantech PCM-3350 PC-104 card
DIO card using IRQ5

I’m seeing typical interrupt latencies that are quite reasonable (10’s of us
for the scope trace setup I’ve got). However, occasionally, I see it stretch
out to up to 300 us. Sometimes it occurs before my handler can toggle the
scope trace output, other times it clearly occurs during the handler, which
runs at priority 60.

I’ve removed all non-essentials from the system to eliminate sources of
latency - no package file system, no io-net, no serial ports, etc. I’m down
to two candidates - timer interrupt or SMM. Based on my prior experience I
don’t believe it to be the timer interrupt, which leaves SMM. SMM is used by
this CPU, but I’ve not yet uncovered all the details. Power management is
disabled in the BIOS (I know that doesn’t guarantee anything).

Is there any way to confirm the source of this latency? Is there any place
to probe that would show SMM activity?

Thanks,

Marty Doane
Siemens Dematic

2

You could cut the SMM pin on the chip? :v)

Marty Doane <martin.doane@siemens.com> wrote:

QNX 6.2.0
x86 (NS Geode GX-1 300 MHz) - Advantech PCM-3350 PC-104 card
DIO card using IRQ5

I’m seeing typical interrupt latencies that are quite reasonable (10’s of us
for the scope trace setup I’ve got). However, occasionally, I see it stretch
out to up to 300 us. Sometimes it occurs before my handler can toggle the
scope trace output, other times it clearly occurs during the handler, which
runs at priority 60.

I’ve removed all non-essentials from the system to eliminate sources of
latency - no package file system, no io-net, no serial ports, etc. I’m down
to two candidates - timer interrupt or SMM. Based on my prior experience I
don’t believe it to be the timer interrupt, which leaves SMM. SMM is used by
this CPU, but I’ve not yet uncovered all the details. Power management is
disabled in the BIOS (I know that doesn’t guarantee anything).

Is there any way to confirm the source of this latency? Is there any place
to probe that would show SMM activity?

Thanks,

Marty Doane
Siemens Dematic


–
cburgess@qnx.com

3

Armin Steinhoff <a-steinhoff@web.de> wrote:

Colin Burgess wrote:
You could cut the SMM pin on the chip? :v)

… but open a window before you are doings so.
A burning CPU doesn"t smell so good > :slight_smile:

“The vital consituent in computer chips is smoke - if it leaks out,
then they stop working!” - Unknown

\

cburgess@qnx.com

4

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:b333io$1v9$1@nntp.qnx.com…

Armin Steinhoff <> a-steinhoff@web.de> > wrote:
Colin Burgess wrote:
You could cut the SMM pin on the chip? :v)

… but open a window before you are doings so.
A burning CPU doesn"t smell so good > :slight_smile:

“The vital consituent in computer chips is smoke - if it leaks out,
then they stop working!” - Unknown

That’s based on an old story about Lucas Electrics, a British manufacturer
known for it’s flakey electrical systems in cars and motorcycles. Here it
is below:

Electrical Theory

by Joseph Lucas

Positive ground depends upon proper circuit functioning, which is the
transmission of negative ions by retention of the invisible spectral
manifestation known as “Smoke”.

Smoke is the thing that makes electrical circuits work; we know this to be
true because every time one lets the smoke out of the electrical system, it
stops working. This can be verified repeatedly through empirical testing.

When, for example, the smoke escapes from an electrical component (like,
say, a Lucas Voltage Regulator), it will be observed that the component
stops working. The function of the wire harness is to carry the smoke from
one devices to another; when the wire harness “springs a leak” and lets all
the smoke out of the system, nothing works afterwards. Starter motors were
frowned upon in British motorcycles for some time, largely because they
consume large quantities of smoke, requiring very large wires.

It has been noted that Lucas components are possibly more prone to
electrical leakage than Bosch or generic Japanese electrics. Experts point
out that this is because Lucas is British and all things British leak.
British engines leak oil, shock absorbers, hydraulic forks and disc brakes
leak fluid. British tyres leak air and the British Defense establishment
leaks secrets… so, naturally, British electrics leak smoke.

From the basic concept of electrical transmission of energy in the form of
smoke, a better understanding of the mysteries of electrical components,
especially those of Lucas manufacture, is gained by the casual user.

DH

5

Colin Burgess wrote:

You could cut the SMM pin on the chip? :v)

… but open a window before you are doings so.
A burning CPU doesn"t smell so good :slight_smile:

Armin

Marty Doane <> martin.doane@siemens.com> > wrote:

QNX 6.2.0
x86 (NS Geode GX-1 300 MHz) - Advantech PCM-3350 PC-104 card
DIO card using IRQ5


I’m seeing typical interrupt latencies that are quite reasonable (10’s of us
for the scope trace setup I’ve got). However, occasionally, I see it stretch
out to up to 300 us. Sometimes it occurs before my handler can toggle the
scope trace output, other times it clearly occurs during the handler, which
runs at priority 60.


I’ve removed all non-essentials from the system to eliminate sources of
latency - no package file system, no io-net, no serial ports, etc. I’m down
to two candidates - timer interrupt or SMM. Based on my prior experience I
don’t believe it to be the timer interrupt, which leaves SMM. SMM is used by
this CPU, but I’ve not yet uncovered all the details. Power management is
disabled in the BIOS (I know that doesn’t guarantee anything).


Is there any way to confirm the source of this latency? Is there any place
to probe that would show SMM activity?


Thanks,

Marty Doane
Siemens Dematic


\

6

I sometimes think that Kris’ tertiary study consisted mainly of research
computer folklore! :v)

Kris Warkentin <kewarken@qnx.com> wrote:

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:b333io$1v9$> 1@nntp.qnx.com> …
Armin Steinhoff <> a-steinhoff@web.de> > wrote:
Colin Burgess wrote:
You could cut the SMM pin on the chip? :v)

… but open a window before you are doings so.
A burning CPU doesn"t smell so good > :slight_smile:

“The vital consituent in computer chips is smoke - if it leaks out,
then they stop working!” - Unknown

That’s based on an old story about Lucas Electrics, a British manufacturer
known for it’s flakey electrical systems in cars and motorcycles. Here it
is below:

Electrical Theory

by Joseph Lucas

Positive ground depends upon proper circuit functioning, which is the
transmission of negative ions by retention of the invisible spectral
manifestation known as “Smoke”.

Smoke is the thing that makes electrical circuits work; we know this to be
true because every time one lets the smoke out of the electrical system, it
stops working. This can be verified repeatedly through empirical testing.

When, for example, the smoke escapes from an electrical component (like,
say, a Lucas Voltage Regulator), it will be observed that the component
stops working. The function of the wire harness is to carry the smoke from
one devices to another; when the wire harness “springs a leak” and lets all
the smoke out of the system, nothing works afterwards. Starter motors were
frowned upon in British motorcycles for some time, largely because they
consume large quantities of smoke, requiring very large wires.

It has been noted that Lucas components are possibly more prone to
electrical leakage than Bosch or generic Japanese electrics. Experts point
out that this is because Lucas is British and all things British leak.
British engines leak oil, shock absorbers, hydraulic forks and disc brakes
leak fluid. British tyres leak air and the British Defense establishment
leaks secrets… so, naturally, British electrics leak smoke.

From the basic concept of electrical transmission of energy in the form of
smoke, a better understanding of the mysteries of electrical components,
especially those of Lucas manufacture, is gained by the casual user.

DH

–
cburgess@qnx.com

7

Marty Doane <martin.doane@siemens.com> wrote:

QNX 6.2.0
x86 (NS Geode GX-1 300 MHz) - Advantech PCM-3350 PC-104 card
DIO card using IRQ5

I’m seeing typical interrupt latencies that are quite reasonable (10’s of us
for the scope trace setup I’ve got). However, occasionally, I see it stretch
out to up to 300 us. Sometimes it occurs before my handler can toggle the
scope trace output, other times it clearly occurs during the handler, which
runs at priority 60.

I’ve removed all non-essentials from the system to eliminate sources of
latency - no package file system, no io-net, no serial ports, etc. I’m down
to two candidates - timer interrupt or SMM. Based on my prior experience I
don’t believe it to be the timer interrupt, which leaves SMM. SMM is used by
this CPU, but I’ve not yet uncovered all the details. Power management is
disabled in the BIOS (I know that doesn’t guarantee anything).

Is there any way to confirm the source of this latency? Is there any place
to probe that would show SMM activity?

System Management Mode is an Intel thing. The NatSemi processors have
something evquivalent; as far as I know, most “legacy” io ports on
the Geode do not actually exist (audio, VGA etc.) but instead, an
access to these ports causes an exception, and the ports are emulated
in software by some SMM-like mechanism. All this is nicely hidden
from the OS. There probably isn’t an external SMM(like) pin involved
since most of the peripherals (virtual as the may be) are internal
to the CPU.

I don’t actually know which peripherals and/or I/O ports are virtual,
nor do I have any idea wrt. the latencies involved upon accessing
them. You’d need to contact NatSemi for that kind of information.

Dave

8

“David Donohoe” <ddonohoe@qnx.com> wrote in message
news:b33tf4$h63$1@nntp.qnx.com…

Marty Doane <> martin.doane@siemens.com> > wrote:
QNX 6.2.0
x86 (NS Geode GX-1 300 MHz) - Advantech PCM-3350 PC-104 card
DIO card using IRQ5

I’m seeing typical interrupt latencies that are quite reasonable (10’s
of us
for the scope trace setup I’ve got). However, occasionally, I see it
stretch
out to up to 300 us. Sometimes it occurs before my handler can toggle
the
scope trace output, other times it clearly occurs during the handler,
which
runs at priority 60.

I’ve removed all non-essentials from the system to eliminate sources of
latency - no package file system, no io-net, no serial ports, etc. I’m
down
to two candidates - timer interrupt or SMM. Based on my prior experience
I
don’t believe it to be the timer interrupt, which leaves SMM. SMM is
used by
this CPU, but I’ve not yet uncovered all the details. Power management
is
disabled in the BIOS (I know that doesn’t guarantee anything).

Is there any way to confirm the source of this latency? Is there any
place
to probe that would show SMM activity?

System Management Mode is an Intel thing. The NatSemi processors have
something evquivalent; as far as I know, most “legacy” io ports on
the Geode do not actually exist (audio, VGA etc.) but instead, an
access to these ports causes an exception, and the ports are emulated
in software by some SMM-like mechanism. All this is nicely hidden
from the OS. There probably isn’t an external SMM(like) pin involved
since most of the peripherals (virtual as the may be) are internal
to the CPU.

I had learned some of this. You’ve added clarity.

I don’t actually know which peripherals and/or I/O ports are virtual,
nor do I have any idea wrt. the latencies involved upon accessing
them. You’d need to contact NatSemi for that kind of information.

That’s what I was thinking too.

Thanks,
Marty Doane
Siemens Dematic