Talk:Interrupt

INitial text

list of default PC IRQs, not sure if for this page since it's platform-specific: http://www.kblearning.com/a+studysite/aplusdiagrams/irqs.htm

---

This line bugs me:

The waiting still occurs. Normally, the computer's microcode continually tests for an interrupt.

• Firstly this implies falsely that all processors are microcoded
• Secondly a processor polling for an interrupt signal at a specific point in a processing cycle does not involve waiting, just a decision point.

--Minority Report 21:46, 7 Nov 2004 (UTC)

Opinion removals

"Computers are now so cheap that this argument makes less sense." This is a judgement call as to wether or not efficiency is important. If there is a replacement comment about a more efficient solution, that should be mentioned instead.

power line atomic clock?

this article says no http://www.saultstar.com/webapp/sitepages/content.asp?contentID=70740&catname=Local+News - Omegatron 21:34, Oct 13, 2004 (UTC)

Interrupt handler

There is another page, Interrupt_handler which I find reads very strangely ("it is the progression of"? needs work) and is in need of additional information, but I believe everything it contains also appears in this article. I do not believe it needs to be an article itself. I propose that it be replaced with a redirect here. Celada 04:03, 2004 Nov 21 (UTC)

Relating Interrupt Articles

There are a number of interrupt articles that seem to have no direction and a large amount of redundant information. I'm trying to organize them as I track them down.

I figure the layout should be as given below. There should be a seperate page for each Main. Each page should have redundent content eliminated, instead links should be placed to the appropriate main page. Of course, each Main page should be expanded apon. This includes a good introduction, history, features, programming information, references, etc.

Feel free to add additional links to this collection.

Catagory: Category: Interrupts

Specific Hardware:

• Main: Intel 8259
  • Redirects: Intel 8259A, 8259, 8259A, 8259B
• Main: Intel APIC Architecture
  • Redirects: Local APIC, IOAPIC, IO-APIC

• Main: STI (x86 instruction)
• Main: CLI (x86 instruction)
• Main: INT (x86 instruction)
  • Redirects: X86-int

General Hardware:

• Main: Programmable Interrupt Controller
  • Redirects: Interrupt controller
• Main: Advanced Programmable Interrupt Controller
  • Redirects: APIC, Apic
• Main: Maskable interrupt
  • Redirects: Masked interrupt
• Main: Non-Maskable interrupt
  • Redirects: Non-Maskable Interrupt, Non-maskable interrupt, Non maskable interrupt, Non-Maskable Interrupts, Non-Maskable interrupts,
• Main: Interprocessor Interrupt
  • Disambig: IPI

• TODO: Interrupt request register, Interrupt mask register, In-Service register
  • Disambig: IMR, ISR, IRR

General Information

• Main: Interrupt
  • Redirects: Interrupts, Hardware interrupt, Software Interrupt, Spurious Interrupt, Interrupt mask

• Main: Interrupt request
  • Redirects: Interrupt Request, IRQ
• Main: Polled Interrupts

• Main: end of interrupt
  • Redirects: EOI

• Main: Interrupt Descriptor Table
  • Disambig: IDT
• Main: Interrupt vector
  • Disambig: IVT
  • Redirects: interrupt vector table

• Main: SPL (computer science)
  • Disambig: SPL
• Main: Interrupt priority level
  • Disambig: IPL

Software

• Main: Interrupt handler
  • Redirects: Interrupt Handler, Interrupt routines, Interrupt Service Routine, Interrupt service routine

Performance

• Main: Interrupt Storm
  • Redirects: Interrupt storm
• Main: Interrupt latency
  • Redirects: Interrupt Latency
• Main: Livelock (computer science)

Asynchronous?

From article: "an interrupt is an asynchronous signal from hardware or software indicating the need for attention". The article later goes on to explain synchronous interrupts caused by software. I am not an expert on this but this appears to be an error. -- Bubbachuck 05:07, 28 October 2006 (UTC)

