1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Interrupts?

Discussion in 'Windows XP' started by Spamlet, Sep 1, 2010.

  1. Spamlet

    Spamlet Flightless Bird

    Not seen much about interrupts, and not even entirely sue what they are.
    But I've noticed - coincidentally or not - that since I did the delete of MS
    Update software to get back to using the less processor hogging Windows
    Update, I keep seeing interrupts flare up to a large percentage of the cpu.
    This is on an old Inspiron 2600 laptop with only 260 meg of memory at the
    moment. It was recently updated to an 80gig WD hard drive, which seems to
    be running well, and this is with XPHome SP3 all up to date.

    There seems to be no way of seeing what these interrupts are for, as they
    change too quickly to open a properties window for them in Process Explorer.
    How much of the cpu should they take up? Might they have been an underlying
    problem that was interfering with MS Update?

    Cheers,

    S
     
  2. Tim Meddick

    Tim Meddick Flightless Bird

    "Interrupts" are used by programs to call hardware resources.

    For instance : the ps2 mouse is typically Interrupt 12 and the operating
    system (software in itself) and other programs will use interrupt 12 to
    access the mouse.

    All interrupts are allocated to a hardware resource.

    To see what interrupts are allocated to what hardware on your PC -

    type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
    Manager.

    Then in Device Manager, click on "View" from the top menus, and then select
    "Resources by type" on the drop-down menu.

    Then click on the + sign next to the item named "Interrupt Request (IRQ)" -
    like on a folder in explorer, to see the expanded list of hardware and
    there allocated interrupts.

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    news:i5ms93$lmo$1@news.eternal-september.org...
    > Not seen much about interrupts, and not even entirely sue what they are.
    > But I've noticed - coincidentally or not - that since I did the delete of
    > MS Update software to get back to using the less processor hogging
    > Windows Update, I keep seeing interrupts flare up to a large percentage
    > of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
    > memory at the moment. It was recently updated to an 80gig WD hard drive,
    > which seems to be running well, and this is with XPHome SP3 all up to
    > date.
    >
    > There seems to be no way of seeing what these interrupts are for, as they
    > change too quickly to open a properties window for them in Process
    > Explorer. How much of the cpu should they take up? Might they have been
    > an underlying problem that was interfering with MS Update?
    >
    > Cheers,
    >
    > S
    >
     
  3. Spamlet

    Spamlet Flightless Bird

    Thanks Tim,

    I've not looked at that part of the device manager before.

    There are 16 'Interrupt Request' devices listed, and eight of them use the
    same number: 9.

    How do I work out which one or ones are hogging the CPU? And, if I
    understand you right, which part of the system is trying to use that
    interrupt device and causing it to hog the CPU.

    Presumably as I don't have much RAM, the hard drive will get a lot of
    activity, but this is fairly new and much quicker than the old one so far
    (Though I don't know why I have two IDE channels and only one hard drive?)

    Cheers,

    S



    "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    > "Interrupts" are used by programs to call hardware resources.
    >
    > For instance : the ps2 mouse is typically Interrupt 12 and the operating
    > system (software in itself) and other programs will use interrupt 12 to
    > access the mouse.
    >
    > All interrupts are allocated to a hardware resource.
    >
    > To see what interrupts are allocated to what hardware on your PC -
    >
    > type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
    > Manager.
    >
    > Then in Device Manager, click on "View" from the top menus, and then
    > select "Resources by type" on the drop-down menu.
    >
    > Then click on the + sign next to the item named "Interrupt Request
    > (IRQ)" - like on a folder in explorer, to see the expanded list of
    > hardware and there allocated interrupts.
    >
    > ==
    >
    > Cheers, Tim Meddick, Peckham, London. :)
    >
    >
    >
    >
    > "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    > news:i5ms93$lmo$1@news.eternal-september.org...
    >> Not seen much about interrupts, and not even entirely sue what they are.
    >> But I've noticed - coincidentally or not - that since I did the delete of
    >> MS Update software to get back to using the less processor hogging
    >> Windows Update, I keep seeing interrupts flare up to a large percentage
    >> of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
    >> memory at the moment. It was recently updated to an 80gig WD hard drive,
    >> which seems to be running well, and this is with XPHome SP3 all up to
    >> date.
    >>
    >> There seems to be no way of seeing what these interrupts are for, as they
    >> change too quickly to open a properties window for them in Process
    >> Explorer. How much of the cpu should they take up? Might they have been
    >> an underlying problem that was interfering with MS Update?
    >>
    >> Cheers,
    >>
    >> S
    >>

    >
     
  4. Tim Meddick

    Tim Meddick Flightless Bird

    To answer you last question, first.

    The reason you have two IEDE channels is that each channel can take two IDE
    drives each. So, with two channels, that's space for 4 drives.

    Usually drives are arranged thus :

    Primary IDE Channel [position 1] = Master:- Hard Drive [C:]
    [position 2] = Slave:- Hard Drive [D:]

    Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E:]
    [position 2] = Slave:- Hard Drive
    [D:]

    .....a cd/dvd drive (when present in a new machine) occupying the 1st
    position on the Secondary IDE channel. If a purchaser of a new PC buys an
    additional Hard drive for extra media content or space for backups, it
    would normally be connected to position 2 of the Primary IDE channel,
    making it slave to the system or [c:] drive. While position 2 of the
    Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
    re-writer. The whole idea behind the PC, is that there is lots of room,
    built-in, to accommodate additions, expansions and upgrades....

    As I may have said in a previous post (or many of them), the way to see
    what application or "running process" is "hogging" system resources - and
    by resources I really mean RAM - is to open the Window's Task Manager.

    Click on an empty area of the taskbar and right-click on it.

    Choose "Task Manager" from the pop-up menu.

    Click on the column heading "Memory Usage" to make the process-list get in
    order, similar to doing the same with files in Explorer. You may need to
    click on the heading twice to get them in order - largest mem usage at the
    top down to lowest at the bottom.

    The task or process-list, refreshes itself once every five seconds by
    default (but you can change that) so by arranging the columns in order of
    size of memory usage - then the application or service[es] that are
    taking up most RAM are always going to be at the top of the list.

    This is how I found out that Window's Update takes up so much RAM when it's
    running, that I can do nothing else on the PC till it's finished (seeing
    how I need it, I have to let it run). So, when I feel the system starting
    to run a bit slow, I open up Task Manager and if I see the process
    "wuauclt.exe" listed, I can go and get a cup of tea and have a sit down
    until then.



    One is obviously going to be for the system [c:] drive, and an other

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    news:i5ok6m$1vi$1@news.eternal-september.org...
    > Thanks Tim,
    >
    > I've not looked at that part of the device manager before.
    >
    > There are 16 'Interrupt Request' devices listed, and eight of them use
    > the same number: 9.
    >
    > How do I work out which one or ones are hogging the CPU? And, if I
    > understand you right, which part of the system is trying to use that
    > interrupt device and causing it to hog the CPU.
    >
    > Presumably as I don't have much RAM, the hard drive will get a lot of
    > activity, but this is fairly new and much quicker than the old one so far
    > (Though I don't know why I have two IDE channels and only one hard
    > drive?)
    >
    > Cheers,
    >
    > S
    >
    >
    >
    > "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    > news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >> "Interrupts" are used by programs to call hardware resources.
    >>
    >> For instance : the ps2 mouse is typically Interrupt 12 and the
    >> operating system (software in itself) and other programs will use
    >> interrupt 12 to access the mouse.
    >>
    >> All interrupts are allocated to a hardware resource.
    >>
    >> To see what interrupts are allocated to what hardware on your PC -
    >>
    >> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
    >> Device Manager.
    >>
    >> Then in Device Manager, click on "View" from the top menus, and then
    >> select "Resources by type" on the drop-down menu.
    >>
    >> Then click on the + sign next to the item named "Interrupt Request
    >> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >> hardware and there allocated interrupts.
    >>
    >> ==
    >>
    >> Cheers, Tim Meddick, Peckham, London. :)
    >>
    >>
    >>
    >>
    >> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >> news:i5ms93$lmo$1@news.eternal-september.org...
    >>> Not seen much about interrupts, and not even entirely sue what they
    >>> are. But I've noticed - coincidentally or not - that since I did the
    >>> delete of MS Update software to get back to using the less processor
    >>> hogging Windows Update, I keep seeing interrupts flare up to a large
    >>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
    >>> 260 meg of memory at the moment. It was recently updated to an 80gig
    >>> WD hard drive, which seems to be running well, and this is with XPHome
    >>> SP3 all up to date.
    >>>
    >>> There seems to be no way of seeing what these interrupts are for, as
    >>> they change too quickly to open a properties window for them in Process
    >>> Explorer. How much of the cpu should they take up? Might they have
    >>> been an underlying problem that was interfering with MS Update?
    >>>
    >>> Cheers,
    >>>
    >>> S
    >>>

    >>

    >
    >
     
  5. Paul

    Paul Flightless Bird

    Spamlet wrote:
    > Thanks Tim,
    >
    > I've not looked at that part of the device manager before.
    >
    > There are 16 'Interrupt Request' devices listed, and eight of them use the
    > same number: 9.
    >
    > How do I work out which one or ones are hogging the CPU? And, if I
    > understand you right, which part of the system is trying to use that
    > interrupt device and causing it to hog the CPU.
    >
    > Presumably as I don't have much RAM, the hard drive will get a lot of
    > activity, but this is fairly new and much quicker than the old one so far
    > (Though I don't know why I have two IDE channels and only one hard drive?)
    >
    > Cheers,
    >
    > S


    If you see 16 entries, your machine is handling interrupts using PIC
    (programmable interrupt controller). The other option, is APIC (which
    may be a BIOS option). APIC has a couple features, such as being able
    to forward interrupts to a particular processor on a multiprocessor
    (or multicore) machine. APIC interrupt numbers also go a bit higher,
    and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
    can even be used on a single core computer, but in that case, there
    is no need to steer the interrupts because they all go to the same
    place.

    http://en.wikipedia.org/wiki/Intel_APIC_Architecture

    This is my Device Manager summary report in the interrupt section.
    I'm running APIC. You can see there is still sharing going on.
    On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI Express
    bus), and the chipset, are all sharing the same IRQ. Interrupt
    handlers have to be able to deal with this sharing.

    ******************** IRQ SUMMARY ********************
    IRQ Usage Summary:
    (ISA) 0 System timer
    (ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
    (ISA) 6 Standard floppy disk controller
    (ISA) 8 System CMOS/real time clock
    (ISA) 9 Microsoft ACPI-Compliant System
    (ISA) 13 Numeric data processor
    (PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
    (PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
    (PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
    (PCI) 16 NVIDIA GeForce 7900 GT/GTO
    (PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
    (PCI) 16 Standard Dual Channel PCI IDE Controller
    (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
    (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
    (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
    (PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
    (PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944 <---
    (PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller <---
    (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
    (PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver <---
    (PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
    (PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
    (PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
    (PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
    (PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 - 29
    (PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 - 29
    (PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
    (PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A

    I don't know of a tool for logging specific interrupt counts in Windows. In Linux,
    you can use /proc/interrupts to get the info. I still haven't figured
    out how to do the equivalent of this in Windows.

    http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html

    "3.2.11. /proc/interrupts

    For a multi-processor machine, this file may look slightly different:

    CPU0 CPU1
    0: 1366814704 0 XT-PIC timer
    1: 128 340 IO-APIC-edge keyboard
    2: 0 0 XT-PIC cascade
    8: 0 1 IO-APIC-edge rtc
    12: 5323 5793 IO-APIC-edge PS/2 Mouse
    13: 1 0 XT-PIC fpu
    16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet
    20: 8450043 11120093 IO-APIC-level megaraid
    30: 10432 10722 IO-APIC-level aic7xxx
    31: 23 22 IO-APIC-level aic7xxx
    NMI: 0
    ERR: 0 "

    In that example, APIC is able to steer interrupts to a particular CPU.
    CPU0 is getting all the timer interrupts. A high count there would
    not be a cause for concern, because the timer is being used by
    the OS a lot.

    I had great hopes for an article with this title, but in fact
    the facilities available look pretty poor. "Disabling hardware"
    is a pathetic way to debug things, especially in a case where
    the hardware cannot be physically removed, to be sure it is
    not affecting system state.

    "Debugging an Interrupt Storm"
    http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx

    According to this, when things share an IRQ, an ISR (interrupt
    service routine) chain is used to sequentially attempt to service
    the interrupt. Different ISRs are tried until the interrupt is cleared.
    To get some idea what hardware is interrupting, you'd need
    the ISR routine to count how many times it successfully
    handled an interrupt. An ISR may queue up a DPC, to finish
    handling the interrupt - a DPC runs at user level, rather
    than interrupt level, and that allows the ISR to be fast
    and lightweight. Process Explorer can show you the level of
    DPC activity, which might be proof that real interrupt
    events are happening (since they finish the servicing
    needed by the hardware). If there was something wrong
    with interrupts, perhaps you'd see a mismatch between
    the time spent handling interrupts, and the amount of
    DPC activity.

    http://www.microsoft.com/whdc/archive/apic.mspx

    "4. The operating system calls the first ISR in the chain.
    5. The ISR probes the hardware and attempts to handle the interrupt.
    6. If there are additional ISRs, the operating system goes on to
    the next one and returns to step 5."

    HTH,
    Paul

    >
    >
    >
    > "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    > news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >> "Interrupts" are used by programs to call hardware resources.
    >>
    >> For instance : the ps2 mouse is typically Interrupt 12 and the operating
    >> system (software in itself) and other programs will use interrupt 12 to
    >> access the mouse.
    >>
    >> All interrupts are allocated to a hardware resource.
    >>
    >> To see what interrupts are allocated to what hardware on your PC -
    >>
    >> type "devmgmt.msc" into the "Run"box on the Start Menu to start the Device
    >> Manager.
    >>
    >> Then in Device Manager, click on "View" from the top menus, and then
    >> select "Resources by type" on the drop-down menu.
    >>
    >> Then click on the + sign next to the item named "Interrupt Request
    >> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >> hardware and there allocated interrupts.
    >>
    >> ==
    >>
    >> Cheers, Tim Meddick, Peckham, London. :)
    >>
    >>
    >>
    >>
    >> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >> news:i5ms93$lmo$1@news.eternal-september.org...
    >>> Not seen much about interrupts, and not even entirely sue what they are.
    >>> But I've noticed - coincidentally or not - that since I did the delete of
    >>> MS Update software to get back to using the less processor hogging
    >>> Windows Update, I keep seeing interrupts flare up to a large percentage
    >>> of the cpu. This is on an old Inspiron 2600 laptop with only 260 meg of
    >>> memory at the moment. It was recently updated to an 80gig WD hard drive,
    >>> which seems to be running well, and this is with XPHome SP3 all up to
    >>> date.
    >>>
    >>> There seems to be no way of seeing what these interrupts are for, as they
    >>> change too quickly to open a properties window for them in Process
    >>> Explorer. How much of the cpu should they take up? Might they have been
    >>> an underlying problem that was interfering with MS Update?
    >>>
    >>> Cheers,
    >>>
    >>> S
    >>>

    >
    >
     
  6. Spamlet

    Spamlet Flightless Bird

    Thanks Tim,

    I'm already using Process Explorer: which is how I could see the interrupts
    taking up cpu in the handy little graphs that are displayed in the
    notification area once you replace Task Manager with Process Explorer as I
    recommend you do, as TM is pretty crude once you have tried PE. In this
    case the interrupts are taking up cpu not ram, and they are too transient to
    get any info from other than they can sometimes take as much as 80% of the
    cpu.

    I discovered this, like you, after I began looking into windows update
    taking all my ram, and, apparently, solved that problem, through a comment
    made by PA Bear. He had asked me to look at how my laptop was accessing the
    update site. Interestingly, it appeared that I was using windows update as
    it was going via a link that had something like 'msupdate/windowsudate' in
    it, but paging down on that site I still found the tick box to uninstall ms
    update components from my computer. I was surprised to see this, but ticked
    it and tried again, and the next time I accessed the link there was no tick
    box at the bottom of the page. Since then the laptop has not hung on
    updates taking up ram (I haven't actually noticed any updates at all
    mind...), but I have noticed these interrupts taking up cpu which I had not
    noticed before. I did wonder if they might represent something still
    looking for that old update process. (Incidentally I've also deleted all
    the google updating files from my computer, as I suspected they might be
    getting in the way too, and had an irritating habit of turning themselves
    back on no matter how many times I 'disabled' them)

    Cheers,

    S




    "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    news:%23CoZ7UsSLHA.456@TK2MSFTNGP06.phx.gbl...
    > To answer you last question, first.
    >
    > The reason you have two IEDE channels is that each channel can take two
    > IDE drives each. So, with two channels, that's space for 4 drives.
    >
    > Usually drives are arranged thus :
    >
    > Primary IDE Channel [position 1] = Master:- Hard Drive [C:]
    > [position 2] = Slave:- Hard Drive [D:]
    >
    > Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E:]
    > [position 2] = Slave:- Hard Drive
    > [D:]
    >
    > ....a cd/dvd drive (when present in a new machine) occupying the 1st
    > position on the Secondary IDE channel. If a purchaser of a new PC buys
    > an additional Hard drive for extra media content or space for backups, it
    > would normally be connected to position 2 of the Primary IDE channel,
    > making it slave to the system or [c:] drive. While position 2 of the
    > Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
    > re-writer. The whole idea behind the PC, is that there is lots of room,
    > built-in, to accommodate additions, expansions and upgrades....
    >
    > As I may have said in a previous post (or many of them), the way to see
    > what application or "running process" is "hogging" system resources - and
    > by resources I really mean RAM - is to open the Window's Task Manager.
    >
    > Click on an empty area of the taskbar and right-click on it.
    >
    > Choose "Task Manager" from the pop-up menu.
    >
    > Click on the column heading "Memory Usage" to make the process-list get in
    > order, similar to doing the same with files in Explorer. You may need to
    > click on the heading twice to get them in order - largest mem usage at the
    > top down to lowest at the bottom.
    >
    > The task or process-list, refreshes itself once every five seconds by
    > default (but you can change that) so by arranging the columns in order of
    > size of memory usage - then the application or service[es] that are
    > taking up most RAM are always going to be at the top of the list.
    >
    > This is how I found out that Window's Update takes up so much RAM when
    > it's running, that I can do nothing else on the PC till it's finished
    > (seeing how I need it, I have to let it run). So, when I feel the system
    > starting to run a bit slow, I open up Task Manager and if I see the
    > process "wuauclt.exe" listed, I can go and get a cup of tea and have a sit
    > down until then.
    >
    >
    >
    > One is obviously going to be for the system [c:] drive, and an other
    >
    > ==
    >
    > Cheers, Tim Meddick, Peckham, London. :)
    >
    >
    >
    >
    > "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    > news:i5ok6m$1vi$1@news.eternal-september.org...
    >> Thanks Tim,
    >>
    >> I've not looked at that part of the device manager before.
    >>
    >> There are 16 'Interrupt Request' devices listed, and eight of them use
    >> the same number: 9.
    >>
    >> How do I work out which one or ones are hogging the CPU? And, if I
    >> understand you right, which part of the system is trying to use that
    >> interrupt device and causing it to hog the CPU.
    >>
    >> Presumably as I don't have much RAM, the hard drive will get a lot of
    >> activity, but this is fairly new and much quicker than the old one so far
    >> (Though I don't know why I have two IDE channels and only one hard
    >> drive?)
    >>
    >> Cheers,
    >>
    >> S
    >>
    >>
    >>
    >> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    >> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >>> "Interrupts" are used by programs to call hardware resources.
    >>>
    >>> For instance : the ps2 mouse is typically Interrupt 12 and the
    >>> operating system (software in itself) and other programs will use
    >>> interrupt 12 to access the mouse.
    >>>
    >>> All interrupts are allocated to a hardware resource.
    >>>
    >>> To see what interrupts are allocated to what hardware on your PC -
    >>>
    >>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
    >>> Device Manager.
    >>>
    >>> Then in Device Manager, click on "View" from the top menus, and then
    >>> select "Resources by type" on the drop-down menu.
    >>>
    >>> Then click on the + sign next to the item named "Interrupt Request
    >>> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >>> hardware and there allocated interrupts.
    >>>
    >>> ==
    >>>
    >>> Cheers, Tim Meddick, Peckham, London. :)
    >>>
    >>>
    >>>
    >>>
    >>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >>> news:i5ms93$lmo$1@news.eternal-september.org...
    >>>> Not seen much about interrupts, and not even entirely sue what they
    >>>> are. But I've noticed - coincidentally or not - that since I did the
    >>>> delete of MS Update software to get back to using the less processor
    >>>> hogging Windows Update, I keep seeing interrupts flare up to a large
    >>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
    >>>> 260 meg of memory at the moment. It was recently updated to an 80gig
    >>>> WD hard drive, which seems to be running well, and this is with XPHome
    >>>> SP3 all up to date.
    >>>>
    >>>> There seems to be no way of seeing what these interrupts are for, as
    >>>> they change too quickly to open a properties window for them in Process
    >>>> Explorer. How much of the cpu should they take up? Might they have
    >>>> been an underlying problem that was interfering with MS Update?
    >>>>
    >>>> Cheers,
    >>>>
    >>>> S
    >>>>
    >>>

    >>
    >>

    >
     
  7. Tim Meddick

    Tim Meddick Flightless Bird

    I see that you are focussing on interrupts as a cause of resource hogging -
    this is not the case.

    Interrupts are just "hooks" that software uses to access hardware. Of
    course, when it does, the PC and CPU are limited by the speed of the
    attached device.

    But it's very rare, or never, that software stops when a device paused or
    stops responding.

    No, it just keeps on processing data and, when it's tried enough times,
    will simply give up on hardware Interrupts requests.

    It's usually more likely the case that it's when an application has been
    asked to do something right at the limits of what is reasonable to expect
    of it, that problems, including apparent "resource hogging" occur.

    The simplest and best way to see which process is taking up what percentage
    of system resources, is to use the Task Manager.

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Paul" <nospam@needed.com> wrote in message
    news:i5oq5b$osd$1@speranza.aioe.org...
    > Spamlet wrote:
    >> Thanks Tim,
    >>
    >> I've not looked at that part of the device manager before.
    >>
    >> There are 16 'Interrupt Request' devices listed, and eight of them use
    >> the same number: 9.
    >>
    >> How do I work out which one or ones are hogging the CPU? And, if I
    >> understand you right, which part of the system is trying to use that
    >> interrupt device and causing it to hog the CPU.
    >>
    >> Presumably as I don't have much RAM, the hard drive will get a lot of
    >> activity, but this is fairly new and much quicker than the old one so
    >> far (Though I don't know why I have two IDE channels and only one hard
    >> drive?)
    >>
    >> Cheers,
    >>
    >> S

    >
    > If you see 16 entries, your machine is handling interrupts using PIC
    > (programmable interrupt controller). The other option, is APIC (which
    > may be a BIOS option). APIC has a couple features, such as being able
    > to forward interrupts to a particular processor on a multiprocessor
    > (or multicore) machine. APIC interrupt numbers also go a bit higher,
    > and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
    > can even be used on a single core computer, but in that case, there
    > is no need to steer the interrupts because they all go to the same
    > place.
    >
    > http://en.wikipedia.org/wiki/Intel_APIC_Architecture
    >
    > This is my Device Manager summary report in the interrupt section.
    > I'm running APIC. You can see there is still sharing going on.
    > On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI
    > Express
    > bus), and the chipset, are all sharing the same IRQ. Interrupt
    > handlers have to be able to deal with this sharing.
    >
    > ******************** IRQ SUMMARY ********************
    > IRQ Usage Summary:
    > (ISA) 0 System timer
    > (ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
    > (ISA) 6 Standard floppy disk controller
    > (ISA) 8 System CMOS/real time clock
    > (ISA) 9 Microsoft ACPI-Compliant System
    > (ISA) 13 Numeric data processor
    > (PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
    > (PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
    > (PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
    > (PCI) 16 NVIDIA GeForce 7900 GT/GTO
    > (PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
    > (PCI) 16 Standard Dual Channel PCI IDE Controller
    > (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
    > (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
    > (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
    > (PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
    > (PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944
    > <---
    > (PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
    > <---
    > (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
    > (PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver
    > <---
    > (PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
    > (PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
    > (PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
    > (PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
    > (PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 -
    > 29
    > (PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 -
    > 29
    > (PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
    > (PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A
    >
    > I don't know of a tool for logging specific interrupt counts in Windows.
    > In Linux,
    > you can use /proc/interrupts to get the info. I still haven't figured
    > out how to do the equivalent of this in Windows.
    >
    > http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html
    >
    > "3.2.11. /proc/interrupts
    >
    > For a multi-processor machine, this file may look slightly different:
    >
    > CPU0 CPU1
    > 0: 1366814704 0 XT-PIC timer
    > 1: 128 340 IO-APIC-edge keyboard
    > 2: 0 0 XT-PIC cascade
    > 8: 0 1 IO-APIC-edge rtc
    > 12: 5323 5793 IO-APIC-edge PS/2 Mouse
    > 13: 1 0 XT-PIC fpu
    > 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro
    > 10/100 Ethernet
    > 20: 8450043 11120093 IO-APIC-level megaraid
    > 30: 10432 10722 IO-APIC-level aic7xxx
    > 31: 23 22 IO-APIC-level aic7xxx
    > NMI: 0
    > ERR: 0 "
    >
    > In that example, APIC is able to steer interrupts to a particular CPU.
    > CPU0 is getting all the timer interrupts. A high count there would
    > not be a cause for concern, because the timer is being used by
    > the OS a lot.
    >
    > I had great hopes for an article with this title, but in fact
    > the facilities available look pretty poor. "Disabling hardware"
    > is a pathetic way to debug things, especially in a case where
    > the hardware cannot be physically removed, to be sure it is
    > not affecting system state.
    >
    > "Debugging an Interrupt Storm"
    > http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx
    >
    > According to this, when things share an IRQ, an ISR (interrupt
    > service routine) chain is used to sequentially attempt to service
    > the interrupt. Different ISRs are tried until the interrupt is cleared.
    > To get some idea what hardware is interrupting, you'd need
    > the ISR routine to count how many times it successfully
    > handled an interrupt. An ISR may queue up a DPC, to finish
    > handling the interrupt - a DPC runs at user level, rather
    > than interrupt level, and that allows the ISR to be fast
    > and lightweight. Process Explorer can show you the level of
    > DPC activity, which might be proof that real interrupt
    > events are happening (since they finish the servicing
    > needed by the hardware). If there was something wrong
    > with interrupts, perhaps you'd see a mismatch between
    > the time spent handling interrupts, and the amount of
    > DPC activity.
    >
    > http://www.microsoft.com/whdc/archive/apic.mspx
    >
    > "4. The operating system calls the first ISR in the chain.
    > 5. The ISR probes the hardware and attempts to handle the interrupt.
    > 6. If there are additional ISRs, the operating system goes on to
    > the next one and returns to step 5."
    >
    > HTH,
    > Paul
    >
    >>
    >>
    >>
    >> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    >> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >>> "Interrupts" are used by programs to call hardware resources.
    >>>
    >>> For instance : the ps2 mouse is typically Interrupt 12 and the
    >>> operating system (software in itself) and other programs will use
    >>> interrupt 12 to access the mouse.
    >>>
    >>> All interrupts are allocated to a hardware resource.
    >>>
    >>> To see what interrupts are allocated to what hardware on your PC -
    >>>
    >>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
    >>> Device Manager.
    >>>
    >>> Then in Device Manager, click on "View" from the top menus, and then
    >>> select "Resources by type" on the drop-down menu.
    >>>
    >>> Then click on the + sign next to the item named "Interrupt Request
    >>> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >>> hardware and there allocated interrupts.
    >>>
    >>> ==
    >>>
    >>> Cheers, Tim Meddick, Peckham, London. :)
    >>>
    >>>
    >>>
    >>>
    >>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >>> news:i5ms93$lmo$1@news.eternal-september.org...
    >>>> Not seen much about interrupts, and not even entirely sue what they
    >>>> are. But I've noticed - coincidentally or not - that since I did the
    >>>> delete of MS Update software to get back to using the less processor
    >>>> hogging Windows Update, I keep seeing interrupts flare up to a large
    >>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with
    >>>> only 260 meg of memory at the moment. It was recently updated to an
    >>>> 80gig WD hard drive, which seems to be running well, and this is with
    >>>> XPHome SP3 all up to date.
    >>>>
    >>>> There seems to be no way of seeing what these interrupts are for, as
    >>>> they change too quickly to open a properties window for them in
    >>>> Process Explorer. How much of the cpu should they take up? Might they
    >>>> have been an underlying problem that was interfering with MS Update?
    >>>>
    >>>> Cheers,
    >>>>
    >>>> S
    >>>>

    >>
     
  8. Tim Meddick

    Tim Meddick Flightless Bird

    I agree, PE is brilliant and you could ask no more of it.

    But I quote Task Manager because everyone has it, and it conveys the
    message of analysing resource usage by processes.

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    news:i5osqq$beg$1@news.eternal-september.org...
    > Thanks Tim,
    >
    > I'm already using Process Explorer: which is how I could see the
    > interrupts taking up cpu in the handy little graphs that are displayed in
    > the notification area once you replace Task Manager with Process Explorer
    > as I recommend you do, as TM is pretty crude once you have tried PE. In
    > this case the interrupts are taking up cpu not ram, and they are too
    > transient to get any info from other than they can sometimes take as much
    > as 80% of the cpu.
    >
    > I discovered this, like you, after I began looking into windows update
    > taking all my ram, and, apparently, solved that problem, through a
    > comment made by PA Bear. He had asked me to look at how my laptop was
    > accessing the update site. Interestingly, it appeared that I was using
    > windows update as it was going via a link that had something like
    > 'msupdate/windowsudate' in it, but paging down on that site I still
    > found the tick box to uninstall ms update components from my computer. I
    > was surprised to see this, but ticked it and tried again, and the next
    > time I accessed the link there was no tick box at the bottom of the page.
    > Since then the laptop has not hung on updates taking up ram (I haven't
    > actually noticed any updates at all mind...), but I have noticed these
    > interrupts taking up cpu which I had not noticed before. I did wonder if
    > they might represent something still looking for that old update process.
    > (Incidentally I've also deleted all the google updating files from my
    > computer, as I suspected they might be getting in the way too, and had an
    > irritating habit of turning themselves back on no matter how many times I
    > 'disabled' them)
    >
    > Cheers,
    >
    > S
    >
    >
    >
    >
    > "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    > news:%23CoZ7UsSLHA.456@TK2MSFTNGP06.phx.gbl...
    >> To answer you last question, first.
    >>
    >> The reason you have two IEDE channels is that each channel can take two
    >> IDE drives each. So, with two channels, that's space for 4 drives.
    >>
    >> Usually drives are arranged thus :
    >>
    >> Primary IDE Channel [position 1] = Master:- Hard Drive [C:]
    >> [position 2] = Slave:- Hard Drive [D:]
    >>
    >> Secondary IDE Channel [position 1] = Master:- CD/DVD Drive [E:]
    >> [position 2] = Slave:- Hard Drive
    >> [D:]
    >>
    >> ....a cd/dvd drive (when present in a new machine) occupying the 1st
    >> position on the Secondary IDE channel. If a purchaser of a new PC buys
    >> an additional Hard drive for extra media content or space for backups,
    >> it would normally be connected to position 2 of the Primary IDE channel,
    >> making it slave to the system or [c:] drive. While position 2 of the
    >> Secondary IDE channel, would be for a second cd/dvd or maybe a cd/dvd
    >> re-writer. The whole idea behind the PC, is that there is lots of
    >> room, built-in, to accommodate additions, expansions and upgrades....
    >>
    >> As I may have said in a previous post (or many of them), the way to see
    >> what application or "running process" is "hogging" system resources -
    >> and by resources I really mean RAM - is to open the Window's Task
    >> Manager.
    >>
    >> Click on an empty area of the taskbar and right-click on it.
    >>
    >> Choose "Task Manager" from the pop-up menu.
    >>
    >> Click on the column heading "Memory Usage" to make the process-list get
    >> in order, similar to doing the same with files in Explorer. You may
    >> need to click on the heading twice to get them in order - largest mem
    >> usage at the top down to lowest at the bottom.
    >>
    >> The task or process-list, refreshes itself once every five seconds by
    >> default (but you can change that) so by arranging the columns in order
    >> of size of memory usage - then the application or service[es] that
    >> are taking up most RAM are always going to be at the top of the list.
    >>
    >> This is how I found out that Window's Update takes up so much RAM when
    >> it's running, that I can do nothing else on the PC till it's finished
    >> (seeing how I need it, I have to let it run). So, when I feel the
    >> system starting to run a bit slow, I open up Task Manager and if I see
    >> the process "wuauclt.exe" listed, I can go and get a cup of tea and have
    >> a sit down until then.
    >>
    >>
    >>
    >> One is obviously going to be for the system [c:] drive, and an other
    >>
    >> ==
    >>
    >> Cheers, Tim Meddick, Peckham, London. :)
    >>
    >>
    >>
    >>
    >> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >> news:i5ok6m$1vi$1@news.eternal-september.org...
    >>> Thanks Tim,
    >>>
    >>> I've not looked at that part of the device manager before.
    >>>
    >>> There are 16 'Interrupt Request' devices listed, and eight of them use
    >>> the same number: 9.
    >>>
    >>> How do I work out which one or ones are hogging the CPU? And, if I
    >>> understand you right, which part of the system is trying to use that
    >>> interrupt device and causing it to hog the CPU.
    >>>
    >>> Presumably as I don't have much RAM, the hard drive will get a lot of
    >>> activity, but this is fairly new and much quicker than the old one so
    >>> far (Though I don't know why I have two IDE channels and only one hard
    >>> drive?)
    >>>
    >>> Cheers,
    >>>
    >>> S
    >>>
    >>>
    >>>
    >>> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    >>> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >>>> "Interrupts" are used by programs to call hardware resources.
    >>>>
    >>>> For instance : the ps2 mouse is typically Interrupt 12 and the
    >>>> operating system (software in itself) and other programs will use
    >>>> interrupt 12 to access the mouse.
    >>>>
    >>>> All interrupts are allocated to a hardware resource.
    >>>>
    >>>> To see what interrupts are allocated to what hardware on your PC -
    >>>>
    >>>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
    >>>> Device Manager.
    >>>>
    >>>> Then in Device Manager, click on "View" from the top menus, and then
    >>>> select "Resources by type" on the drop-down menu.
    >>>>
    >>>> Then click on the + sign next to the item named "Interrupt Request
    >>>> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >>>> hardware and there allocated interrupts.
    >>>>
    >>>> ==
    >>>>
    >>>> Cheers, Tim Meddick, Peckham, London. :)
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >>>> news:i5ms93$lmo$1@news.eternal-september.org...
    >>>>> Not seen much about interrupts, and not even entirely sue what they
    >>>>> are. But I've noticed - coincidentally or not - that since I did the
    >>>>> delete of MS Update software to get back to using the less processor
    >>>>> hogging Windows Update, I keep seeing interrupts flare up to a large
    >>>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with
    >>>>> only 260 meg of memory at the moment. It was recently updated to an
    >>>>> 80gig WD hard drive, which seems to be running well, and this is with
    >>>>> XPHome SP3 all up to date.
    >>>>>
    >>>>> There seems to be no way of seeing what these interrupts are for, as
    >>>>> they change too quickly to open a properties window for them in
    >>>>> Process Explorer. How much of the cpu should they take up? Might
    >>>>> they have been an underlying problem that was interfering with MS
    >>>>> Update?
    >>>>>
    >>>>> Cheers,
    >>>>>
    >>>>> S
    >>>>>
    >>>>
    >>>
    >>>

    >>

    >
    >
     
  9. Spamlet

    Spamlet Flightless Bird

    "Paul" <nospam@needed.com> wrote in message
    news:i5oq5b$osd$1@speranza.aioe.org...
    > Spamlet wrote:
    >> Thanks Tim,
    >>
    >> I've not looked at that part of the device manager before.
    >>
    >> There are 16 'Interrupt Request' devices listed, and eight of them use
    >> the same number: 9.
    >>
    >> How do I work out which one or ones are hogging the CPU? And, if I
    >> understand you right, which part of the system is trying to use that
    >> interrupt device and causing it to hog the CPU.
    >>
    >> Presumably as I don't have much RAM, the hard drive will get a lot of
    >> activity, but this is fairly new and much quicker than the old one so far
    >> (Though I don't know why I have two IDE channels and only one hard
    >> drive?)
    >>
    >> Cheers,
    >>
    >> S

    >
    > If you see 16 entries, your machine is handling interrupts using PIC
    > (programmable interrupt controller). The other option, is APIC (which
    > may be a BIOS option). APIC has a couple features, such as being able
    > to forward interrupts to a particular processor on a multiprocessor
    > (or multicore) machine. APIC interrupt numbers also go a bit higher,
    > and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
    > can even be used on a single core computer, but in that case, there
    > is no need to steer the interrupts because they all go to the same
    > place.
    >
    > http://en.wikipedia.org/wiki/Intel_APIC_Architecture
    >
    > This is my Device Manager summary report in the interrupt section.
    > I'm running APIC. You can see there is still sharing going on.
    > On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI
    > Express
    > bus), and the chipset, are all sharing the same IRQ. Interrupt
    > handlers have to be able to deal with this sharing.
    >
    > ******************** IRQ SUMMARY ********************
    > IRQ Usage Summary:
    > (ISA) 0 System timer
    > (ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
    > (ISA) 6 Standard floppy disk controller
    > (ISA) 8 System CMOS/real time clock
    > (ISA) 9 Microsoft ACPI-Compliant System
    > (ISA) 13 Numeric data processor
    > (PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
    > (PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
    > (PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
    > (PCI) 16 NVIDIA GeForce 7900 GT/GTO
    > (PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
    > (PCI) 16 Standard Dual Channel PCI IDE Controller
    > (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
    > (PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
    > (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
    > (PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
    > (PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944
    > <---
    > (PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
    > <---
    > (PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
    > (PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver
    > <---
    > (PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
    > (PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
    > (PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
    > (PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
    > (PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 -
    > 29
    > (PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 -
    > 29
    > (PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
    > (PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A
    >
    > I don't know of a tool for logging specific interrupt counts in Windows.
    > In Linux,
    > you can use /proc/interrupts to get the info. I still haven't figured
    > out how to do the equivalent of this in Windows.
    >
    > http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html
    >
    > "3.2.11. /proc/interrupts
    >
    > For a multi-processor machine, this file may look slightly different:
    >
    > CPU0 CPU1
    > 0: 1366814704 0 XT-PIC timer
    > 1: 128 340 IO-APIC-edge keyboard
    > 2: 0 0 XT-PIC cascade
    > 8: 0 1 IO-APIC-edge rtc
    > 12: 5323 5793 IO-APIC-edge PS/2 Mouse
    > 13: 1 0 XT-PIC fpu
    > 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro
    > 10/100 Ethernet
    > 20: 8450043 11120093 IO-APIC-level megaraid
    > 30: 10432 10722 IO-APIC-level aic7xxx
    > 31: 23 22 IO-APIC-level aic7xxx
    > NMI: 0
    > ERR: 0 "
    >
    > In that example, APIC is able to steer interrupts to a particular CPU.
    > CPU0 is getting all the timer interrupts. A high count there would
    > not be a cause for concern, because the timer is being used by
    > the OS a lot.
    >
    > I had great hopes for an article with this title, but in fact
    > the facilities available look pretty poor. "Disabling hardware"
    > is a pathetic way to debug things, especially in a case where
    > the hardware cannot be physically removed, to be sure it is
    > not affecting system state.
    >
    > "Debugging an Interrupt Storm"
    > http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx
    >
    > According to this, when things share an IRQ, an ISR (interrupt
    > service routine) chain is used to sequentially attempt to service
    > the interrupt. Different ISRs are tried until the interrupt is cleared.
    > To get some idea what hardware is interrupting, you'd need
    > the ISR routine to count how many times it successfully
    > handled an interrupt. An ISR may queue up a DPC, to finish
    > handling the interrupt - a DPC runs at user level, rather
    > than interrupt level, and that allows the ISR to be fast
    > and lightweight. Process Explorer can show you the level of
    > DPC activity, which might be proof that real interrupt
    > events are happening (since they finish the servicing
    > needed by the hardware). If there was something wrong
    > with interrupts, perhaps you'd see a mismatch between
    > the time spent handling interrupts, and the amount of
    > DPC activity.
    >
    > http://www.microsoft.com/whdc/archive/apic.mspx
    >
    > "4. The operating system calls the first ISR in the chain.
    > 5. The ISR probes the hardware and attempts to handle the interrupt.
    > 6. If there are additional ISRs, the operating system goes on to
    > the next one and returns to step 5."
    >
    > HTH,
    > Paul


    Thanks Paul, that is more interesting background for me - if a little over
    my head in places.
    I'll have a look at the bios next time I restart, though I doubt if this old
    laptop will give many options.

    Cheers,

    S

    >
    >>
    >>
    >>
    >> "Tim Meddick" <timmeddick@o2.co.uk> wrote in message
    >> news:ubA1N9jSLHA.5716@TK2MSFTNGP02.phx.gbl...
    >>> "Interrupts" are used by programs to call hardware resources.
    >>>
    >>> For instance : the ps2 mouse is typically Interrupt 12 and the
    >>> operating system (software in itself) and other programs will use
    >>> interrupt 12 to access the mouse.
    >>>
    >>> All interrupts are allocated to a hardware resource.
    >>>
    >>> To see what interrupts are allocated to what hardware on your PC -
    >>>
    >>> type "devmgmt.msc" into the "Run"box on the Start Menu to start the
    >>> Device Manager.
    >>>
    >>> Then in Device Manager, click on "View" from the top menus, and then
    >>> select "Resources by type" on the drop-down menu.
    >>>
    >>> Then click on the + sign next to the item named "Interrupt Request
    >>> (IRQ)" - like on a folder in explorer, to see the expanded list of
    >>> hardware and there allocated interrupts.
    >>>
    >>> ==
    >>>
    >>> Cheers, Tim Meddick, Peckham, London. :)
    >>>
    >>>
    >>>
    >>>
    >>> "Spamlet" <spam.morespam@invalid.invalid> wrote in message
    >>> news:i5ms93$lmo$1@news.eternal-september.org...
    >>>> Not seen much about interrupts, and not even entirely sue what they
    >>>> are. But I've noticed - coincidentally or not - that since I did the
    >>>> delete of MS Update software to get back to using the less processor
    >>>> hogging Windows Update, I keep seeing interrupts flare up to a large
    >>>> percentage of the cpu. This is on an old Inspiron 2600 laptop with only
    >>>> 260 meg of memory at the moment. It was recently updated to an 80gig
    >>>> WD hard drive, which seems to be running well, and this is with XPHome
    >>>> SP3 all up to date.
    >>>>
    >>>> There seems to be no way of seeing what these interrupts are for, as
    >>>> they change too quickly to open a properties window for them in Process
    >>>> Explorer. How much of the cpu should they take up? Might they have
    >>>> been an underlying problem that was interfering with MS Update?
    >>>>
    >>>> Cheers,
    >>>>
    >>>> S
    >>>>

    >>
     
  10. Paul

    Paul Flightless Bird

    Tim Meddick wrote:
    > I see that you are focussing on interrupts as a cause of resource
    > hogging - this is not the case.
    >
    > Interrupts are just "hooks" that software uses to access hardware. Of
    > course, when it does, the PC and CPU are limited by the speed of the
    > attached device.
    >
    > But it's very rare, or never, that software stops when a device paused
    > or stops responding.
    >
    > No, it just keeps on processing data and, when it's tried enough times,
    > will simply give up on hardware Interrupts requests.
    >
    > It's usually more likely the case that it's when an application has been
    > asked to do something right at the limits of what is reasonable to
    > expect of it, that problems, including apparent "resource hogging" occur.
    >
    > The simplest and best way to see which process is taking up what
    > percentage of system resources, is to use the Task Manager.
    >
    > ==
    >
    > Cheers, Tim Meddick, Peckham, London. :)
    >


    Of course it can be the case. At least in the case of hardware interrupts,
    the hardware asserts a hardware signal. (On a PCI card, it might be the
    INTA# signal dropping to logic zero, to indicate the card needs service.)

    The motherboard has some kind of logic, to collect up all the interrupt
    reasons, prioritize them, and deliver them to the processor. There is the
    ability to "mask" to a certain interrupt level, for orderly servicing.
    (If you lift the mask all the way up, then no regular interrupts get
    to the processor - such a system could only continue to function, if
    there was a provision for running "polled" instead of in "interrupt"
    mode. Polling is less efficient and would result in a slower system.)

    If a piece of hardware keeps asserting its interrupt signal, on a badly
    designed computer, such an activity could completely block a response
    at the user level. The keyboard wouldn't work, the cursor might not
    move when you move the mouse. And that would be, because there are no longer
    any cycles available to run activities at a user level. All the cycles
    are spent "taking interrupts".

    There are other extremes as well, but this would have been more common
    twenty years ago. At one time, the operation of a hardware subsystem
    might stop, if even one interrupt was "lost". Say, for example, the
    design team misses a detail, and somehow an interrupt is cleared
    before it triggers the service routine. (We used to call those
    spurious interrupts, because the spurious interrupt handler would get
    called and something would be printed on the console screen as a result.)
    If it happened on a network interface card, the result might be no working
    TCP/IP service all of a sudden. Modern systems have a lot more recovery
    features, both for too many interrupts and too few interrupts, for
    this kind of thing to be visible now.

    There are other ways to affect the real time behavior of a system,
    such as make a computer useless for building an audio workstation.
    This is an example of a mechanism - the OS is actually defenseless
    to this hardware feature and can't do anything about it. This feature
    has also been proposed as a means of hacking systems.

    http://en.wikipedia.org/wiki/System_Management_Mode

    and this is how you (indirectly) come to the conclusion that might
    be causing a problem. Within the last few years, there were some
    motherboards that needed a BIOS update, to stop doing that. This
    program was valuable for detecting that the motherboard BIOS
    needed work (i.e. shorten the interval of whatever was running
    as an SMM).

    http://www.thesycon.de/deu/latency_check.shtml

    The red bars here are bad, and indicate the computer may have problems
    handling latency sensitive things like audio. If the delays noted
    here were long enough, you might lose clock tick interrupts, causing
    the Windows clock to lose time.

    http://www.thesycon.de/dpclat/dpclat2.jpg

    Interrupts are more than hooks. They *can* drop a system to its
    knees, depending on the OS, and depending on the interrupt level.
    For example, what happens if you ground the NMI# signal ?
    By the very nature of the name of this signal, the system
    is defenseless to this as well.

    http://en.wikipedia.org/wiki/Non_maskable_interrupt

    This article has more info, and addresses things like software
    interrupts.

    http://en.wikipedia.org/wiki/Interrupt

    "Software interrupt is an interrupt generated within a processor
    by executing an instruction. Software interrupts are often used
    to implement system calls because they implement a subroutine call
    with a CPU ring level change."

    http://en.wikipedia.org/wiki/Interrupt_storm

    "In operating systems, an interrupt storm is an event during which a
    processor receives an inordinate number of interrupts that consume
    the majority of the processor's time. Interrupt storms are typically
    caused by hardware devices that do not support interrupt rate limiting."

    Paul
     
  11. Tim Meddick

    Tim Meddick Flightless Bird

    An interrupt is simply an assigned "handle" - a "hook", if you will, that's
    all it is.

    Software uses these "handles" or "hooks" to call hardware resources.

    If there is a problem, it is in the software process or a piece of
    hardware - it cannot be in an interrupt request!

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Paul" <nospam@needed.com> wrote in message
    news:i5p10e$4c7$1@speranza.aioe.org...
    > Tim Meddick wrote:
    >> I see that you are focussing on interrupts as a cause of resource
    >> hogging - this is not the case.
    >>
    >> Interrupts are just "hooks" that software uses to access hardware. Of
    >> course, when it does, the PC and CPU are limited by the speed of the
    >> attached device.
    >>
    >> But it's very rare, or never, that software stops when a device paused
    >> or stops responding.
    >>
    >> No, it just keeps on processing data and, when it's tried enough times,
    >> will simply give up on hardware Interrupts requests.
    >>
    >> It's usually more likely the case that it's when an application has been
    >> asked to do something right at the limits of what is reasonable to
    >> expect of it, that problems, including apparent "resource hogging"
    >> occur.
    >>
    >> The simplest and best way to see which process is taking up what
    >> percentage of system resources, is to use the Task Manager.
    >>
    >> ==
    >>
    >> Cheers, Tim Meddick, Peckham, London. :)
    >>

    >
    > Of course it can be the case. At least in the case of hardware
    > interrupts,
    > the hardware asserts a hardware signal. (On a PCI card, it might be the
    > INTA# signal dropping to logic zero, to indicate the card needs service.)
    >
    > The motherboard has some kind of logic, to collect up all the interrupt
    > reasons, prioritize them, and deliver them to the processor. There is the
    > ability to "mask" to a certain interrupt level, for orderly servicing.
    > (If you lift the mask all the way up, then no regular interrupts get
    > to the processor - such a system could only continue to function, if
    > there was a provision for running "polled" instead of in "interrupt"
    > mode. Polling is less efficient and would result in a slower system.)
    >
    > If a piece of hardware keeps asserting its interrupt signal, on a badly
    > designed computer, such an activity could completely block a response
    > at the user level. The keyboard wouldn't work, the cursor might not
    > move when you move the mouse. And that would be, because there are no
    > longer
    > any cycles available to run activities at a user level. All the cycles
    > are spent "taking interrupts".
    >
    > There are other extremes as well, but this would have been more common
    > twenty years ago. At one time, the operation of a hardware subsystem
    > might stop, if even one interrupt was "lost". Say, for example, the
    > design team misses a detail, and somehow an interrupt is cleared
    > before it triggers the service routine. (We used to call those
    > spurious interrupts, because the spurious interrupt handler would get
    > called and something would be printed on the console screen as a result.)
    > If it happened on a network interface card, the result might be no
    > working
    > TCP/IP service all of a sudden. Modern systems have a lot more recovery
    > features, both for too many interrupts and too few interrupts, for
    > this kind of thing to be visible now.
    >
    > There are other ways to affect the real time behavior of a system,
    > such as make a computer useless for building an audio workstation.
    > This is an example of a mechanism - the OS is actually defenseless
    > to this hardware feature and can't do anything about it. This feature
    > has also been proposed as a means of hacking systems.
    >
    > http://en.wikipedia.org/wiki/System_Management_Mode
    >
    > and this is how you (indirectly) come to the conclusion that might
    > be causing a problem. Within the last few years, there were some
    > motherboards that needed a BIOS update, to stop doing that. This
    > program was valuable for detecting that the motherboard BIOS
    > needed work (i.e. shorten the interval of whatever was running
    > as an SMM).
    >
    > http://www.thesycon.de/deu/latency_check.shtml
    >
    > The red bars here are bad, and indicate the computer may have problems
    > handling latency sensitive things like audio. If the delays noted
    > here were long enough, you might lose clock tick interrupts, causing
    > the Windows clock to lose time.
    >
    > http://www.thesycon.de/dpclat/dpclat2.jpg
    >
    > Interrupts are more than hooks. They *can* drop a system to its
    > knees, depending on the OS, and depending on the interrupt level.
    > For example, what happens if you ground the NMI# signal ?
    > By the very nature of the name of this signal, the system
    > is defenseless to this as well.
    >
    > http://en.wikipedia.org/wiki/Non_maskable_interrupt
    >
    > This article has more info, and addresses things like software
    > interrupts.
    >
    > http://en.wikipedia.org/wiki/Interrupt
    >
    > "Software interrupt is an interrupt generated within a processor
    > by executing an instruction. Software interrupts are often used
    > to implement system calls because they implement a subroutine call
    > with a CPU ring level change."
    >
    > http://en.wikipedia.org/wiki/Interrupt_storm
    >
    > "In operating systems, an interrupt storm is an event during which a
    > processor receives an inordinate number of interrupts that consume
    > the majority of the processor's time. Interrupt storms are typically
    > caused by hardware devices that do not support interrupt rate
    > limiting."
    >
    > Paul
     
  12. Paul

    Paul Flightless Bird

    Tim Meddick wrote:
    > An interrupt is simply an assigned "handle" - a "hook", if you will,
    > that's all it is.
    >
    > Software uses these "handles" or "hooks" to call hardware resources.
    >
    > If there is a problem, it is in the software process or a piece of
    > hardware - it cannot be in an interrupt request!
    >
    > ==
    >
    > Cheers, Tim Meddick, Peckham, London. :)


    Nope.

    The process starts with a hardware signal. As long as the particular interrupt
    level is not masked, the processor stacks the current context (whatever is
    running) and "takes an interrupt". That is a context switch, and means the
    current process is no longer running. The interrupt handler is running.

    A short time later, the interrupt handler has looked at hardware registers
    in the chip, and concluded it needs to be serviced. Using whatever feature
    the chip has for clearing the interrupt, the handler attempts to clear
    the interrupt. The hardware interrupt signal rises to the de-asserted
    state.

    Interrupt signal ---------- -----------------------
    |_______________|

    Interrupt Handler
    Handler Clears
    Triggered Interrupt
    (Context switch)

    Context user_level -------- ------------------
    interrupt_level | |
    ----------------------
    (return from
    interrupt
    handler)

    DPC ------------------------------------------------| |----

    Queued DPC
    finishes interrupt
    cleanup at user level

    Some time after the interrupt is cleared, the interrupt handler returns
    control to the next thing on the stack, which was that user process that
    was running.

    Since the interrupt handler, also queued a DPC to be run later, once the
    DPC queue has been drained, eventually that DPC will get serviced. It
    runs at a lower priority (same priority as other user processes), and
    is allowed to spend more time dealing with the hardware. The
    interrupt handler itself is not allowed to spend a lot of time
    handling an interrupt, because of the effect this has on
    real time performance. The execution of the DPC, is allowed to be
    interrupted at any time, just like a user process can be interrupted.

    In summary:

    1) It's not a "hook".

    2) It's practically a mechanical process. Interrupt signal drops (asserted state).
    Processor drops what it is doing, and the interrupt handler runs as
    soon as the execution pipeline can be drained enough to allow it
    (nanoseconds). Processors have out-of-order execution, and the
    execution pipeline has to be clean enough, for the interrupt handler
    to start running. But the time to do that is pretty short.

    3) The interrupt handler only does enough work, so that the interrupt
    can be cleared. The queuing of a DPC, allows the OS to be effectively
    notified that an event has happened on the device (like a packet
    arrived on the Ethernet chip and has been automatically moved into
    system memory via DMA, into one of the memory areas defined by the
    ring buffer), and that further processing is required.

    4) By returning very quickly, the interrupt handler allows other devices
    with a similar priority, to have their interrupts handled.

    5) The queuing of a DPC, allows milliseconds to be spent later, cleaning
    up ring buffers (adding new buffers to the ring) and the like, so there
    is room for new packets to be received. Or for new commands to be
    sent to the hardware.

    The purpose of an interrupt, is so the processor doesn't have to keep
    checking that a piece of hardware is "ready". The hardware delivers
    a signal, which "wakes" up the processor to the good news. The processor
    can be running your copy of Firefox, so all its effort goes into
    rendering a web page. But when the hardware finishes some task you
    gave it, the hardware interrupt signal causes the processor to immediately
    pay attention to the good news (even if a picture is half-painted in
    Firefox, the interrupt will still be "taken"). The interrupt is efficient,
    because no processor cycles are wasted checking "are you ready yet".
    The processor is alerted immediately by a hardware signal.

    You can find other diagrams of this sort of thing, but it's pretty
    hard for me to find a nice diagram I can write words around.

    http://prex.sourceforge.net/doc/img/irq.gif

    In the event of an "interrupt storm", there is a defect in this
    process, where the processor is getting interrupted way more often
    than it should. If a hardware defect allows the interrupt signal
    to stay in the asserted state, on older computer designs, the
    system would effectively be frozen (since user processes would
    be starved of cycles). The terminology is common enough, to have
    its own Wikipedia article.

    http://en.wikipedia.org/wiki/Interrupt_storm

    And a lack of interrupt rate limiting, is not the only reason for
    storms. There is at least one common peripheral chip in computers,
    where a small percentage of shipped parts had a timing problem,
    and would create their own "storms". It resulted in some users
    experiencing slowdowns or freezing, while other users of the same
    brand of equipment, wouldn't see any problems. And this is the
    reason "Spamlet", the original poster, is interested in what
    is going on in Process Explorer.

    Paul
     
  13. Yousuf Khan

    Yousuf Khan Flightless Bird

    On 9/2/2010 4:03 PM, Spamlet wrote:
    > Thanks Paul, that is more interesting background for me - if a little over
    > my head in places.
    > I'll have a look at the bios next time I restart, though I doubt if this old
    > laptop will give many options.
    >
    > Cheers,
    >
    > S


    Another interesting thing to note is that Windows XP doesn't use APIC
    interrupts very well. In XP, at most it'll use upto 25 separate
    interrupts for all of your hardware onboard. It'll usually even share
    several pieces of hardware on the same interrupt number. This is fine if
    you got for example two separate USB controllers, and they are on the
    same interrupt, as they are doing the same thing. But when you start
    sharing USB interrupts with video interrupts, and hard disk interrupts,
    then you're going to have a lot of contention.

    Windows 7 (and I gather Vista as well, but who cares?) can use tens of
    thousands of different interrupt numbers using the same APIC hardware.
    Almost no need to share any interrupts at all.

    Yousuf Khan
     
  14. Paul

    Paul Flightless Bird

    Yousuf Khan wrote:
    > On 9/2/2010 4:03 PM, Spamlet wrote:
    >> Thanks Paul, that is more interesting background for me - if a little
    >> over
    >> my head in places.
    >> I'll have a look at the bios next time I restart, though I doubt if
    >> this old
    >> laptop will give many options.
    >>
    >> Cheers,
    >>
    >> S

    >
    > Another interesting thing to note is that Windows XP doesn't use APIC
    > interrupts very well. In XP, at most it'll use upto 25 separate
    > interrupts for all of your hardware onboard. It'll usually even share
    > several pieces of hardware on the same interrupt number. This is fine if
    > you got for example two separate USB controllers, and they are on the
    > same interrupt, as they are doing the same thing. But when you start
    > sharing USB interrupts with video interrupts, and hard disk interrupts,
    > then you're going to have a lot of contention.
    >
    > Windows 7 (and I gather Vista as well, but who cares?) can use tens of
    > thousands of different interrupt numbers using the same APIC hardware.
    > Almost no need to share any interrupts at all.
    >
    > Yousuf Khan


    Perhaps something like this.

    http://en.wikipedia.org/wiki/Message_Signaled_Interrupts

    I wonder if any of the hardware in my computer supports that ?
    And how would I know if it was being used ? Device manager
    shows the same old boring 0..23 IRQs of Intel APIC.
    (AMD did a version with 32, that never caught on.)
    If there were MSIs on my system (with WinXP SP3),
    where would they be documented ?

    Paul
     
  15. Yousuf Khan

    Yousuf Khan Flightless Bird

    On 9/4/2010 1:26 AM, Paul wrote:
    > Perhaps something like this.
    >
    > http://en.wikipedia.org/wiki/Message_Signaled_Interrupts
    >
    > I wonder if any of the hardware in my computer supports that ?
    > And how would I know if it was being used ? Device manager
    > shows the same old boring 0..23 IRQs of Intel APIC.
    > (AMD did a version with 32, that never caught on.)
    > If there were MSIs on my system (with WinXP SP3),
    > where would they be documented ?
    >
    > Paul


    No, MSI is simply how PCI-express (which is a serial data interface)
    gets the attention of the CPU, without having its own dedicated
    interrupt pin. In the old days, of PCI and earlier, all hardware
    produced its own interrupts through a special pin. With serial
    interfaces they do not have a separate pin for that, so it sends a
    special message to the PCI-express chipset asking it to assert an
    interrupt for it on the CPU. However, this has nothing to do with how
    many interrupt numbers you can have.

    As for the AMD Open PIC system, it was a system for distributing
    interrupts around to multiple processors, upto 32 of them in total.
    Intel's multi-processor PIC system was called MPIC. AMD eventually
    abandoned OpenPIC for MPIC. Again, it has nothing to do with how many
    interrupt numbers you have, just how many processors can receive interrupts.

    Yousuf Khan
     
  16. Tim Meddick

    Tim Meddick Flightless Bird

    Fine - you go ahead and blame your PIC for excessive resource hogging -
    don't bother investigating which processes are actually involved in taking
    up to much cpu time / memory!

    ==

    Cheers, Tim Meddick, Peckham, London. :)




    "Paul" <nospam@needed.com> wrote in message
    news:i5rq6h$15c$1@speranza.aioe.org...
    > Tim Meddick wrote:
    >> An interrupt is simply an assigned "handle" - a "hook", if you will,
    >> that's all it is.
    >>
    >> Software uses these "handles" or "hooks" to call hardware resources.
    >>
    >> If there is a problem, it is in the software process or a piece of
    >> hardware - it cannot be in an interrupt request!
    >>
    >> ==
    >>
    >> Cheers, Tim Meddick, Peckham, London. :)

    >
    > Nope.
    >
    > The process starts with a hardware signal. As long as the particular
    > interrupt
    > level is not masked, the processor stacks the current context (whatever
    > is
    > running) and "takes an interrupt". That is a context switch, and means
    > the
    > current process is no longer running. The interrupt handler is running.
    >
    > A short time later, the interrupt handler has looked at hardware
    > registers
    > in the chip, and concluded it needs to be serviced. Using whatever
    > feature
    > the chip has for clearing the interrupt, the handler attempts to clear
    > the interrupt. The hardware interrupt signal rises to the de-asserted
    > state.
    >
    > Interrupt signal ---------- -----------------------
    > |_______________|
    >
    > Interrupt Handler
    > Handler Clears
    > Triggered Interrupt
    > (Context switch)
    >
    > Context user_level -------- ------------------
    > interrupt_level | |
    > ----------------------
    > (return from
    > interrupt
    > handler)
    >
    > DPC ------------------------------------------------|
    > |----
    >
    > Queued DPC
    > finishes
    > interrupt
    > cleanup at
    > user level
    >
    > Some time after the interrupt is cleared, the interrupt handler returns
    > control to the next thing on the stack, which was that user process that
    > was running.
    >
    > Since the interrupt handler, also queued a DPC to be run later, once the
    > DPC queue has been drained, eventually that DPC will get serviced. It
    > runs at a lower priority (same priority as other user processes), and
    > is allowed to spend more time dealing with the hardware. The
    > interrupt handler itself is not allowed to spend a lot of time
    > handling an interrupt, because of the effect this has on
    > real time performance. The execution of the DPC, is allowed to be
    > interrupted at any time, just like a user process can be interrupted.
    >
    > In summary:
    >
    > 1) It's not a "hook".
    >
    > 2) It's practically a mechanical process. Interrupt signal drops
    > (asserted state).
    > Processor drops what it is doing, and the interrupt handler runs as
    > soon as the execution pipeline can be drained enough to allow it
    > (nanoseconds). Processors have out-of-order execution, and the
    > execution pipeline has to be clean enough, for the interrupt handler
    > to start running. But the time to do that is pretty short.
    >
    > 3) The interrupt handler only does enough work, so that the interrupt
    > can be cleared. The queuing of a DPC, allows the OS to be effectively
    > notified that an event has happened on the device (like a packet
    > arrived on the Ethernet chip and has been automatically moved into
    > system memory via DMA, into one of the memory areas defined by the
    > ring buffer), and that further processing is required.
    >
    > 4) By returning very quickly, the interrupt handler allows other devices
    > with a similar priority, to have their interrupts handled.
    >
    > 5) The queuing of a DPC, allows milliseconds to be spent later, cleaning
    > up ring buffers (adding new buffers to the ring) and the like, so
    > there
    > is room for new packets to be received. Or for new commands to be
    > sent to the hardware.
    >
    > The purpose of an interrupt, is so the processor doesn't have to keep
    > checking that a piece of hardware is "ready". The hardware delivers
    > a signal, which "wakes" up the processor to the good news. The processor
    > can be running your copy of Firefox, so all its effort goes into
    > rendering a web page. But when the hardware finishes some task you
    > gave it, the hardware interrupt signal causes the processor to
    > immediately
    > pay attention to the good news (even if a picture is half-painted in
    > Firefox, the interrupt will still be "taken"). The interrupt is
    > efficient,
    > because no processor cycles are wasted checking "are you ready yet".
    > The processor is alerted immediately by a hardware signal.
    >
    > You can find other diagrams of this sort of thing, but it's pretty
    > hard for me to find a nice diagram I can write words around.
    >
    > http://prex.sourceforge.net/doc/img/irq.gif
    >
    > In the event of an "interrupt storm", there is a defect in this
    > process, where the processor is getting interrupted way more often
    > than it should. If a hardware defect allows the interrupt signal
    > to stay in the asserted state, on older computer designs, the
    > system would effectively be frozen (since user processes would
    > be starved of cycles). The terminology is common enough, to have
    > its own Wikipedia article.
    >
    > http://en.wikipedia.org/wiki/Interrupt_storm
    >
    > And a lack of interrupt rate limiting, is not the only reason for
    > storms. There is at least one common peripheral chip in computers,
    > where a small percentage of shipped parts had a timing problem,
    > and would create their own "storms". It resulted in some users
    > experiencing slowdowns or freezing, while other users of the same
    > brand of equipment, wouldn't see any problems. And this is the
    > reason "Spamlet", the original poster, is interested in what
    > is going on in Process Explorer.
    >
    > Paul
     

Share This Page