operating systems - Can someone explain to me how the CPU finds the source of an interrupt in OS theory?

operating-systems interrupts

06
2014-04

user54094

I am currently doing a module in Operating Systems theory and I have a few concepts that I am unable to grasp - would this be the right place to ask questions ?

My main question is about interrupts. When the CPU detects that there has been an interrupt, I understand that it must find out where this interrupt originated. My understanding is as follows, could anyone tell me if this is correct, and explain a few gaps in my knowledge ?

For the CPU to detect where the interrupt originated, it could query all objects to identify the source, but these I/O based questions would take a long time. Instead, it uses the interrupt cycle, and expects an interrupt identifier on the data bus. If it is an 8 bit data bus, there is 256 interrupt levels (i.e 2^8). (Why is this?)

So an Interrupt Service Routine (ISR) is written for every possible interrupt level and stored in a table at a fixed location (interrupt vector) which is standardized by the processor. In my notes is says "Location must be known before getting the address" (What does this mean?)

The interrupt level identifier received as part of the interrupt cycle is used as an index into the interrupt vector (Can someone break this down a little please?). My understanding is that a value, the interrupt level identifier is passed to the CPU and used to point at the interrupt vector.

Also, what does it mean when an interrupt is said to be "serviced"?

Thank you very much, and sorry for the long paragraphs, I am just a little confused by many aspects of this !

Answers

Tangurena

what does it mean when an interrupt is said to be "serviced"?

When the thing requesting the interrupt is taken care of, then it is called "serviced." This could be as simple as reading the next character from the keyboard, or sending the next packet of data out the ethernet card. Some interrupts are more important than others, so there is the capability to prioritize them.

A useful article can be found here.

The interrupt level identifier received as part of the interrupt cycle is used as an index into the interrupt vector

As you mentioned, when an interrupt happens, the CPU basically asked "who did that?" and the interrupting device puts its interrupt identifier on the data bus. The CPU then takes this number and looks it up into the table of ISR to transfer execution to the handler.

An interrupt is a request of the processor to suspend its current program and transfer control to a new program called the Interrupt Service Routine (ISR). Special hardware mechanisms that are designed for maximum speed force the transfer. The ISR determines the cause of the interrupt, takes the appropriate action, and then returns control to the original process that was suspended.

ultrasawblade

Instead, it uses the interrupt cycle, and expects an interrupt identifier on the data bus. If it is an 8 bit data bus, there is 256 interrupt levels (i.e 2^8). (Why is this?)

The alternative to doing that is to have a pin on the CPU for each IRQ type or level you want to support. The 68000 did this, they had 3 interrupt pins allowing you to express IRQ level 0 (NMI) through 7. Intel CPUs only have 1 IRQ pin and expect an address on the bus (provided by an intermediate device called the PIC) to provide its type (I think on Intel this "address", really an index, goes directly into a register. Some PICs can actually tell the CPU what address to go to directly).

I believe they have a separate NMI pin (and there are other interrupts with their own pins such as SMI, IPI, and a reset is a type of interrupt).

So an Interrupt Service Routine (ISR) is written for every possible interrupt level and stored in a table at a fixed location (interrupt vector) which is standardized by the processor.

You don't need to write 256 ISRs, you can create a "stub" that simply "returns from interrupt", effectively ignoring it.

In my notes is says "Location must be known before getting the address" (What does this mean?)

It's a bit ambiguous - I don't know if it means you need to know the base address of the vector table or simply saying you can't know the address of the ISR if you don't know the IRQ number involved.

The interrupt level identifier received as part of the interrupt cycle is used as an index into the interrupt vector (Can someone break this down a little please?).

PIC receives an IRQ from a device. This device is set to trigger IRQ #3. CPU, upon receiving the IRQ from the PIC, sees 3 on the bus, and jumps to the address in its local IRQ vector table, index 3.

My understanding is that a value, the interrupt level identifier is passed to the CPU and used to point at the interrupt vector.

Right.

Also, what does it mean when an interrupt is said to be "serviced"?

Typically you don't want the CPU interrupted while it's handing an interrupt. CPUs and CPU + PIC combinations do various things to disable interrupts after an IRQ is received. So you have to "announce" when you're done handling it. On Intel you have to reenable the system interrupt-enable bit, and tell the PIC you are done servicing the IRQ. The PIC "holds back" further IRQs until the CPU tells it that it's done.

I've left out some details from the above to simplify and also because it's been a long time since I've studied any of the above, but I hope it is helpful.

Update 1:

I've checked several times, and there aren't any new drivers available for my box. (There is a new display driver, but Sony hasn't respun it with their special hooks, so it won't work on this box.)

I don't see that "walking the stack" would do any good since the "looping" is in interrupts, not any specific process. I suppose I could try to do an interrupt trace, but it would likely take a lot of time that I don't have.

Update 2:

Update: Today I experienced the failure while running on battery, the first time that has happened. So I know of no conditions that prevent the failure.

Re turning off Windows services such as search indexing, I did that a long time ago.

Update 3: (5/21/11)

On a whim I unplugged the network cable and have been running wireless at home and at work for the past two days. (I don't generally like to run wireless if I don't need to since I figure there's already too much RF pollution.) No episodes have occurred. Weird.

Update 4: (5/30/11)

I've been running for the past 11 or so days, using wireless only. (Not something I normally like to do, since I feel there's too much RF pollution already and no need to add more when a wired connection is available.) And for the past 11 days I've not had an "incident" -- by far the longest incident-free time I've seen. In a day or two I'll start plugging in again and see what happens.

Update 5: (6/2/11)

As a result of a wireless router outage at work, I had to use the wired connection there for two days, and the old behavior (40% or so "events" after 30-60 minutes of up-time) returned. Curious thing, though: On both days, when I brought the laptop home and connected to wireless, the problem would recur within a few minutes. But once I did a "sleep" and "reawaken" the problem would be permanently gone.

To bring the laptop home I'd sleep it, but somehow the "bug" survived through that. Or, quite possibly, the wired interface didn't get reset until after reawakening, and it did something nasty during those few seconds.

Just for reference, the wired adapter is a "Marvell Yukon 88E8040 PCI-E Fast Ethernet Controller". It would be interesting to know if the same adapter is associated with other cases of this problem.

Update 6: (6/6/11)

I'm beginning to suspect that somehow the wireless adapter is the culprit. When it's turned off it can somehow corrupt the system. I say this because the router at work is a little "funky" and I sometimes have to turn the wireless off and back on (via a mechanical switch on the front of the laptop) to get a connection. When I do this, inevitably within a few minutes (not immediately) I get the interrupts back. Sleeping and reawakening the laptop clears the interrupt problem, seemingly permanently (until the next time the wireless is turned off). For the record, the wireless adapter is a "Intel(R) WiFi Link 5100 AGN", though it could be more of a problem with the way the switch is implemented.

Update 7: (7/5/11)

I've been running for over a month now on the wireless network adapter (vs hardwired) and the problem has essentially gone away. A few times (due to losing connectivity for some reason) I've turned the adapter off for several seconds and then back on, to reset it. In all but one of these cases, as good as I can remember, I got the 50% CPU problem after the off/on cycle, though, curiously, in several cases the problem didn't appear for 30 minutes or more after the off/on.

Update 8: (7/18/13)

About 10 months ago I had to completely restore my system from backup, and since then I've not seen the 50% cpu problem. (Haven't tried to deliberately provoke it, but the radio has been accidentally turned off on several occasions.) Of course, no Windows bug ever goes away completely, so now I have a problem with Open Office crashing, but I guess I can live with that.

Home