"Synchronous interrupts" aren't really interrupts. 195.224.75.71 13:48, 21 November 2006 (UTC)

Ashu on wiki 01:20, 12 December 2006 (UTC) An interrupt is understood by the processor only when it is checked for. So, if a processor checks for interrupts only after the execute cycle of an instruction, even an asynchronous interrupt cannot be understood at any other time. Software interrupts are more predicatble in the sense that they can be part of dry run of a program. On the other hand, interrupts caused by other hardware is completely unpredictable for the program.

Whatever the source (software or hardware), an interrupt is always handled by the processor synchronously: before executing the next instruction pointed to by program counter (PC), if an interrupt has been signaled, then at the next clock cycle, the processor saves the current context and jumps to a special routine (generally in ROM) that manages any kind of interrupts (which generally consumes some clock cycles before the real processing occurs).

Instructions are always executed on clock cycles (even for interruption processing). So asynchronous is not really the appropriate term; we should prefer software-triggered or hardware-triggered, but the consequent behavior is the same.

Note also that due to this extra-processing, latency between the event and start of useful interrupt processing is never null (but is often negligible) and depends on the processor family. Teuxe (talk) 15:10, 18 September 2012 (UTC)

how come this article does not contain a paragraph about 'IRR'

IRR redirects here. but i can't find no explanation. --

You probably meant Interrupt Request Register? This is an implementation-specific register that may not be general enough to be explained in this article. Presently IRR points to a disambiguation page with no reference to this Interrupt Request Register.

IRR could be introduced as an example of register, if a general algorithm for interrupt processing is described in this article. Teuxe (talk) 15:19, 18 September 2012 (UTC)

I added this definition to IRR, but redirecting to programmable interrupt controller which is more appropriate. Teuxe (talk) 15:32, 18 September 2012 (UTC)

Multiprocessing?

What happens to the interrupt if the computer has more than one processor? What determines which processor will handle the interrupt? 71.196.223.172 (talk) 19:37, 24 December 2009 (UTC)

Each interrupt line is always routed to a single processor. You may see different interrupt lines be mapped to different processors (for various reasons), but never will two processors be interrupted by the same hardware line. Teuxe (talk) 15:23, 18 September 2012 (UTC)

The answer depends very much on the architecture.

Generally speaking, the processor generating a synchronous interrupt handles it, but in, e.g., the Burroughs B5000, a processor designated as master handles all interrupts; a processor designated as a slave processor halts when the master processor is handling an interrupt on its behalf.

On some systems, e.g., an IBM System/360 Model 65, a specific input/output channel or device can only be accessed by a single processor, and the channel or device generates interrupts on that processor. On other systems, e.g., IBM System/370 Extended Architecture (S/370-XA), any processor can access and channel or device. Depending on the architecture, the interrupt may be handled by any enabled processor or only by the processor that initiated the I/O.

Inter-processor interrupts are always handled by the target processor. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:07, 19 January 2022 (UTC)

Interrupt routine example

I propose for deletion the interrupt routine example (for PIC MCU) placed on the article. This example is messy, contains unrelated functionality, looks pretty odd and occupies about one third of content. I think that interrupt handler routines (and related functionality) are very platform dependent (and can be very easily found in reference documentation), so in this article we must concentrate on common aspects without examples. If nobody against - I will delete it in a week time. Pmod (talk) 20:04, 2 April 2010 (UTC)

Totally Agreed. 129.27.142.133 (talk) 11:12, 6 August 2010 (UTC)

Sharing interrupt lines

As currently described the article leaves an impression that there are severe problems in sharing interrupt lines. In present day architectures the problems have been well solved by interrupt controllers, which can quickly identify and prioritize the interrupt sources and which can be used by software interrupt servers to implement prioritized interrupt handling of any desired complexity. The plain wired-or architecture, which is behind the claims in the architecture, is quite obsolete except in simplest systems. (This is not to say that wired-or itself is obsolete, only in this context.) Even with properly implemented wired-or architecture the problem of multiple interrupt sources of different priorities can be solved by having masking at the generating end and by using software interrupt request queuing. The article should be changed and expanded to reflect the current state of art.Lauri.pirttiaho (talk) 15:08, 29 January 2011 (UTC)

