Hi all,

I have a nice little Giga-Byte GA6BXDS with a couple
PII/350s. Everything seems to run very well, but I'm a little
perplexed by my /proc/interrupts output:
 
           CPU0       CPU1       
  0:      27762      24501    IO-APIC-edge  timer
  1:        564        520    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  4:       1641       1456    IO-APIC-edge  serial
  8:          2          0    IO-APIC-edge  rtc
 12:       2880       2685    IO-APIC-edge  PS/2 Mouse
 13:          1          0          XT-PIC  fpu
 14:       4574       4085    IO-APIC-edge  ide0
 16:        674        665   IO-APIC-level  aic7xxx, aic7xxx, Intel EtherExpress Pro 
10/100 Ethernet
 17:          0          0   IO-APIC-level  Ensoniq AudioPCI
NMI:          0
IPI:          0


What bugs me is interrupt 16. I've got a lot of my machine on a UDMA
ide drive (vs my ancient, slow 8-bit SCSI drive), and my LAN gets not
too much traffic, so I guess the load isn't really that bad... but
wait, there's more:

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 [Millennium G200 
AGP] (rev 01)
        Subsystem: Unknown device 102b:ff03
        Flags: bus master, VGA palette snoop, medium devsel, latency 64, IRQ 16
        Memory at e8000000 (32-bit, prefetchable)
        Memory at e4000000 (32-bit, non-prefetchable)
        Memory at e5000000 (32-bit, non-prefetchable)

my graphics card is also on IRQ 16! (err, I notice that it is on a
different - presumably AGP - bus, so this probably doesn't count)

Why is linux deciding that two AIC7895 UW SCSI controllers, a 100Mb
ethernet card, and my video card should all get interrupt 16, when
under normal usage these are some of the more high-bandwith devices
one can have?

Anyone know anything about interrupt allocation? Is this even a
concern?

Thanks from an ignoramus...
--
Brendan Cully
[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]

Reply via email to