Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: UART Handling - was interrupt handshaking

Jake_OshinsJake_Oshins Member Posts: 1,058
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" <xxxxx@compuware.com>
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" <xxxxx@compuware.com>
Date: Fri, 13 Dec 2002 11:34:23 -0500

Comments

  • Norbert_KawulskiNorbert_Kawulski Member Posts: 174
    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 ----
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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%%
  • DougDoug Member Posts: 83
    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 ----
    >
    >
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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" <xxxxx@stollmann.de> 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%%
  • DougDoug Member Posts: 83
    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
  • Norbert_KawulskiNorbert_Kawulski Member Posts: 174
    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 ----
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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%%
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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 ]
    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%%

    ---
    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.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > Does W2K/XP let the BIOS handle some IRQs ?

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

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > "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...
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space