Look out for possible copyright violations in this article

This article has been found to be edited by students of the Wikipedia:India Education Program project as part of their (still ongoing) course-work. Unfortunately, many of the edits in this program so far have been identified as plain copy-jobs from books and online resources and therefore had to be reverted. See the India Education Program talk page for details. In order to maintain the WP standards and policies, let's all have a careful eye on this and other related articles to ensure that no material violating copyrights remains in here. --Matthiaspaul (talk) 15:20, 30 October 2011 (UTC)

Suggest merge

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was to rename the source article. — Dsimic (talk | contribs) 04:09, 13 November 2014 (UTC)

---

Once Interrupt request is made generic and not a specific list of IBM PC hardware data, it would seem to be redundant with this article and could usefully be merged here. --Wtshymanski (talk) 16:29, 4 November 2014 (UTC)

• Support: Makes sense to me. — Dsimic (talk | contribs) 06:41, 5 November 2014 (UTC)

• Support: But I would suggest a different method. Restore the PC-specific material to Interrupt request, move the generic stuff from there to here, and rename Interrupt request to something PC-specific. Jeh (talk) 09:59, 5 November 2014 (UTC)

Hm, as there isn't that much content in Interrupt request in the first place, how about creating new section Interrupt § Platform-specific details (or similar) instead and moving there what would be left in Interrupt request? Just so we don't end up with a really short article that's hardly going to grow bigger? At the same time, I'm really unable to come with a good PC-specific name to which Interrupt request could be renamed. — Dsimic (talk | contribs) 01:47, 6 November 2014 (UTC)

When I said "restore the PC-specific material", I was referring to going back to this version. This approach would better preserve the edit history.

As for the name, a poor name will do for starters; it can always be moved to a better one. Jeh (talk) 04:08, 6 November 2014 (UTC)

Thank you for the clarification. It all makes sense, and the only thing that still confuses me a bit is what would remain in the Interrupt request article? PC-specific stuff, like IRQ assignments from the revision linked above? — Dsimic (talk | contribs) 06:25, 6 November 2014 (UTC)

You mean in the ~"Interrupts on PC architecture" article ;) Yes, basically everything Wtshymanski removed with the edit just after that version. Jeh (talk) 08:40, 6 November 2014 (UTC)

Right, and that might be the new article title. :) Totally agreed, it's much better to keep platform-specific information separate from general descriptions. — Dsimic (talk | contribs) 09:33, 6 November 2014 (UTC)

How about I undo this edit [1] and then move Interrupt request to Interrupt request (PC architecture) till someone comes up with a better title for it? Even better than a merge. --Wtshymanski (talk) 19:51, 6 November 2014 (UTC)

I'd say that would be good, as this version of the Interrupt request article is pretty well rounded up, and there isn't much what could be merged into the Interrupt article. Of course, we need to hear from Jeh as well. :) — Dsimic (talk | contribs) 20:14, 6 November 2014 (UTC)

Done. --Wtshymanski (talk) 21:12, 12 November 2014 (UTC)

Sorry, I missed the TP updates. But that was what I proposed already so I can't imagine why I would have objected. Jeh (talk) 21:20, 12 November 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Exit from interrupt service routine

I just reverted an edit that says that after an ISR the processor resumes normal activity " where it left off." I changed similar text a while ago. I'd like to see a consensus on this. I think this may be true of Linux, but my understanding is that in many OSs the ISR exits to the dispatcher to run the highest priority ready task, which might not be the interrupted task. Peter Flass (talk) 12:09, 22 December 2014 (UTC)

Hello! It's much better to be as less specific as possible on this; returning back to "where it left off" isn't the case even for the Linux kernel, here's a quote from the Linux Device Drivers, third edition, chapter 10. Interrupt Handling, page 269:

