> >>>>> On Thu, 15 Aug 1996 17:18:48 -0400,
> 	Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu> said:
> 
> >> How about this (on i386) ?
> >> 
> >> mainbus0 irq 0
> >> mainbus0 irq 1
> >> :
> 
> > That could make sense.  However, i'd go with 'isa' because the PICs
> > are an ISA thing, because PCI interrupts really are routed through
> > them, and because you always have an ISA bus.
> 
> Please explain it a bit more.
>
> For example, Is the output format which you think below (on i386) ?
> 	% vmstat -i
> 	interrupt		total		rate
> 	isa0 irq 0		10000		100
> 		:
> 	isa0 irq 11		100		3
> 		de0		100		3
> 		stray		0		0
> in the condition given below
> 	pci0 at mainbus0
> 	ppb0 at pci0 ...
> 	pci1 at ppb0 ...
> 	de0 at pci1 ...
> 	de0: interrupting at irq 11

sure.  On PCI, all PCI interrupts are routed through the PICs...

> If so, I like mainbus0 rather than isa0, because printing isa0 may
> confuse users, and because ICU is not located on ISA bus, but on
> CPU motherboard.

Sure, that may be reasonable...  However, if that's reasonable, why
isn't the ICU-handling code in arch/i386/i386?  8-)

In NetBSD/i386, ICU handling seems to be wedded (at least by location)
to the ISA code.  If that's the case, it's not particularly
unreasonable to have the interrupt counts say something like that.

On the other hand, if initialization, etc., of the PICs is done before
ISA/EISA/PCI bus code is run, then it could very well make sense to
change it to 'mainbus irq'...


I like to have the kernel print the information more like:

de0 at pci0 dev 11 function 0: DC21040 [10Mb/s] pass 2.3
[ de0: ... ]
de0: interrupting at isa irq 5
		     ^^^

i.e. having the PCI chipset explicitly mention some more information
about the routing.  (That's what I do on the Alpha.  I could even
go so far as to have it explicitly print out the device name of
the ISA bus in question, but there's no real reason to do that, and
doing so with the interrupt counting scheme i'm currently using would
be hard.  Unfortunately, i don't have any machines with a PPB, with
'useful' devices behind the PPB, at the moment.)

On machines where there are seperate PCI and ISA/EISA interrupt lines,
like the AlphaStation 600, i print something like "... at kn20aa irq 16"
for the PCI device interrupts.  (kn20aa is the CPU type of the CPU in
question, and it routes PCI interrupts through a completely different
mechanism than ISA/EISA interrupts.)

'vmstat -i' says things like:

55 [bunnahabhain] GENERIC % vmstat -i
interrupt         total     rate
clock          2554069992     1024
isa irq 3             2        0
isa irq 4          4331        0
isa irq 11       598465        0
isa irq 14     47299304       18
Total          2601972094     1043

(remember, i use static interrupt-name tables, for now, so there are
no device names whatsoever...  Also note that the clock interrupt
is given its own CPU interrupt line, and is not routed through an ISA
IRQ.)

On AlphaStation 600s, it's typically something like:

clock ...
kn20aa irq 8 ...
kn20aa irq 16 ...
isa irq 3 ...
isa irq 4 ...

etc.  The information that I print in the boot messages indicates
(unambiguously, at least for the current set of machines that I
support) where the device is really interrupting.


cgd