RE: UART Handling - was interrupt handshaking

Your reasoning is spurious on a couple of levels. First, the issue is
whether or not you can read every single byte. So it’s not necessary to
flood the system in order to create an error, just to cause a delay of
70us. You could have problems at much lower interrupt rates, as long as
you have that 70us delay.

Second, processor instructions aren’t really the issue any more. As you
point out, the processor has cycles to burn. Even so, the PCI spec
allows stalls of up to 30us on the PCI bus. If there is heavy busmaster
traffic going on while the UART is interrupting, it’s possible that each
read from any PCI device’s registers could take that 30us. This means
that it’s possible for any ISR to take upwards of 60us. If there’s even
one higher-priority interrupt active in the system, you could blow your
70us deadline.

Now bring processor power management into the question. Your processor
may be in one of the ACPI-defined low power states when the UART
interrupts. If it’s in C1, that’s only 4 or 5us of extra latency. If
it’s in C2, it’s somewhere between 10us and 60us, depending on the
chipset. If it’s in C3, which really saves power, you’re looking at
somewhere between 70us and 800us, depending on the processor and the
chipset.

Now bring BIOS into the question. Your BIOS, depending on how well it
was designed, will trigger at least a few System Management Interrupts.
The entry and exit code for these is usually uncached, in Real-Big Mode.
Thus just the entry and exit paths can take about 1500us. Anything they
actually do in response to the SMI is extra, running uncached code.
(There are a few very recent BIOSes that run cached, protected mode.
But they are the exception.) Some BIOSes will even go upwards of
33000us in an SMI. Dell will even take over the screen and show the
user a menu.

Jake Oshins
Windows Kernel Group Interrupt Guy

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
Subject: RE: interrupt handshaking - was other crap
From: “Moreira, Alberto”
Date: Mon, 16 Dec 2002 09:25:58 -0500
X-Message-Number: 12

So, let’s see. 115,200 bits per second is 14,400 8-bit characters per
second. If one interrupt per character will flood the system, the peak
interrupt rate of the system is 14,400 interrupts per second. That gives
us
around 70 microseconds per interrupt. At one gigahertz, that is, 10^9/
10^6
= 1000 instructions per microsecond, so, that’s around 70,000
instructions.
Even if we use a fraction of the CPU power to handle the interrupt, say,
7,000 instructions, that’s a lot of instructions to handle one
character, no
? I’d expect a bit more from a modern processor.

Alberto.

-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Saturday, December 14, 2002 2:29 PM
To: NT Developers Interest List
Subject: [ntdev] RE: interrupt handshaking - was other crap

I don’t completely agree. The serial port FIFO example given below is
spurious. The problem with a serial port with no FIFO is that the data
may be overwritten so quickly by new incoming data that you would need
fantastically small interrupt latency to handle it at 115200 BAUD.