Then it's just a matter of cleaning up, running software interrupts, and getting back to regular work. The "regular work" may well have changed as a result of an interrupt (the handler could wake_up a process, for example), so the last thing that happens on return from an interrupt is a possible rescheduling of the processor.

I've also added this into the article's lead section as a reference. — Dsimic (talk | contribs) 18:42, 25 December 2014 (UTC)

History?

It would be interesting to have a "history" section that says when/where interrupts first appeared. Some other versions of this article have one, though without source citations: the Dutch version explicitly says that the Electrologica X1 was the first (that would make the answer 1958, the year that machine first shipped) and the German one says that interrupts appeared "in the 1960, for example in the Electrologica X1" [sic]. Dijkstra's review paper (Dijkstra, Edsger W. EWD-1303 (PDF). E.W. Dijkstra Archive. Center for American History, University of Texas at Austin. (transcription)) shows that he started working with interrupts in 1957 in the X1 design, but that does not say definitively that this was the first design with interrupts. !!!!

The March 1956 UNIVAC 1103A is usually cited as the first computer with an interrupt and the January 1957 (shipped August 1958) IBM 709 is usually cited as the first to have I/O interrupts. However, some military computers may have been there first. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:45, 31 May 2020 (UTC)

02/2019 Tasklets

Seems like article could be missing some reference to tasklets., Tech201805 (talk)

References

Interrupts from "internal" timers

In my professional experience, timers are I/O devices which are external to the processor, and interrupt requests are control lines into the processor from external devices. Based on this, I deleted the claim that hardware timers (which issue interrupt requests) are internal circuits within processors. My edit was reverted, with an edit summary that says "a timer is part of some processors". No supporting RS is provided for this claim and, since it contradicts my knowledge of this topic, I've marked it dubious. Lambtron talk 14:09, 29 May 2020 (UTC)

Does your professional experience extend to either mainframes or to computers before the era of LSI? Timers as separate components are characteristic of microprocessors. The fact is that some timing facilities, e.g., CPU timer on an IBM System/370 through z/Architecture, can't be implemented with an external I/O device. A contemporary IBM mainframe has multiple timers on each CPU chip. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:51, 29 May 2020 (UTC)

Funny you should ask! I actually worked on a System/370 clone design as part of a research project decades ago. It's true that System/370 has a built-in "CPU timer", but that doesn't make the timer part of the central processor. The CPU timer is effectively an I/O device which happens to be mapped to fixed addresses and, like all other I/O devices, it issues interrupt service requests to an architecturally distinct processor. In many ways this is similar to microcontroller chips, which have on-chip timers (and other on-chip I/O devices) that are mapped to fixed addresses. Lambtron talk 15:37, 29 May 2020 (UTC)

You may be confusing the CPU timer with the Interval Timer; there is no address associated with either the CPU Timer or the TOD clock. None of those look remotely like an I/O device, unless you want to stretch the term out of all recognition and call, e.g, the I-unit of a 370/165 an I/O device. The IBM mainframe timing facilities are not architecturally distinct, any more than floating point registers are, and for a long time have been on the same chip as other CPU components. In fact, with SMT there are more CPU timers on the chip than there are cores. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:18, 29 May 2020 (UTC)

At first glance it might seem that the CPU timer is not associated with an address because it's programmed via privileged instructions. Internally, however, the timer is mapped to addresses in the processor's register space and its output is hardwired to a processor interrupt request input, effectively making it a tightly-coupled I/O device. It's no stretch at all to reach this conclusion. From the processor's perspective, the timer's service request enters the processor via an interrupt request input node -- a distinct architectural boundary between processor and external circuitry. Perhaps the confusion here is due to differences between IBM device nomenclature and the architectural meaning of "processor"? Lambtron talk 18:24, 29 May 2020 (UTC)

Don't x86 CPUs have an integrated timer since the Pentium age? Additionally, does it really matter from the IRQ perspective whether an interrupt source is internal or external to the CPU? --Zac67 (talk) 17:02, 29 May 2020 (UTC)

