Documentation/IO-APIC.txt

   1 Most (all) Intel SMP boards have the so-called 'IO-APIC', which is
   2 an enhanced interrupt controller, able to route hardware interrupts
   3 to multiple CPUs, or to CPU groups.
   4
   5 Linux supports the IO-APIC, but unfortunately there are broken boards
   6 out there which make it unsafe to enable the IO-APIC unconditionally.
   7 The Linux policy thus is to enable the IO-APIC only if it's 100% safe, ie.:
   8
   9            - the board is on the 'whitelist'
  10
  11         or - the board does not have PCI pins connected to the IO-APIC
  12
  13         or - the user has overridden blacklisted settings with the
  14              pirq= boot option line.
  15
  16 Kernel messages tell you whether the board is 'safe'. If your box
  17 boots with enabled IO-APIC IRQs, then you have nothing else to do. Your
  18 /proc/interrupts will look like this one:
  19
  20    ---------------------------->
  21    hell:~> cat /proc/interrupts
  22               CPU0       CPU1
  23      0:      90782          0   XT PIC   timer
  24      1:       4135       2375  IO-APIC   keyboard
  25      2:          0          0   XT PIC   cascade
  26      3:        851        807  IO-APIC   serial
  27      9:          6         22  IO-APIC   ncr53c8xx
  28     11:        307        154  IO-APIC   NE2000
  29     13:          4          0   XT PIC   fpu
  30     14:      56000      30610  IO-APIC   ide0
  31    NMI:          0
  32    IPI:          0
  33    <----------------------------
  34
  35 some interrupts will still be 'XT PIC', but this is not a problem, none
  36 of those IRQ sources is 'heavy'.
  37
  38 If one of your boot messages says 'unlisted/blacklisted board, DISABLING
  39 IO-APIC IRQs', then you should do this to get multi-CPU IO-APIC IRQs
  40 running:
  41
  42         A) if your board is unlisted, then mail to linux-smp to get
  43            it into either the white or the blacklist
  44         B) if your board is blacklisted, then figure out the appropriate
  45            pirq= option to get your system to boot
  46
  47
  48 pirq= lines look like the following in /etc/lilo.conf:
  49
  50         append="pirq=15,11,10"
  51
  52 the actual numbers depend on your system, on your PCI cards and on their
  53 PCI slot position. Usually PCI slots are 'daisy chained' before they are
  54 connected to the PCI chipset IRQ routing facility (the incoming PIRQ1-4
  55 lines):
  56
  57                ,-.        ,-.        ,-.        ,-.        ,-.
  58      PIRQ4 ----| |-.    ,-| |-.    ,-| |-.    ,-| |--------| |
  59                |S|  \  /  |S|  \  /  |S|  \  /  |S|        |S|
  60      PIRQ3 ----|l|-. `/---|l|-. `/---|l|-. `/---|l|--------|l|
  61                |o|  \/    |o|  \/    |o|  \/    |o|        |o|
  62      PIRQ2 ----|t|-./`----|t|-./`----|t|-./`----|t|--------|t|
  63                |1| /\     |2| /\     |3| /\     |4|        |5|
  64      PIRQ1 ----| |-  `----| |-  `----| |-  `----| |--------| |
  65                `-'        `-'        `-'        `-'        `-'
  66
  67 every PCI card emits a PCI IRQ, which can be INTA,INTB,INTC,INTD:
  68
  69                                ,-.
  70                          INTD--| |
  71                                |S|
  72                          INTC--|l|
  73                                |o|
  74                          INTB--|t|
  75                                |x|
  76                          INTA--| |
  77                                `-'
  78
  79 These INTA-D PCI IRQs are always 'local to the card', their real meaning
  80 depends on which slot they are in. If you look at the daisy chaining diagram,
  81 a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
  82 the PCI chipset. Most cards issue INTA, this creates optimal distribution
  83 between the PIRQ lines. (distributing IRQ sources properly is not a
  84 necessity, PCI IRQs can be shared at will, but it's a good for performance
  85 to have non shared interrupts). Slot5 should be used for videocards, they
  86 do not use interrupts normally, thus they are not daisy chained either.
  87
  88 so if you have your SCSI card (IRQ11) in Slot1, Tulip card (IRQ9) in
  89 Slot2, then you'll have to specify this pirq= line:
  90
  91         append="pirq=11,9"
  92
  93 the following script tries to figure out such a default pirq= line from
  94 your PCI configuration:
  95
  96         echo -n pirq=; echo `scanpci | grep T_L | cut -c56-` | sed 's/ /,/g'
  97
  98 note that this script wont work if you have skipped a few slots or if your
  99 board does not do default daisy-chaining. (or the IO-APIC has the PIRQ pins
 100 connected in some strange way). E.g. if in the above case you have your SCSI
 101 card (IRQ11) in Slot3, and have Slot1 empty:
 102
 103         append="pirq=0,9,11"
 104
 105 [value '0' is a generic 'placeholder', reserved for empty (or non-IRQ emitting)
 106 slots.]
 107
 108 generally, it's always possible to find out the correct pirq= settings, just
 109 permute all IRQ numbers properly ... it will take some time though. An
 110 'incorrect' pirq line will cause the booting process to hang, or a device
 111 won't function properly (if it's inserted as eg. a module).
 112
 113 If you have 2 PCI buses, then you can use up to 8 pirq values. Although such
 114 boards tend to have a good configuration and will be included in the
 115 whitelist.
 116
 117 Be prepared that it might happen that you need some strange pirq line:
 118
 119         append="pirq=0,0,0,0,0,0,9,11"
 120
 121 use smart try-and-err techniques to find out the correct pirq line ...
 122
 123
 124 the following pirq line can be used to force a board into the whitelist:
 125
 126         append="pirq=0"
 127
 128 [if your system works with no problems after this, then it should be added
 129 to the official whitelist, contact us]
 130
 131 good luck and mail to linux-smp@vger.rutgers.edu or
 132 linux-kernel@vger.rutgers.edu if you have any problems that are not covered
 133 by this document.
 134
 135 -- mingo
 136