Date: Sun, 06 Apr 1997 13:08:44 -0600 From: Steve Passe <smp@csn.net> To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Cc: nishio@caleche.kecl.ntt.co.jp, freebsd-smp@freebsd.org Subject: Re: APIC_IO problem on Tyan S1668 Message-ID: <199704061908.NAA25133@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Sun, 06 Apr 1997 12:14:21 MDT." <199704061814.MAA09025@fast.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> Unless I'm missing something, there shouldn't be any device-specific
> code in the ``band-aid''. Isn't all that needs to be done is
> to add an extra line in the MP config table for the other PCI
> slot? This should be (I think) just one of these two situations:
your partly right, I didn't shift gears from the model I previously encountered
this kind of problem with, ie the PCI-PCI bridged card. in that case the
numbers could move on you, depending on which slot the bridge card was
in. here the numbers will be static and thus its easier to deal with.
---
> (for this case; i'm using real numbers)
> 1. Slot 10 actually maps to irq 20 and is just skipped...
> (following trend from 16,17,18,19,...)
> 2. Slot 10 actually maps to irq 16 and shares with pci0:14
> (It is possible that is shares with a different slot, but I don't think so.)
>
> My gut tells me that it is #2, as that is how the ISA irqs are mapped.
The ISA irqs are shared
between slots 1 & 5 because there are only 4 IRQ redirection registers
in the MB chipset and they have no other choice. However there are 3-4
extra pins available on the IO_APIC, it would be nice if they used them!
It's been awhile since I looked at the details of this, there may be some other
MB/chipset consideration that forces them to also share the PCI slots above
#4, the gigabyte board also does this:
INT active-lo level 0 8:A 2 16
INT active-lo level 0 9:A 2 17
INT active-lo level 0 10:A 2 18
INT active-lo level 0 11:A 2 19
INT active-lo level 0 7:A 2 19
INT active-lo level 0 12:A 2 16
but at least they tell us about it!
---
> So then you have two ways of checking this:
> 1. If the device number isn't in the table, clone one from +/-4
> on the same bus; print warning. (The thought here is that the
> slots are numbered sequentially, with a logical layout).
> 2. Find a device with the same ISA irq mappings, and use its APIC
> irq; if multiple matches found, punt; print warning message.
the current mptable is in kernel core, and pre-built during the boot stage.
changing it on the fly would take a little work. the catch is in how
the request is made:
the pci code asks to register an INT for device pci0:10. my routine looks
it up in the incore (equivilant to) mptable, fails to find it. it doesn't have
any info about the ISA IRQ at this point so it can't use that to reverse
engineer the APIC INT. it could scan the other entries, see the range of 14-11
for devices and try 10 (your suggestion #1). this would not be guaranteed.
long term this requires a "ROGUE" entry for this MB which the boot code
would use to build a "correct" incore mptable. short term I would add a
bandaid to my routine in i386/i386/mp_machdep.c:
#define TYAN_S1668_ROGUE
#if defined( TYAN_S1668_ROGUE )
/** NOTE: this might be some other #, we are guessing... */
#define TYAN_S1668_SLOT5_IRQ 16
get_pci_apic_irq( int pciBus, int pciDevice, int pciInt )
{
if ( (pciBus == 0) && (pciDevice == 10) )
return TYAN_S1668_SLOT5_IRQ;
#else
get_pci_apic_irq( int pciBus __attribute__ ((unused)),
int pciDevice, int pciInt )
{
#endif
...
}
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704061908.NAA25133>