relationship between IRQ and DMA in x86/x86-64 architecture PC

[m4rtin]

While in general I understand what IRQ(Interrupt requests) and DMA(Direct memory Access) are, then how do they relate to each other in x86/x86-64 architecture PC? Is DMA sort of replacement for IRQ and DMA-capable devices do not need an IRQ address( for example IRQ2, IRQ5, etc)? For example, older network cards needed to send interrupts to CPU for each received frame while modern network cards are able to take advantage of DMA technology and can access memory directly and no IRQ is needed?

[ataradov]

I may be wrong, but interrupts are still there, they are just configured automatically. Interrupts are needed anyway so that CPU knows when to process the data. DMA transfer is started when frame IRQ is received, and then DMA generates another IRQ when its done received the frame. Pretty standard scheme.

[james_s]

I'm not up to date with the physical implementation these days but IRQ and DMA request lines have coexisted since at least as far back as the AT, they are two different things. Each IRQ and DMA is a separate signal, routed to a physical pin on the bus. Originally you had to manually connect the card to a free IRQ and DMA line using jumpers but when PnP came out the cards became auto-configuring. I once was given a faulty modem that would prevent the machine from booting when it was installed. I figured out that the PnP part of the hardware had failed and it was trying to use all of the IRQ lines. I ended up putting strips of tape over all but one IRQ pad on the ISA bus connector and used it for years like that.

[hamster_nz]

My knowledge is very old, from back in the sound blaster days....

DMA is how a peripheral can transfer data into memory without the data passing through the CPU. Software sets up the DMA controller channel, saying transfer this much data to the area of memory, and tell me when you are done.

Once the transfer is completed an IRQ is signalled, to tell the CPU that the data has been transferred, and it can now initiate another transfer if desired.

This all changed around the time of the IBM  PS/2 microchannel architecture, where I/O cards were able to act as bus masters, so were able to take ownership of the bus and read or write to RAM without needing to use a DMA channel, but the old DMA controller stuck around for ages. The old way was horrid, and could only address the lowest MB of physical memory, so any OS with virtual memory had to use 'bounce buffers' to move data to where the DMA engine could get to it.

How it now works in modern x86 is now way beyond me, but I assume that the can transfer to/from RAM as they require, and IRQs are more implemented in the PCI express serial data protocol  than an being an actual physical wire....

On top of that IRQs are now handled by complicated things like IOAPiCs and have magic features like MSI-X that I am completely  ignorant of to deliver the right  IRQ signal to the right CPU core.

[james_s]

IRQ lines were around in the very earliest PC, they were used for anything that needed to interrupt the processor regardless of whether DMA was used. By around the late 90s IRQ sharing was starting to appear, I've never actually looked into how that was done, but prior to that everything that wanted to trigger an interrupt request had to have its own dedicated IRQ line. A few of the IRQs were used by low level peripherals like the keyboard port and timer that were integral to the architecture so those were not even brought out onto the bus. IIRC the PC and XT had 8 total IRQ lines while the AT and later doubled that to 16 along with the AT bus which had an additional set of contacts.

[Howardlong]

Like others my knowledge is old and sketchy, but as I remember it in the original ISA bus IRQs were edge sensitive rather than level sensitive, which meant that sharing IRQs was often disastrous. The most common scenario I encountered was with COM1/COM3 sharing the same standard IRQ, as did COM2/COM4. Sure, you could use non-standard IRQs but there weren't many to choose from. Essentially it meant that you couldn't reliably operate many standard serial ports simultaneously.

IRQs and address spaces were selected with DIP switches and/or handbag jumpers. I never understood what the fuss was about these, what you set was what you got, but that didn't stop the introduction of ISA Plug and Play, which at the time was frequently called "Plug and Pray" as its automated allocation was often far from favourable, and overriding it wasn't always possible.

More modern busses like the PCI bus use level sensitive IRQs allowing interrupt sharing, as well as offering a more robust plug and play than ISA PnP.

[timb]

Like others my knowledge is old and sketchy, but as I remember it in the original ISA bus IRQs were edge sensitive rather than level sensitive, which meant that sharing IRQs was often disastrous. The most common scenario I encountered was with COM1/COM3 sharing the same standard IRQ, as did COM2/COM4. Sure, you could use non-standard IRQs but there weren't many to choose from. Essentially it meant that you couldn't reliably operate many standard serial ports simultaneously.

IRQs and address spaces were selected with DIP switches and/or handbag jumpers. I never understood what the fuss was about these, what you set was what you got, but that didn't stop the introduction of ISA Plug and Play, which at the time was frequently called "Plug and Pray" as its automated allocation was often far from favourable, and overriding it wasn't always possible.

More modern busses like the PCI bus use level sensitive IRQs allowing interrupt sharing, as well as offering a more robust plug and play than ISA PnP.

ISA PnP wasn't a bad idea, per say, it's just the implementation was often lacking. You see, initially it didn't *require* a special "ISA PnP Motherboard" or anything to work; it was essentially a software implementation first! Basically, before BIOS integrated PnP, it went like this:

You bought your ISA PnP card and installed it into your generic AT clone. There were no jumpers on the board to set IRQs and DMA, so you loaded up some software that came on a disk with the card. This software then scanned your system, checking each ISA address, IRQ line, DMA channel, etc. (not unlike a diagnostic/system profiler application like MSD.exe).

Once it had an overview of the hardware in your system, it picked a free IRQ, DMA channel and appropriate address. The software then installed a device driver that would send this configuration to the card on boot (sometimes this information would actually be stored in NVRAM/Flash/EEPROM on the card itself, negating the need for a device driver) and told you to reboot.

The problem with this method is it relies on whomever wrote the software to do hardware detection. Quality varied widely from one manufacturer to the next. (NI had really good PnP software; 3Com, not so much.)

Eventually this problem was rectified when the PnP initialization was handled by the BIOS instead of individual hardware manufacturers. Unfortunately, it was too late to be particularly useful for ISA, as PCI was out and quickly gaining traction.

[Howardlong]

Your memory is better than mine, I'd forgotten about he floppy thing! Come to think of it, the same applied the MCA too: without the floppy the hardware was useless, and there was no internet to help you out in those days. I remember having dustbins full of floppies during big deployment rollouts.

[james_s]

MCA was technologically very interesting and I still have a soft spot for the higher end PS/2 systems but IBM's attempt to keep it closed and proprietary doomed it to commercial failure.

[Howardlong]

MCA was technologically very interesting and I still have a soft spot for the higher end PS/2 systems but IBM's attempt to keep it closed and proprietary doomed it to commercial failure.

I worked for Olivetti Systems & Networks around 1991, and worked on the config management and bulk deployment strategies at a technical implementation level for high volume national rollouts for big customers, mostly banks (think in terms of ~5ku deployments). As well as IBM PS/2s, we deployed Olivetti and NCR machines, and all were MCA, so you could license the technology. The way I read it was that IBM thought they'd save their market share by single handedly coming up with a new architecture that required licensing, thinking they'd learned from their perceived mistake of the relatively open ISA bus.

[james_s]

Yeah MCA could be licensed, but you couldn't just freely use it as with ISA, and IIRC the licensing fees were somewhat obscene. It's no wonder the competition developed alternate architectures. ISA remained viable for quite a long time for low bandwidth stuff and with the advent of VLB it kept going until PCI finally took over. Even so the PC before my current box had one or two 16 bit ISA slots in it alongside PCI and AGP.