[SOLVED] Question about /proc/interrupts virtual file

gacanepa · 05-31-2013, 01:55 PM

Hi everyone,
I have the following 2 questions about the /proc/interrupts virtual file (refer to the contents of the file in my Debian Wheezy box below):
1) If more than one device is using the same IRQ, i.e. IRQ #5, is it correct to assume that one of those devices (or all of them altogether) can experience issues? If so, how can I assign a different IRQ to each device in order to avoid those issues?
2) Is the order of IRQs relevant, meaning that they will get system resources (allocated memory, CPU time) in the order they are listed? Kind of in this example, as far as system resources are concerned, will the floppy drive have priority over usb1 and usb2?
Thanks in advance!

Code:

gacanepa@debian:/proc$ cat interrupts
           CPU0
  0:     396659    XT-PIC-XT-PIC    timer
  1:          8    XT-PIC-XT-PIC    i8042
  2:          0    XT-PIC-XT-PIC    cascade
  3:          0    XT-PIC-XT-PIC    uhci_hcd:usb3
  5:       1785    XT-PIC-XT-PIC    uhci_hcd:usb4, eth0
  6:          2    XT-PIC-XT-PIC    floppy
  7:          0    XT-PIC-XT-PIC    parport0
  8:          0    XT-PIC-XT-PIC    rtc0
  9:          0    XT-PIC-XT-PIC    acpi
 10:          0    XT-PIC-XT-PIC    MPU401 UART
 11:         48    XT-PIC-XT-PIC    uhci_hcd:usb1, ehci_hcd:usb2
 12:          4    XT-PIC-XT-PIC    i8042
 14:      28368    XT-PIC-XT-PIC    ata_piix
 15:        159    XT-PIC-XT-PIC    ata_piix
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
IWI:          0   IRQ work interrupts
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:         30   Machine check polls
ERR:          0
MIS:          0

business_kid · 06-01-2013, 01:44 PM

No, and No.

To elaborate: Up to the early 2000s, 2 devices on the same interrupt meant a hardware lockup as soon as they were both accessed. Turn off the power and try again.

This became unworkable. The fix was a hardware fix. The original IBM XT (which everything is/was theoretically compatible with) used an 8259 chip for interrupts - 8 inputs --> 1 output, for processing these; a second 8259 was added in the AT, giving 16 interrupts. Now it's all in asics, So you can add mad numbers of hardware interrupts. They also started polling the devices assigned to each interrupt ("Did you call me?"). So interrupts can be shared, and they started giving interrupts to internal stuff in the kernel to make life easier.

You can often change some interrupts (pci cards) in the bios. Other IRQs are traditionally assigned to certain devices, and it's better not to mess with that, in case the software relies on that. None should, but . . .
Devices also have a few choices of interrupt saved on sram, so it will be assigned one it wants to use. My advice is not to mess.

The devices are not necessarily listed in order of priority, but in some order convenient to the hardware. You can grok source code if you really want to know. Priority settings of the programs accessing them would probably matter more (Man nice if you're interested).

gacanepa · 06-01-2013, 06:54 PM

Quote:

Originally Posted by business_kid

No, and No.

To elaborate: Up to the early 2000s, 2 devices on the same interrupt meant a hardware lockup as soon as they were both accessed. Turn off the power and try again.

This became unworkable. The fix was a hardware fix. The original IBM XT (which everything is/was theoretically compatible with) used an 8259 chip for interrupts - 8 inputs --> 1 output, for processing these; a second 8259 was added in the AT, giving 16 interrupts. Now it's all in asics, So you can add mad numbers of hardware interrupts. They also started polling the devices assigned to each interrupt ("Did you call me?"). So interrupts can be shared, and they started giving interrupts to internal stuff in the kernel to make life easier.

You can often change some interrupts (pci cards) in the bios. Other IRQs are traditionally assigned to certain devices, and it's better not to mess with that, in case the software relies on that. None should, but . . .
Devices also have a few choices of interrupt saved on sram, so it will be assigned one it wants to use. My advice is not to mess.

The devices are not necessarily listed in order of priority, but in some order convenient to the hardware. You can grok source code if you really want to know. Priority settings of the programs accessing them would probably matter more (Man nice if you're interested).

Thanks a lot for taking the time to read my question and to answer it so thoroughly. I will add to your reputation and mark this as solved.