Date: Thu, 30 Jan 1997 17:36:38 -0500 (EST) From: Kenneth Merry <ken@housing1.stucen.gatech.edu> To: smp@csn.net (Steve Passe) Cc: bag@sinbin.demos.su, mishania@demos.su, freebsd-smp@freebsd.org Subject: Re: troubles with smp kernel Message-ID: <199701302236.RAA25173@housing1.stucen.gatech.edu> In-Reply-To: <199701301934.MAA18162@clem.systemsix.com> from Steve Passe at "Jan 30, 97 12:34:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe wrote...
[ ... ]
> note that the following lines are grabbed from several of the previous
> mailings, resorted to explain the issue:
>
> >Bus: Bus ID Type
> > 0 PCI
> > 1 PCI
> > 2 PCI
> > 3 ISA
>
> this shows the PCI bus on the motherboard (Bus 0) and the PCI busses
> created by the PCI bridge chips on each of the 3940s (Bus 1 & Bus 2)
> This is correctly done, by the way, and many SMP motherboards blow
> it entirely.
> >I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT#
> > INT active-lo level 1 4:A 2 19
> > INT active-lo level 1 5:A 2 16
> > INT active-lo level 0 10:A 2 18
> > INT active-lo level 2 4:A 2 16
> > INT active-lo level 2 5:A 2 17
>
> >ahc0 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 19 on pci1:4
> >ahc1 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 16 on pci1:5
> >ahc2 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 19 on pci2:4
> >ahc3 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 16 on pci2:5
> ^^
> ||
> here is your major problem, ahc2 and ahc3 are getting the wrong INTs
> assigned to them. ahc2 should get IRQ16, and ahc3 should get IRQ17
Are you sure that they're getting the wrong INTs? In an earlier
mail, Mikhail Sokolov said that:
====
What we have is attached at the end of the letter of mine; to be short it's
the above mentioned mother, 2x3940TUW (Twin Ultra Wide) Adaptecs in slots
4 and 5, sharing irq's. The FM of the motherboard claims, that it might not
be any problem at all to have it shared, _when an OS supports sharing
correct_. Seems it doesn't :-(.
====
Slots 4 and 5 on this particular board share the same interrupt.
My machine, for instance, has a 3940UW in slot 4, and a Matrox Millineum in
slot 5, and three DE21040-based cards in slots 1-3. So the interrupts get
assigned like this:
slot 1: de2 <Digital 21140 Fast Ethernet> rev 18 int a irq 16 on pci0:12
slot 2: de1 <Digital 21140A Fast Ethernet> rev 32 int a irq 17 on pci0:11
slot 3: de0 <Digital 21140 Fast Ethernet> rev 17 int a irq 18 on pci0:10
slot 4: ahc0 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 19 on pci1:4
ahc1 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 16 on pci1:5
slot 5: vga0 <VGA-compatible display device> rev 1 int a irq 19 on pci0:13
Seems like it's behaving the same way, although that might not be a
'good' way..:) But my system does work when the 3940, Matrox and SMC cards
share interrupts.
> A little history to explain why the current code is failing:
>
> The original MP spec 1.1 didn't take PCI bridge cards into account
> and thus couldn't handle them. Intel then added appendix D.2/3 to the
> spec which attempted to clear this up, but many MBs didn't get
> it right. Beyond that it was unclear to me from the spec exactly
> how the code should deal with it till I had a chance to work it thru
> with several people who actual had this type of hardware.
> As a result the current code ignores the Bus ID when assigning these
> INTs.
>
> The simple solution here would be to run without the 2nd 3940. The first one
> is being properly assigned. However, since your MB (ASUS) does the mp table
> correctly I suggest the better alternative:
If for some reason the 3940's aren't working properly sharing
interrupts with each other, maybe one of them could share an interrupt with
the network card? To do that, you could do something like put the network
card in either slot 1 or slot 5, a 3940 in slot 2, and a 3940 in slot 4.
If the network card is in slot 1, it'll share an interrupt with the second
channel of the 3940 in slot 4. If the network card is in slot 5, it will
share an interrupt with the first channel of the 3940 in slot 4. The 3940
in slot 2 will have two interrupts to itself, one for each channel.
> You could attempt to fix the code in sys/i386/i386/mp_machdep.c. The following
> patch hopefully will work, but I don't have an SMP machine right now so I
> could not test it... let me know if it works.
[ ... ]
> I expect the above to make things much better, assumming you were using devices
> on the 2nd 3940. Note that the above patch will actually cause many
> motherboards to STOP working because they don't do the mp table stuff
> correctly! This is why I haven't submitted such a change to the code. The
> real fix is going to involve analyzing the mp table, then making a CORRECTED
> in-core copy when the kernel boots. It ain't gonna be pretty, and it ain't
> gonna be easy to get right, so I have been avoiding it!!!
Ahh, okay, so is the idea to basically reassign the interrupts that
the BIOS assigns, so that there are unique interrupts for each device in
the system? Would it be a good idea for me to try out the patch?
Ken (who may catch on eventually :) )
--
Kenneth Merry
ken@ulc199.residence.gatech.edu
Disclaimer: I don't speak for GTRI, GT, or Elvis.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701302236.RAA25173>