IRQ lines are a feature of certain bus architectures and don't exist in IBM mainframes. Interrupt handling on the 360 line is by type rather than by source, e.g., all I/O interrupts have the same old and new PSW locations. Similarly, the IBM mainframes don't use memory mapped I/O.

BTW, on some S/360 models the Interval Timer is virtual; it's decremented by the microcode rather than by dedicated hardware. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:26, 29 May 2020 (UTC)

Yes Zac, it's an important point. All interrupt sources are external to the processor. A processor cannot request interrupt service, nor does it ever have reason to do so. A processor has, at its circuit boundary, input net(s) through which external circuits request service; this is the mechanism through which all interrupts are invoked. Lambtron talk 18:33, 29 May 2020 (UTC)

That's not true even in the Intel world. The obvious counterexample is the INT instruction. Processors have been generating interrupts for more than half a century., over and above timer interrupts. If you have an edition of the 1107 manual without the misprint, please substitute. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:35, 29 May 2020 (UTC)

References

Notes

Condition of references versus timeliness of references

Given a choice of two references to cite, one of which was published at a more appropriate date, but with a printing defect, and the other published five years later but more readable, which should be cited in the article? Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 31 May 2020 (UTC)

References

I think I would cite both, it's only WP:OVERKILL when you have more than 3. --Mathnerd314159 (talk) 17:13, 21 January 2022 (UTC)

IBM 650

The artical claims The IBM 650 (1954) incorporated the first occurrence of interrupt masking. However, the 650 did not have interrupts. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:46, 30 December 2020 (UTC)

The main source AFAICT for this is https://people.cs.clemson.edu/~mark/interrupts.html by Mark Smotherman which says:

The 650 had a console option to automatically branch to a restart sequence upon a machine error. Blaauw and Brooks write:

There is a rudimentary interrupt system for machine errors. When the stop condition of the Machine Error indicator in [sic] not enabled by its mask switch, it causes a trap. The next instruction is now taken from the console switches, word 8000, instead of from the specified location. There is no status preservation whatever; there is no way to know where the offending trap occurred. Moreover, the Distributor and Accumulator are reset; the main purpose is to get a fresh restart after an intermittent error.

Similarly all the statements seem to be based on Smotherman. I have made that sourcing more clear. If you have a reliable source that disagrees with Smotherman then feel free to add it. --Mathnerd314159 (talk) 02:02, 23 December 2021 (UTC)

NPOV - PC centric

Large parts of the article seem to be describing interrupts on a PC rather than interrupts in general. The information on specific interrupt systems should be in separate, appropriately named, sections or subsection from material on interrupts in general.

There are systems in which an interrupt causes processor status and interrupt reason to be pushed on the stack rather than stored at fixed locations. Does that belong in the article, or is it TMI? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:19, 24 December 2021 (UTC)

@Chatul: I would suggest to have an overview because It highly depends on architecture. As long as we have sane sources on that of course. Given different ISAs I think it's best to keep details short. They are CPU-specific and belong to specific articles (e.g. x64, MIPS) etc. Help:LST is also to the rescue to avoid WP:COAT. AXONOV (talk) ⚑ 22:40, 24 December 2021 (UTC)

I've revised some text to make it more general and added a {{POV-section}} to the IRQ section. The article needs some text to describe interrupt handling on I/O channels with multiple devices, but I'm not sure what material should be at what heading level. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:14, 26 December 2021 (UTC)

India Education Program course assignment

This article was the subject of an educational assignment at Department of Electronics and Telecommunication, College of Engineering, Pune, India supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:54, 1 February 2023 (UTC)

Missing interrupts

An interrupt that should occur but doesn't can cause software hangs, and some operating systems have code to deal with the issue. Should there be a section on that topic, or is it TMI? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:20, 3 March 2023 (UTC)

I guess it would be a new section under "Hardware interrupts" similar to "Spurious interrupts"? If you can find some decent sources I would say go for it. Mathnerd314159 (talk) 06:21, 4 March 2023 (UTC)