From owner-freebsd-smp Thu Jan 30 15:14:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08934 for smp-outgoing; Thu, 30 Jan 1997 15:14:30 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA08925 for ; Thu, 30 Jan 1997 15:14:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA19294; Thu, 30 Jan 1997 16:13:08 -0700 Message-Id: <199701302313.QAA19294@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Kenneth Merry cc: bag@sinbin.demos.su, mishania@demos.su, freebsd-smp@freebsd.org Subject: Re: troubles with smp kernel In-reply-to: Your message of "Thu, 30 Jan 1997 17:36:38 EST." <199701302236.RAA25173@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 16:13:07 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, these are the entries from the mp table for the PCI devices (ed0, ahcX): >>>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 this was what actually happened, ie the output of dmesg: >>>ahc0 rev 0 int a irq 19 on pci1:4 >>>ahc1 rev 0 int a irq 16 on pci1:5 >>>ahc2 rev 0 int a irq 19 on pci2:4 >>>ahc3 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: > ... > 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. yes, I'm certain, look at the above lines again. since there are 2 3940s involved we have a replication of device:int with each of them: ahc0: device 4, INT a <--> ahc2: device 4, INT a ahc1: device 5, INT a <--> ahc3: device 5, INT a since the current code walks thru the table looking for a match to device:INT, BUT ignores bus ID, ahc0 AND ahc2 both resolve to the 1:4:A entry, ie IRQ19, and ahc1 AND ahc3 both resolve to the 1:5:A entry, ie IRQ16. ahc2 SHOULD resolve to the 2:4:A entry, ie IRQ16 (shared because they are in adjoining slots) and ahc3 SHOULD resolve to 2:5:A, IRQ17 --- > [ ... ] > 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? no, thats not what I'm saying, hopefully the above explanation clears this up. my scenario doesn't re-assign the INTS, its just that the current code fails to properly read the ASUS table, and my suggested patch should fix this, ie properly read the table. The confusion comes from the fact that many MBs build the table INCORRECTLY and thus doing "the correct thing" would break them. I hope I'm clearly describing this, I know how difficult it can be to grasp, I've only gained the knowledge by working with the code till I get it right! As to your trying the patch, I can't remember if yours is the system that has the good mp table (ie another ASUS), or whether you have the one for which I had to hard-code the true values inside the source of the kernel (ie a misbehaving MP BIOS). If you have the ASUS then the patch won't hurt (assumming its correct) but it also won't change anything unless you add a PCI card that uses the same device:INT as another PCI card in the system. If you have the system with my hard-coded patches for the 3940 INT sources, then it would probably break the kernel! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----