Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.hardware > #1292 > unrolled thread

Assigned interrupts ... what's correct ?

Started byArmin <a-steinhoff@web.de>
First post2012-06-30 12:42 +0200
Last post2012-06-30 13:37 +0200
Articles 3 — 2 participants

Back to article view | Back to comp.os.linux.hardware


Contents

  Assigned interrupts ... what's correct ? Armin <a-steinhoff@web.de> - 2012-06-30 12:42 +0200
    Re: Assigned interrupts ... what's correct ? Armin <a-steinhoff@web.de> - 2012-06-30 13:12 +0200
    Re: Assigned interrupts ... what's correct ? Clemens Ladisch <clemens@ladisch.de> - 2012-06-30 13:37 +0200

#1292 — Assigned interrupts ... what's correct ?

FromArmin <a-steinhoff@web.de>
Date2012-06-30 12:42 +0200
SubjectAssigned interrupts ... what's correct ?
Message-ID<jsml0s$nne$1@online.de>
Hi,

I have tried to find out what IRQ has been assigned to the devices of my 
SuSE/Intel machine ... and I got different infos.

I'm really confused and here is what I did:

lspci -vvv

02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet 
(rev a0)
         Subsystem: ASUSTeK Computer Inc. Device 8233
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 0, Cache Line Size: 16 bytes
         Interrupt: pin A routed to IRQ 43  <=======

--------------------------------------------------------

lspci -vvv -H1

02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet 
(rev a0)
         Subsystem: ASUSTeK Computer Inc. Device 8233
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 0, Cache Line Size: 16 bytes
         Interrupt: pin A routed to IRQ 10 <=======

---------------------------------------------------------

dmesg | grep IRQ

[    0.804642] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) 
-> IRQ 17
[    0.804910] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) 
-> IRQ 18
[    0.805193] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 19 (level, low) 
-> IRQ 19
[    1.961335] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    9.355871] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 19 (level, 
low) -> IRQ 19
[    9.635378] atl2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> 
IRQ 17  <========


Any comments ?

--Armin

[toc] | [next] | [standalone]


#1293

FromArmin <a-steinhoff@web.de>
Date2012-06-30 13:12 +0200
Message-ID<jsmmou$j47$1@online.de>
In reply to#1292
Armin wrote:
> Hi,
>
> I have tried to find out what IRQ has been assigned to the devices of my
> SuSE/Intel machine ... and I got different infos.
>
> I'm really confused and here is what I did:
>
> lspci -vvv
>
> 02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet
> (rev a0)
> Subsystem: ASUSTeK Computer Inc. Device 8233
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 16 bytes
> Interrupt: pin A routed to IRQ 43 <=======
>
> --------------------------------------------------------
>


  cat /proc/interrupts shows:

            CPU0       CPU1
   0:        180          0   IO-APIC-edge      timer
   1:       2510          0   IO-APIC-edge      i8042
   7:          0          0   IO-APIC-edge      parport0
   8:          1          0   IO-APIC-edge      rtc0
   9:          0          0   IO-APIC-fasteoi   acpi
  12:     618156          0   IO-APIC-edge      i8042
  14:      17818          0   IO-APIC-edge      ata_piix
  15:          0          0   IO-APIC-edge      ata_piix
  16:     134588          0   IO-APIC-fasteoi   i915
  17:         20          0   IO-APIC-fasteoi   uhci_hcd:usb3
  18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
  19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb5
  20:        106          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
  23:     162408          0   IO-APIC-fasteoi   ata_piix
  42:     849553          0   PCI-MSI-edge      snd_hda_intel
  43:      81457          0   PCI-MSI-edge      eth0 <======

So IRQ 43 is real assigned IRQ ??

--Armin


> lspci -vvv -H1
>
> 02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet
> (rev a0)
> Subsystem: ASUSTeK Computer Inc. Device 8233
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 16 bytes
> Interrupt: pin A routed to IRQ 10 <=======
>
> ---------------------------------------------------------
>
> dmesg | grep IRQ
>
> [ 0.804642] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) ->
> IRQ 17
> [ 0.804910] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) ->
> IRQ 18
> [ 0.805193] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 19 (level, low) ->
> IRQ 19
> [ 1.961335] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 9.355871] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 19 (level, low)
> -> IRQ 19
> [ 9.635378] atl2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ
> 17 <========
>
>
> Any comments ?
>
> --Armin

[toc] | [prev] | [next] | [standalone]


#1294

FromClemens Ladisch <clemens@ladisch.de>
Date2012-06-30 13:37 +0200
Message-ID<a586o3FiffU1@mid.individual.net>
In reply to#1292
Armin wrote:
> I have tried to find out what IRQ has been assigned to the devices of
> my SuSE/Intel machine ... and I got different infos.

There are multiple ways of routing and handling interrupts, with various
degrees of backwards compatibility.

In the good^Wbad ol' times of the ISA bus, the interrupt controller (the
PIC) was able to handle 16 interrupts, numbered 0 to 15.  Modern
interrupt controllers are still compatible with that, and the BIOS must
initialize interrupts to use that because it doesn't know if the OS is
able to use anything else.

All PCI devices have an interrupt number register, which does not affect
the device itself but is just used by the BIOS or the OS to tell the
driver to which interrupt the chip's interrupt pin is routed.  This
register is what is shown by lspci -H1:

> lspci -vvv -H1
> 02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet (rev a0)
>         Interrupt: pin A routed to IRQ 10 <=======

This is the ISA interrupt that was set by the BIOS.

Most ISA interrupts are reserved for certain ISA devices, so you often
end up with all PCI devices sharing only one or two interrupts.
Therefore, a better interrupt controller was introduced, the IOAPIC.
Typically, it has eight additional interrupts lines (16-23) for PCI
devices.

When a driver attaches to a PCI device, the kernel automatically
configures the interrupt to be routed through the IOAPIC, if possible.
This is what you see in the kernel log:

> dmesg | grep IRQ
> atl2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17  <========

There is still the problem that with eight interrupt lines, modern PCs
still have many shared PCI interrupts.  So PCI Express has a new
interrupt delivery mechanism (MSI) that does not require interrupt lines
at all and allows arbitrarily many interrupts.

MSIs behave not exactly the same as old-style PCI interrupts, so the
kernel cannot enable them automatically but does so only when a driver
requests it.  You can see this happen with "dmesg | grep -i IRQ", or
by using lspci without -H which shows the kernel-internal data structure:

> lspci -vvv
> 02:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet (rev a0)
>         Interrupt: pin A routed to IRQ 43  <=======

This is also shown in /proc/interrupts.


To answer your question "what's correct?" -- all of them are, at
different times.  :-)


Regards,
Clemens

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.linux.hardware


csiph-web