With level-triggered devices (see my earlier messages) you end up doing
exactly the sort of “queuing” that you’re talking about just by holding
your interrupt in the asserted state. The OS will call your ISR
repeatedly until you finally release the signal. (In PCI devices, this
is the INTx# signal.)

With edge-triggered devices, your ISR must be able to handle every event
that your device currently has pending, since it may only be called
once. This may or may not involve internal queuing. It may just
involve setting individual status bits for each class of event.

Jake Oshins
Windows Kernel Group Interrupt Guy

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
Subject: Re: interrupt handshaking - was other crap
From: “Moreira, Alberto”
Date: Fri, 13 Dec 2002 11:34:23 -0500

Jake,
I am a bit uncertain now, could you please clarify.

Does W2K/XP let the BIOS handle some IRQs ?

If that is the case I wonder how USB isochronous pipes have to be set
up. Assuming the HostController interrupts each millisecond. A worst
case 33000 us latency would mean at least 33 packets have to be
outstanding in queued URBs/(DMA). In the ddk docs there is no lower
limit given on how many packets have to be queued! HOW CAN THIS WORK ?

Norbert.

“You must believe in yourself before you can believe in anything.”
---- snip ----

Now bring BIOS into the question. Your BIOS, depending on how well it
was designed, will trigger at least a few System Management Interrupts.
The entry and exit code for these is usually uncached, in Real-Big Mode.
Thus just the entry and exit paths can take about 1500us. Anything they
actually do in response to the SMI is extra, running uncached code.
(There are a few very recent BIOSes that run cached, protected mode.
But they are the exception.) Some BIOSes will even go upwards of
33000us in an SMI. Dell will even take over the screen and show the
user a menu.

Jake Oshins
---- snip ----

SMI is being phased out, but on legacy systems SMI’s are only genrated when
bad things happen such as voltage and temperature events, or ECC
errors. There may be some cheesy real mode legacy USB support from SMI as
well, but not after Windows boots. After boot, the OS handles ALL IRQ’s.

-Justin

At 12:04 AM 12/18/2002, you wrote:

Jake,
I am a bit uncertain now, could you please clarify.

Does W2K/XP let the BIOS handle some IRQs ?

If that is the case I wonder how USB isochronous pipes have to be set
up. Assuming the HostController interrupts each millisecond. A worst
case 33000 us latency would mean at least 33 packets have to be
outstanding in queued URBs/(DMA). In the ddk docs there is no lower
limit given on how many packets have to be queued! HOW CAN THIS WORK ?

Norbert.

“You must believe in yourself before you can believe in anything.”
---- snip ----
> Now bring BIOS into the question. Your BIOS, depending on how well it
> was designed, will trigger at least a few System Management Interrupts.
> The entry and exit code for these is usually uncached, in Real-Big Mode.
> Thus just the entry and exit paths can take about 1500us. Anything they
> actually do in response to the SMI is extra, running uncached code.
> (There are a few very recent BIOSes that run cached, protected mode.
> But they are the exception.) Some BIOSes will even go upwards of
> 33000us in an SMI. Dell will even take over the screen and show the
> user a menu.

> Jake Oshins
---- snip ----


You are currently subscribed to ntdev as: zeppelin@io.com
To unsubscribe send a blank email to %%email.unsub%%

SMI (System Management Interrupts) are special interrupts handled by special
power management firmware that is active no matter what OS is running. When
an SMI comes in, the processor saves most of the processor registers,
switches into a special mode, and starts executing the special SMI BIOS
code. At the end, the code issues a special RESUME instruction causing the
processor state to be restored and processing to continue. During te time in
SMI BIOS code, interrupts are usually masked because the interrupt vector
information is meaningless in the SMI memory mode.

Doug

“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
>
> Jake,
> I am a bit uncertain now, could you please clarify.
>
> Does W2K/XP let the BIOS handle some IRQs ?
>
> If that is the case I wonder how USB isochronous pipes have to be set
> up. Assuming the HostController interrupts each millisecond. A worst
> case 33000 us latency would mean at least 33 packets have to be
> outstanding in queued URBs/(DMA). In the ddk docs there is no lower
> limit given on how many packets have to be queued! HOW CAN THIS WORK ?
>
> Norbert.
> --------
> “You must believe in yourself before you can believe in anything.”
> ---- snip ----
> > Now bring BIOS into the question. Your BIOS, depending on how well it
> > was designed, will trigger at least a few System Management Interrupts.
> > The entry and exit code for these is usually uncached, in Real-Big Mode.
> > Thus just the entry and exit paths can take about 1500us. Anything they
> > actually do in response to the SMI is extra, running uncached code.
> > (There are a few very recent BIOSes that run cached, protected mode.
> > But they are the exception.) Some BIOSes will even go upwards of
> > 33000us in an SMI. Dell will even take over the screen and show the
> > user a menu.
>
> > Jake Oshins
> ---- snip ----
>
>
>
>

That is correct. I don’t know what you mean by “special power management
firmware” though. BIOS code by any other name is still BIOS (bios is
sometimes called firmware I’ll grant you that). The SMI handler completely
takes over the machine. Certain BIOSs took control for crazy amounts of
time to do house keeping like ECC scrubbing. These BIOS were sticking in
SMI for like 100ms. Microsoft had clarify the spec, and say that you must
return within 1ms to be compliant. As I mentioned before, SMI is being
phased out in favor of other configurations on the newer architectures.

-Justin

At 03:30 AM 12/18/2002, you wrote:

SMI (System Management Interrupts) are special interrupts handled by special
power management firmware that is active no matter what OS is running. When
an SMI comes in, the processor saves most of the processor registers,
switches into a special mode, and starts executing the special SMI BIOS
code. At the end, the code issues a special RESUME instruction causing the
processor state to be restored and processing to continue. During te time in
SMI BIOS code, interrupts are usually masked because the interrupt vector
information is meaningless in the SMI memory mode.

Doug

“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
> >
> > Jake,
> > I am a bit uncertain now, could you please clarify.
> >
> > Does W2K/XP let the BIOS handle some IRQs ?
> >
> > If that is the case I wonder how USB isochronous pipes have to be set
> > up. Assuming the HostController interrupts each millisecond. A worst
> > case 33000 us latency would mean at least 33 packets have to be
> > outstanding in queued URBs/(DMA). In the ddk docs there is no lower
> > limit given on how many packets have to be queued! HOW CAN THIS WORK ?
> >
> > Norbert.
> > --------
> > “You must believe in yourself before you can believe in anything.”
> > ---- snip ----
> > > Now bring BIOS into the question. Your BIOS, depending on how well it
> > > was designed, will trigger at least a few System Management Interrupts.
> > > The entry and exit code for these is usually uncached, in Real-Big Mode.
> > > Thus just the entry and exit paths can take about 1500us. Anything they
> > > actually do in response to the SMI is extra, running uncached code.
> > > (There are a few very recent BIOSes that run cached, protected mode.
> > > But they are the exception.) Some BIOSes will even go upwards of
> > > 33000us in an SMI. Dell will even take over the screen and show the
> > > user a menu.
> >
> > > Jake Oshins
> > ---- snip ----
> >
> >
> >
> >
>
>
>
>—
>You are currently subscribed to ntdev as: zeppelin@io.com
>To unsubscribe send a blank email to %%email.unsub%%

Since I use to write BIOS/POST/SMI code, I always differntiate BIOS from
POST code from SMI code. Just a habit. It is special due to how it is loaded
into RAM, how it is entered, the memory mode while running, and how it
exits.

In reality all code (drivers, firmware, applications, OS) is the same, but
it is different.

I was one of those people who took too much time in an SMI because the
hardware was designed improperly and the function required (battery
charging) could only be done by doing something in an SMI which took too
long…

Doug

“Justin Frodsham” wrote in message news:xxxxx@ntdev…
>
> That is correct. I don’t know what you mean by “special power management
> firmware” though. BIOS code by any other name is still BIOS (bios is
> sometimes called firmware I’ll grant you that). The SMI handler
completely
> takes over the machine. Certain BIOSs took control for crazy amounts of
> time to do house keeping like ECC scrubbing. These BIOS were sticking in
> SMI for like 100ms. Microsoft had clarify the spec, and say that you must
> return within 1ms to be compliant. As I mentioned before, SMI is being
> phased out in favor of other configurations on the newer architectures.
>
> -Justin

Thanks for the info. I understand now. Somehow I had selectively
ignored that mode (SMI).

As
‘IA-32 Intel Architecture Software Developer’s Manual Volume 3’
shows, you need external hardware to mask SMI# pin. So without
schematics of your mainboard you can not be sure whether there are
SMI# requests or not.

‘Phasing out’ sounds good.

Norbert.

“Anything that can go wrong will go wrong.”
---- snip ----
---- snip ----

SMI is used for APM, legacy keyboard/mouse emulation for USB keyboard/mouse,
among other things you guys have mentioned. OS is unware of SMI at all. When
SMI asserts, it puts processor into SMM and BIOS SMM code will take over. We
all wish it along with other legacy go away entirely. However, in PC world,
legacy die extramely hard.

Bi

-----Original Message-----
From: Justin Frodsham [mailto:zeppelin@io.com]
Sent: Wednesday, December 18, 2002 6:18 AM
To: NT Developers Interest List
Subject: [ntdev] Re: UART Handling - was interrupt handshaking

That is correct. I don’t know what you mean by “special power management
firmware” though. BIOS code by any other name is still BIOS (bios is
sometimes called firmware I’ll grant you that). The SMI handler completely
takes over the machine. Certain BIOSs took control for crazy amounts of
time to do house keeping like ECC scrubbing. These BIOS were sticking in
SMI for like 100ms. Microsoft had clarify the spec, and say that you must
return within 1ms to be compliant. As I mentioned before, SMI is being
phased out in favor of other configurations on the newer architectures.

-Justin

At 03:30 AM 12/18/2002, you wrote:

SMI (System Management Interrupts) are special interrupts handled by
special
power management firmware that is active no matter what OS is running. When
an SMI comes in, the processor saves most of the processor registers,
switches into a special mode, and starts executing the special SMI BIOS
code. At the end, the code issues a special RESUME instruction causing the
processor state to be restored and processing to continue. During te time
in
SMI BIOS code, interrupts are usually masked because the interrupt vector
information is meaningless in the SMI memory mode.

Doug

“Norbert Kawulski” wrote in message news:xxxxx@ntdev…
> >
> > Jake,
> > I am a bit uncertain now, could you please clarify.
> >
> > Does W2K/XP let the BIOS handle some IRQs ?
> >
> > If that is the case I wonder how USB isochronous pipes have to be set
> > up. Assuming the HostController interrupts each millisecond. A worst
> > case 33000 us latency would mean at least 33 packets have to be
> > outstanding in queued URBs/(DMA). In the ddk docs there is no lower
> > limit given on how many packets have to be queued! HOW CAN THIS WORK ?
> >
> > Norbert.
> > --------
> > “You must believe in yourself before you can believe in anything.”
> > ---- snip ----
> > > Now bring BIOS into the question. Your BIOS, depending on how well it
> > > was designed, will trigger at least a few System Management
Interrupts.
> > > The entry and exit code for these is usually uncached, in Real-Big
Mode.
> > > Thus just the entry and exit paths can take about 1500us. Anything
they
> > > actually do in response to the SMI is extra, running uncached code.
> > > (There are a few very recent BIOSes that run cached, protected mode.
> > > But they are the exception.) Some BIOSes will even go upwards of
> > > 33000us in an SMI. Dell will even take over the screen and show the
> > > user a menu.
> >
> > > Jake Oshins
> > ---- snip ----
> >
> >
> >
> >
>
>
>
>—
>You are currently subscribed to ntdev as: zeppelin@io.com
>To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

Well, it’s nice to have some hardware in the machine that one can use to sit
under the OS, no ?

Alberto.

-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Wednesday, December 18, 2002 1:18 PM
To: NT Developers Interest List
Subject: [ntdev] Re: UART Handling - was interrupt handshaking

SMI is used for APM, legacy keyboard/mouse emulation for USB keyboard/mouse,
among other things you guys have mentioned. OS is unware of SMI at all. When
SMI asserts, it puts processor into SMM and BIOS SMM code will take over. We
all wish it along with other legacy go away entirely. However, in PC world,
legacy die extramely hard.

Bi

-----Original Message-----
From: Justin Frodsham [mailto:zeppelin@io.com mailto:zeppelin]
Sent: Wednesday, December 18, 2002 6:18 AM
To: NT Developers Interest List
Subject: [ntdev] Re: UART Handling - was interrupt handshaking

That is correct. I don’t know what you mean by “special power management
firmware” though. BIOS code by any other name is still BIOS (bios is
sometimes called firmware I’ll grant you that). The SMI handler completely
takes over the machine. Certain BIOSs took control for crazy amounts of
time to do house keeping like ECC scrubbing. These BIOS were sticking in
SMI for like 100ms. Microsoft had clarify the spec, and say that you must
return within 1ms to be compliant. As I mentioned before, SMI is being
phased out in favor of other configurations on the newer architectures.

-Justin

At 03:30 AM 12/18/2002, you wrote:
>SMI (System Management Interrupts) are special interrupts handled by
special
>power management firmware that is active no matter what OS is running. When

>an SMI comes in, the processor saves most of the processor registers,
>switches into a special mode, and starts executing the special SMI BIOS
>code. At the end, the code issues a special RESUME instruction causing the
>processor state to be restored and processing to continue. During te time
in
>SMI BIOS code, interrupts are usually masked because the interrupt vector
>information is meaningless in the SMI memory mode.
>
>Doug
>
>“Norbert Kawulski” wrote in message news:xxxxx@ntdev
news:xxxxx
> >
> > Jake,
> > I am a bit uncertain now, could you please clarify.
> >
> > Does W2K/XP let the BIOS handle some IRQs ?
> >
> > If that is the case I wonder how USB isochronous pipes have to be set
> > up. Assuming the HostController interrupts each millisecond. A worst
> > case 33000 us latency would mean at least 33 packets have to be
> > outstanding in queued URBs/(DMA). In the ddk docs there is no lower
> > limit given on how many packets have to be queued! HOW CAN THIS WORK ?
> >
> > Norbert.
> > --------
> > “You must believe in yourself before you can believe in anything.”
> > ---- snip ----
> > > Now bring BIOS into the question. Your BIOS, depending on how well it

> > > was designed, will trigger at least a few System Management
Interrupts.
> > > The entry and exit code for these is usually uncached, in Real-Big
Mode.
> > > Thus just the entry and exit paths can take about 1500us. Anything
they
> > > actually do in response to the SMI is extra, running uncached code.
> > > (There are a few very recent BIOSes that run cached, protected mode.
> > > But they are the exception.) Some BIOSes will even go upwards of
> > > 33000us in an SMI. Dell will even take over the screen and show the
> > > user a menu.
> >
> > > Jake Oshins
> > ---- snip ----
> >
> >
> >
> >
>
>
>
>—
>You are currently subscribed to ntdev as: zeppelin@io.com
>To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</news:xxxxx></mailto:zeppelin>

> Does W2K/XP let the BIOS handle some IRQs ?

No, except SMI which IIRC can occur only on power-related transition
only.

Max

> “Moreira, Alberto” wrote:

Well, it’s nice to have some hardware in the machine that one can use
to sit under the OS, no ?

Yes. I’ve heard rumors of some hardware having bugs. Not ours, of
course,
but other companies. Anyhow, SMI traps are often the only way to work
around some issues.

I’ve even heard rumors of Microsoft telling hardware vendors to use SMIs
in some circumstances. I think it was in a Dilbert cartoon recently…