From owner-freebsd-smp Sun Jan 12 12:41:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA20007 for smp-outgoing; Sun, 12 Jan 1997 12:41:24 -0800 (PST) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA19997 for ; Sun, 12 Jan 1997 12:41:21 -0800 (PST) Received: from gilligan.eng.umd.edu (gilligan.eng.umd.edu [129.2.103.21]) by po1.glue.umd.edu (8.8.3/8.7.3) with ESMTP id PAA07301 for ; Sun, 12 Jan 1997 15:41:18 -0500 (EST) Received: from localhost (chuckr@localhost) by gilligan.eng.umd.edu (8.8.3/8.7.3) with SMTP id PAA11262 for ; Sun, 12 Jan 1997 15:41:18 -0500 (EST) X-Authentication-Warning: gilligan.eng.umd.edu: chuckr owned process doing -bs Date: Sun, 12 Jan 1997 15:41:17 -0500 (EST) From: Chuck Robey X-Sender: chuckr@gilligan.eng.umd.edu To: FreeBSD-smp@freebsd.org Subject: process status? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What utility could I use (like top or something like that) that is aware of smp, and would show what's executing and where? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Mon Jan 13 01:15:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA01091 for smp-outgoing; Mon, 13 Jan 1997 01:15:13 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA01086 for ; Mon, 13 Jan 1997 01:15:08 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id CAA22677 for freebsd-smp@freebsd.org; Mon, 13 Jan 1997 02:15:06 -0700 (MST) From: Ade Barkah Message-Id: <199701130915.CAA22677@hemi.com> Subject: Data point, and questions... To: freebsd-smp@freebsd.org Date: Mon, 13 Jan 1997 02:15:06 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I tried running the smp kernel this weekend with various level of success. So far I'm pretty impressed. =-) Background: the motherboard is an Asus PCI/I-P54NP4D, with two Pentium 133s, and external cache disabled (broken). Supposedly I need a P54CM for the 2nd cpu, but the dealer installed an "off-the-shelf" P133, whatever that means. ** 1st try: compiled the kernel without the APIC_IO support as mptable suggests. After enabling the 2nd processor, most programs dump core with sig 11s. ** 2nd try: compiled a kernel with the APIC_IO support. Received the following message: | npx0: INT 16 interface | stray irq 13 | Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 11, 13, imen: 0x00ffd221 Hmm... reading npx.c says the FPU doesn't work in smp yet, so maybe the stray irq is ok. Now, sometimes (after a warm reboot, perhaps), the "13," doesn't show up, and the machine hangs. With this APIC_IO support, the machine appeared to be a little more stable, but after awhile it dies with random core dumps as well. ** 3rd try: I had an Adaptec 1542CF w/64mb + bounce buffer support. So, that might be part of the problem. I replaced it with an Adaptec 2940U, and compiled a new kernel with the Sys V shared mem support (for X) and the APIC_IO option. Things appear to be really stable so far. On reboot occasionally the machine hangs as the 2nd try above (right after Enabled INTs.) However, I've recompiled the kernel several times for testing and I've yet received a core dump. I've also compiled libc_r with no core dumps, so things really look promising. However... I can't tell if it's actually using two cpus! The "make -j 4" times using the smp w/apic and the uni-processor kernel yield almost identical times (about 14 minutes to compile an smp kernel, slow due to the disabled cache.) | % sysctl kern | grep smp | | kern.smp_active: 2 | kern.smp_cpus: 2 So, that looks normal... I don't know why I don't see any improve- ments at all. Is there another way to find out if processes are indeed running on two cpus ? I've appended my kernel configuration file below, in case it is interesting to anyone. ** Other notes: 1) On ps aux, all the STARTED times show "31Dec69". 2) The sio driver now regularly reports sio overflows. A modem is connected at 57.6k there. 3) Is there support for multi-threaded programs ? (I mean, do the threads run on multiple processors ?) I wrote a simple pthread program, and it doesn't look like the threads run in parallel. 4) Are there any other tests besides mptable you'd like me to run ? (mptable -verbose -dmesg output is appended below.) Thanks! Let me know if I can help in some way, even just to test something. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- 1) mptable -verbose -dmesg (mb: Asus PCI/I-P54NP4D) =============================================================================== MPTable, version 2.0.4 looking for EBDA pointer @ 0x040e, NOT found searching CMOS 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f98a0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f98a0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x48 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f98b4 signature: 'PCMP' base table length: 228 version: 1.1 checksum: 0x5c OEM ID: 'ASUSTEK1' Product ID: 'P54NIP400000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 20 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf -- Bus: Bus ID Type 0 ISA 1 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-SMP #0: Sun Jan 12 19:18:41 MST 1997 root@gw.barkah.org:/usr2/src/sys/compile/KERNEL FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 io0 (APIC): apic id: 2, version: 0x000f0011 Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1192906 Hz CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 62472192 (61008K bytes) Probing for devices on PCI bus 0: chip0 rev 17 on pci0:0 chip1 rev 136 on pci0:2 ahc0 rev 0 int a irq 15 on pci0:4 ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs (ahc0:0:0): "SEAGATE ST11200N 8334" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1005MB (2059140 512 byte sectors) (ahc0:1:0): "HP 2.13 GB #A1 9002" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 2033MB (4165272 512 byte sectors) (ahc0:4:0): "HP HP35480A 1133" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x13, drive empty (ahc0:6:0): "TOSHIBA CD-ROM XM-3501TA 2564" type 5 removable SCSI 2 cd0(ahc0:6:0): CD-ROM can't get the size vga0 rev 1 on pci0:5 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x278-0x27f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: aui/utp/bnc[*UTP*] address 00:a0:24:a3:3f:b0 npx0 on motherboard npx0: INT 16 interface stray irq 13 Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 13, 15, imen: 0x00ff5a21 SMP: All idle procs online. SMP: Starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! sio1: 1 more silo overflow (total 1) ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=2 # number of busses options NAPIC=1 # number of IO APICs options NINTR=15 # number of INTs =============================================================================== 2) Kernel configuration: # smp kernel for gw.barkah.org machine "i386" cpu "I586_CPU" cpu "I686_CPU" ident KERNEL maxusers 64 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=1 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options KTRACE options QUOTA options DDB options SYSVSHM options SYSVSEM options SYSVMSG options USER_LDT #allow user-level control of i386 ldt options SMP options APIC_IO options NCPU=2 options NBUS=2 options NAPIC=1 options NINTR=15 config kernel root on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr controller ahc0 controller scbus0 device sd0 device st0 device cd0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ep0 at isa? port 0x300 net irq 10 vector epintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device gzip pseudo-device tun 1 pseudo-device pty 16 pseudo-device bpfilter 4 From owner-freebsd-smp Mon Jan 13 07:41:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA17846 for smp-outgoing; Mon, 13 Jan 1997 07:41:52 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA17841 for ; Mon, 13 Jan 1997 07:41:50 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id HAA24335 for ; Mon, 13 Jan 1997 07:41:48 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id IAA15546; Mon, 13 Jan 1997 08:40:16 -0700 (MST) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id IAA28858; Mon, 13 Jan 1997 08:40:14 -0700 Date: Mon, 13 Jan 1997 08:40:14 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199701131540.IAA28858@fast.cs.utah.edu> To: freebsd-smp@freebsd.org, mbarkah@hemi.com Subject: Re: Data point, and questions... Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I need a P54CM for the 2nd cpu This is no longer the case. This was with the original Pentiums; all of Intel's current Pentiums are SMP-capable (well, maybe not the low-power notebook ones?) From owner-freebsd-smp Mon Jan 13 09:55:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA25493 for smp-outgoing; Mon, 13 Jan 1997 09:55:05 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA25478 for ; Mon, 13 Jan 1997 09:54:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA20622; Mon, 13 Jan 1997 10:54:27 -0700 Message-Id: <199701131754.KAA20622@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: Ade Barkah cc: freebsd-smp@FreeBSD.org Subject: Re: Data point, and questions... In-reply-to: Your message of "Mon, 13 Jan 1997 02:15:06 MST." <199701130915.CAA22677@hemi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Jan 1997 10:54:26 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, --- >* 1st try: compiled the kernel without the APIC_IO support as >mptable suggests. I just updated the web page with the latest version, 2.0.5: http://www.freebsd.org/~fsmp/SMP/mptable/mptable.c.gz This makes APIC_IO the default (now highly recommended, USE IT), as well as adding: options SMP_INVLTLB # this is also highly recommended (ie USE IT) --- >| npx0: INT 16 interface >| stray irq 13 >| Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 11, 13, imen: 0x00ffd221 > >Hmm... reading npx.c says the FPU doesn't work in smp yet, so >maybe the stray irq is ok. > >Now, sometimes (after a warm reboot, perhaps), the "13," doesn't >show up, and the machine hangs. not "OK", but a "feature" of the Neptune chipset! not possessing one I haven't been able to track this down. you are the 1st to report it actually hanging the machine. --- >With this APIC_IO support, the machine appeared to be a little more >stable, but after awhile it dies with random core dumps as well. > >** 3rd try: I had an Adaptec 1542CF w/64mb + bounce buffer support. >So, that might be part of the problem. this might work with the above mentioned SMP_INVLTLB option in effect. --- >However... I can't tell if it's actually using two cpus! The >"make -j 4" times using the smp w/apic and the uni-processor >kernel yield almost identical times (about 14 minutes to >compile an smp kernel, slow due to the disabled cache.) > >| % sysctl kern | grep smp >| >| kern.smp_active: 2 >| kern.smp_cpus: 2 this is strange, it looks like both are truly running. I wonder if lack of cache is causing this? --- 1) On ps aux, all the STARTED times show "31Dec69". known problem. --- >2) The sio driver now regularly reports sio overflows. A modem > is connected at 57.6k there. INTerrupt latency sucks right now because of our "giant lock" model. This is being thought over,,, it will be a big change to fix! I suspect that fixing your cache might help here also. --- >3) Is there support for multi-threaded programs ? (I mean, do > the threads run on multiple processors ?) I wrote a simple > pthread program, and it doesn't look like the threads run > in parallel. they DON'T, no kernel threading yet, libc_r time-shares a single process... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Jan 13 15:13:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14054 for smp-outgoing; Mon, 13 Jan 1997 15:13:32 -0800 (PST) Received: from cobber.cord.edu (cobber.cord.edu [138.129.1.32]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA14045 for ; Mon, 13 Jan 1997 15:13:23 -0800 (PST) Received: by cobber.cord.edu (4.1/SMI-4.1) id AA26568; Mon, 13 Jan 97 17:08:11 CST Date: Mon, 13 Jan 97 17:08:11 CST From: mestery@cobber.cord.edu (Kyle Mestery) Message-Id: <9701132308.AA26568@cobber.cord.edu> To: freebsd-smp@freebsd.org Subject: Status of (E)IDE drives Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I was wondering what the current status of EIDE drives is with the smp kernel. I have just purchased a Tyan Tomcat II motherboard, and I am about to purchase a disk for it, and if (for the time being) I couild save money and by a EIDE drive, it would be ghood! =) Thanks in advance. Kyle Mestery From owner-freebsd-smp Mon Jan 13 15:31:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA15003 for smp-outgoing; Mon, 13 Jan 1997 15:31:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA14992 for ; Mon, 13 Jan 1997 15:31:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA22255; Mon, 13 Jan 1997 16:30:12 -0700 Message-Id: <199701132330.QAA22255@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: mestery@cobber.cord.edu (Kyle Mestery) cc: freebsd-smp@freebsd.org Subject: Re: Status of (E)IDE drives In-reply-to: Your message of "Mon, 13 Jan 1997 17:08:11 CST." <9701132308.AA26568@cobber.cord.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Jan 1997 16:30:11 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > Hi. I was wondering what the current status of EIDE > drives is with the smp kernel. I have just purchased > a Tyan Tomcat II motherboard, and I am about to purchase > a disk for it, and if (for the time being) I couild save > money and by a EIDE drive, it would be ghood! =) my belief is that they work if options APIC_IO and SMP_INVLTLB are both set. can users confirm this? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Jan 13 16:16:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18274 for smp-outgoing; Mon, 13 Jan 1997 16:16:58 -0800 (PST) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA18258 for ; Mon, 13 Jan 1997 16:16:36 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vjwcI-0007Ge-00; Mon, 13 Jan 1997 16:20:38 -0800 To: smp@freebsd.org Subject: Re: Status of (E)IDE drives In-reply-to: Your message of "Mon, 13 Jan 1997 16:30:11 MST." <199701132330.QAA22255@clem.systemsix.com> Date: Mon, 13 Jan 1997 16:20:38 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > > Hi. I was wondering what the current status of EIDE > > drives is with the smp kernel. I have just purchased > > a Tyan Tomcat II motherboard, and I am about to purchase > > a disk for it, and if (for the time being) I couild save > > money and by a EIDE drive, it would be ghood! =) > > my belief is that they work if options APIC_IO and SMP_INVLTLB are both set. > can users confirm this? I didn't use an IDE drive for booting, but I could read the contents of the IDE disk I use for DOS/Windows/NT just fine (with APIC_IO and SMP_INVLTLB). -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Tue Jan 14 00:20:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA29633 for smp-outgoing; Tue, 14 Jan 1997 00:20:23 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA29628 for ; Tue, 14 Jan 1997 00:20:20 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id BAA13027; Tue, 14 Jan 1997 01:20:17 -0700 (MST) From: Ade Barkah Message-Id: <199701140820.BAA13027@hemi.com> Subject: Re: Data point, and questions... To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Date: Tue, 14 Jan 1997 01:20:17 -0700 (MST) Cc: freebsd-smp@freebsd.org In-Reply-To: <199701131540.IAA28858@fast.cs.utah.edu> from Kevin Van Maren at "Jan 13, 97 08:40:14 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I need a P54CM for the 2nd cpu > > This is no longer the case. This was with the original Pentiums; > all of Intel's current Pentiums are SMP-capable (well, maybe not > the low-power notebook ones?) Thanks. That was my impression when I read the mindshare Pentium book. Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-smp Tue Jan 14 09:39:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA25182 for smp-outgoing; Tue, 14 Jan 1997 09:39:26 -0800 (PST) Received: from gloria.cord.edu (gloria.cord.edu [138.129.254.6]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA25154 for ; Tue, 14 Jan 1997 09:39:21 -0800 (PST) Received: (kamester@localhost) by gloria.cord.edu (8.8.4/8.6.5) id LAA01926; Tue, 14 Jan 1997 11:39:12 -0600 (CST) Date: Tue, 14 Jan 1997 11:39:11 -0600 (CST) From: Kyle Mestery To: freebsd-smp@freebsd.org Subject: Re: Status of (E)IDE drives In-Reply-To: <199701140529.GAA26172@donau.informatik.uni-rostock.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'll try to report as fast as I can, but I'm a bit busy doing > publications and classes for my boss right now. > Hope I can test the new kernel until the end of next week, Kyle, > maybe you have the time to wait ? That woudl be great Gunther! I woudl really appreciate any input you have. I am putting off buying a drive until at least next week anyways. Thanks for the help! Kyle -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Kyle A.D. Mestery | --* POWERED BY FREEBSD *-- 1901 20th St. S #4 | Network Support Specialist Moorhead, MN 56560 | Concordia College, Moorhead, MN 218-236-6359 | "My other computer runs UNIX also" -TJ From owner-freebsd-smp Tue Jan 14 12:33:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA05522 for smp-outgoing; Tue, 14 Jan 1997 12:33:59 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA05318 for ; Tue, 14 Jan 1997 12:29:59 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id PAA02896 for smp@freebsd.org; Tue, 14 Jan 1997 15:29:21 -0500 (EST) From: Keith Mitchell Message-Id: <199701142029.PAA02896@weenix.guru.org> Subject: Tomcat III and APIC_IO To: smp@freebsd.org Date: Tue, 14 Jan 1997 15:29:21 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone been able to get the Tomcat III MB to work with APIC_IO?? I tried the following combinations: APIC_IO and SMP_INVLTLB APIC_IO SMP_INVLTLB (just SMP) Under the first two conditions, the kernel booted but then hung right before passing control to init (I think). It showed all of the usual kernel lines and then just sat there. In the third situation it booted, but when I turned on the second processor it panic'd. The last condition appears to work ok. Here is my kernel config: # # Kernel Config for weenix # machine "i386" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident WEENIX maxusers 20 # # Miscellaneous Options # options GPL_MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options SHOW_BUSYBUFS #Show Busy Buffers at root unmount options BOUNCE_BUFFERS #Support DMA >16MB options UCONSOLE #Support User Consoles options QUOTA #Enable System Quotas options SYSVSHM #System V Shared Memory options SYSVSEM #System V Shared Memory options SYSVMSG #System V Shared Memory options USER_LDT #Needed for Wine options IPFIREWALL #Firewall Code options IPFIREWALL_VERBOSE #Tell me about firewalled packets options CHILD_MAX=128 #Maximum number of child processes options OPEN_MAX=128 #Maximum number of open files? options USERCONFIG #Boot -c editor options VISUAL_USERCONFIG #Visual -c editor # # Multiprocessor Options # options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O #options SMP_INVLTLB # # # File systems # options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options KERNFS #Kernel filesystem options DEVFS #Device File System options "EXT2FS" #Linux File system # # Compatibility Options # options LINUX_COMPAT #Linux Compatibility options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options "IBCS2" # # SCSI options # options SCSI_DELAY=15 options SCSI_REPORT_GEOMETRY options AHC_TAGENABLE options AHC_SCBPAGING_ENABLE config kernel root on sd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 # # SCSI Config # controller ncr0 controller ahc0 controller scbus0 at ahc0 bus 0 controller scbus1 at ahc0 bus 1 disk sd0 at scbus0 target 0 disk sd1 at scbus0 target 3 device sd0 at scbus? device st0 at scbus? device cd0 at scbus? device worm0 at scbus? # # Console drivers # device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # On-board com ports # device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr # # STB Multiport board # options COM_MULTIPORT device sio1 at isa? port 0x3e8 tty flags 0x485 vector siointr device sio2 at isa? port 0x1a8 tty flags 0x485 vector siointr device sio3 at isa? port 0x1e8 tty flags 0x485 vector siointr device sio4 at isa? port 0x1f8 tty irq 15 flags 0x485 vector siointr # # Miscellaneous Devices # device lpt0 at isa? port? tty irq 7 vector lptintr device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr # # Ethernet Cards # device de0 device de1 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 64 pseudo-device snp 4 pseudo-device ccd pseudo-device vn 2 pseudo-device speaker pseudo-device bpfilter 4 pseudo-device gzip ------------------------------ mptable -verbose -dmesg output ------------------------------ =============================================================================== MPTable, version 2.0.5 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f0c80 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0c80 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xf4 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f0c94 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0xa5 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf -- Bus: Bus ID Type 0 ISA 1 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0 2 0 INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 INT active-lo level 1 20:A 2 16 INT active-lo level 1 19:A 2 17 INT active-lo level 1 18:A 2 18 INT active-lo level 1 17:A 2 19 SMI conforms conforms 0 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 0 0 255 0 NMI active-hi edge 0 0 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=2 # number of busses options NAPIC=1 # number of IO APICs options NINTR=21 # number of INTs options SMP_INVLTLB # #options SMP_PRIVPAGES # BROKEN, DO NOT use! #options SMP_AUTOSTART # BROKEN, DO NOT use! #options SERIAL_DEBUG # com port debug output ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-SMP #0: Tue Jan 14 15:09:12 EST 1997 kmitch@weenix.guru.org:/usr/src/sys-smp/compile/WEENIX FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 Warning: APIC I/O disabled Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193133 Hz CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 62459904 (60996K bytes) DEVFS: ready for devices Probing for devices on PCI bus 0: chip0 rev 3 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 de0 rev 35 int a irq 9 on pci0:17 de0: 21040 [10Mb/s] pass 2.3 de0: address 00:80:48:e8:19:cd de0: enabling 10baseT port chip3 rev 2 on pci0:18 vga0 rev 1 on pci0:19 de1 rev 35 int a irq 11 on pci0:20 de1: 21040 [10Mb/s] pass 2.3 de1: address 00:80:48:e8:17:a4 de1: enabling 10baseT port Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 10 on pci1:4 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0 waiting for scsi devices to settle ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "MICROP 4221-09 1128RF 28RF" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) sd0(ahc0:0:0): with 4048 cyls, 9 heads, and an average 109 sectors/track ahc0: target 3 Tagged Queuing Device (ahc0:3:0): "iomega jaz 1GB H.62" type 0 removable SCSI 2 sd1(ahc0:3:0): Direct-Access sd1(ahc0:3:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) sd1(ahc0:3:0): with 1021 cyls, 64 heads, and an average 32 sectors/track (ahc0:4:0): "ARCHIVE Python 28388-XXX 5.28" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x13, drive empty (ahc0:5:0): "PLEXTOR CD-ROM PX-6XCS 1.07" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM can't get the size ahc1 rev 0 int a irq 9 on pci1:5 ahc1: aic7880 Wide Channel B, SCSI Id=7, 16/255 SCBs ahc1 waiting for scsi devices to settle ahc1: target 0 Tagged Queuing Device (ahc1:0:0): "Quantum XP32150 576D" type 0 fixed SCSI 2 sd2(ahc1:0:0): Direct-Access 2050MB (4199760 512 byte sectors) sd2(ahc1:0:0): with 3907 cyls, 10 heads, and an average 107 sectors/track ahc1: target 1 Tagged Queuing Device (ahc1:1:0): "CONNER CFP1080S 4649" type 0 fixed SCSI 2 sd3(ahc1:1:0): Direct-Access 1030MB (2110812 512 byte sectors) sd3(ahc1:1:0): with 3658 cyls, 6 heads, and an average 96 sectors/track Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 sio1 at 0x3e8-0x3ef flags 0x485 on isa sio1: type 16550A (multiport) sio2 at 0x1a8-0x1af flags 0x485 on isa sio2: type 16550A (multiport) sio3 at 0x1e8-0x1ef flags 0x485 on isa sio3: type 16550A (multiport) sio4 at 0x1f8-0x1ff irq 15 flags 0x485 on isa sio4: type 16550A (multiport master) lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 3 buttons? fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface DEVFS: ready to run ccd0: Concatenated disk driver IP packet filtering initialized, divert disabled, unlimited logging SMP: All idle procs online. SMP: Starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! =============================================================================== From owner-freebsd-smp Tue Jan 14 14:05:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11225 for smp-outgoing; Tue, 14 Jan 1997 14:05:47 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA11206 for ; Tue, 14 Jan 1997 14:05:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA28385; Tue, 14 Jan 1997 15:04:10 -0700 Message-Id: <199701142204.PAA28385@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: Keith Mitchell cc: smp@freebsd.org Subject: Re: Tomcat III and APIC_IO In-reply-to: Your message of "Tue, 14 Jan 1997 15:29:21 EST." <199701142029.PAA02896@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jan 1997 15:04:10 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Has anyone been able to get the Tomcat III MB to work with APIC_IO?? > > I tried the following combinations: > > APIC_IO and SMP_INVLTLB > APIC_IO > SMP_INVLTLB > (just SMP) > > Under the first two conditions, the kernel booted but then hung right before > passing control to init (I think). It showed all of the usual kernel lines > and then just sat there. In the third situation it booted, but when I turned > on the second processor it panic'd. The last condition appears to work ok. case #1 is the preferred situation, if it doesn't work you (or my code) have a fundimental problem. case #2 should work, but as stated above, should be used with SMP_INVLTLB. case #3 (SMP_INVLTLB) NEEDS APIC_IO to work, hence the panic. I suppose I should add code somewhere that: #if defined( SMP_INVLTLB ) && !defined( APIC_IO ) #error you MUST use option APIC_IO to use option SMP_INVLTLB #endif case #4 obviously NEEDs to work, but #1 SHOULD have. you need to detrermine where exactly it is hanging. A copy of all output leading up to the hang would be helpful. --- > Here is my kernel config: > ... alot of extras here, start out with a GENERIC config file, strip it of everything you dont need, then add the SMP specific stuff (APIC_IO & SMP_INVLTLB). See if this works. --- > ------------------------------ > mptable -verbose -dmesg output > ------------------------------ > ... > INT active-lo level 1 20:A 2 16 > INT active-lo level 1 19:A 2 17 > INT active-lo level 1 18:A 2 18 > INT active-lo level 1 17:A 2 19 > ... > dmesg output: > ... > Probing for devices on PCI bus 1: > ahc0 rev 0 int a irq 10 on pci1:4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^ my guess is that my APIC code might not be correctly handling the 3940. Specifically I see that it is on pci bus #1, NOT #0, I don't know how well I handle that right now. The basic problem is that it isn't clear to me how I'm suppossed to translate pci bus #s from the MP table entries... In most cases there is just bus #0 so there is no ambiguity. Again I need to see all the output from the boot preceeding the hang to be able to help. To get this without a LOT of retyping you will want to setup a serial console boot. I posted a quickie document on doing this awhile back, look with the search engine in SMP mail for "debugging SMP kernels". If that doesn't work let me know and I'll mail it to you. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Jan 14 14:19:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11793 for smp-outgoing; Tue, 14 Jan 1997 14:19:32 -0800 (PST) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [206.54.227.6]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA11787 for ; Tue, 14 Jan 1997 14:19:28 -0800 (PST) Received: from arabian.astrolab.org (dial224.nconnect.net [206.54.227.224]) by atlantis.nconnect.net (8.8.4/8.7.3) with SMTP id QAA19749; Tue, 14 Jan 1997 16:14:31 -0600 (CST) Message-ID: <32DC061B.41C67EA6@nconnect.net> Date: Tue, 14 Jan 1997 16:18:03 -0600 From: Randy DuCharme Organization: Computer Specialists X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-SMP i386) MIME-Version: 1.0 To: Keith Mitchell CC: smp@freebsd.org Subject: Re: Tomcat III and APIC_IO References: <199701142029.PAA02896@weenix.guru.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Keith Mitchell wrote: > > Has anyone been able to get the Tomcat III MB to work with APIC_IO?? > < whack > Yes. Mine runs FLAWLESSLY ( and fast too! ) with dual 200s. Here's my config FWIW.... # $Id: ARABIAN_SMP, v 1.0.0 1996/12/26 rdd Exp $ machine "i386" cpu "I586_CPU" ident ARABIAN_SMP maxusers 10 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console #options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options "MAXMEM=98284" options "AUTO_EOI_1" options "AUTO_EOI_2" options CHILD_MAX=128 options OPEN_MAX=128 options SMP options NCPU=2 options APIC_IO options SMP_INVLTLB config kernel root on sd1 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 controller ahc0 controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # Mandatory, don't remove device npx0 at isa? port "IO_NPX" iosiz 0x0 flags 0x0 irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. #options KTRACE #kernel tracing From owner-freebsd-smp Tue Jan 14 14:42:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA12887 for smp-outgoing; Tue, 14 Jan 1997 14:42:02 -0800 (PST) Received: from trout.nosc.mil (trout.nosc.mil [128.49.16.7]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA12882 for ; Tue, 14 Jan 1997 14:41:59 -0800 (PST) Received: from manta.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA20767; Tue, 14 Jan 97 14:41:51 PST Received: from [128.49.16.48] (aegis.nosc.mil) by manta.nosc.mil (4.1/SMI-4.1) id AA05693; Tue, 14 Jan 97 14:41:42 PST X-Sender: gshaffer@cod.nosc.mil Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jan 1997 14:40:53 -0800 To: Keith Mitchell From: Greg Shaffer Subject: Re: Tomcat III and APIC_IO Cc: smp@freebsd.org Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a Tomcat III MB with APIC_IO enabled and it works great! I have not tried the SMP_INVLTLB option yet. Greg Shaffer >Has anyone been able to get the Tomcat III MB to work with APIC_IO?? > >I tried the following combinations: > > APIC_IO and SMP_INVLTLB > APIC_IO > SMP_INVLTLB > (just SMP) > >Under the first two conditions, the kernel booted but then hung right before >passing control to init (I think). It showed all of the usual kernel lines >and then just sat there. In the third situation it booted, but when I turned >on the second processor it panic'd. The last condition appears to work ok. > From owner-freebsd-smp Tue Jan 14 17:11:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22478 for smp-outgoing; Tue, 14 Jan 1997 17:11:07 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22470; Tue, 14 Jan 1997 17:11:04 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id UAA00835; Tue, 14 Jan 1997 20:10:58 -0500 (EST) From: Keith Mitchell Message-Id: <199701150110.UAA00835@weenix.guru.org> Subject: Adaptec 3940UW and SMP To: hackers@freebsd.org Date: Tue, 14 Jan 1997 20:10:58 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am having a problem getting APIC_IO working on my Tyan Tomcat III motherboard with SMP. I originally posted to the smp mailing list and was advised to also post here (by Steve Passe). The symptoms are: with the APIC_IO option enabled, the kernel boots and then stops never passing control over to init to finish the boot. At this point I can usually Ctrl-Alt-Del and reboot although once or twice it actually locked up the computer. (see boot messages at the bottom of this message) Without APIC_IO it seems to work ok. Unfortunately, I don't have another SCSI controller to try. Any ideas?? Let me know if I forgot to include a necessary piece of info. Below are various responses from Steve concerning this matter (summary): [---- snip of message from steve quoting boot messages.----] > ... >Probing for devices on PCI bus 1: >ahc0 rev 0 int a irq 10 on pci1:4 > ... >ahc1 rev 0 int a irq 9 on pci1:5 > ... >Enabled INTs: 1, 2, 4, 6, 7, 8, 9, 10, 12, 16, 19, imen: 0x00f6e829 as I predicted, it fails to remap the 3940 properly. However it does appear to leave it at INTs 10 & 9, and INTs 10 & 9 appear to be enabled. [---- Another message from steve ----] Might be a missing INT problem. If you can borrow another disk controller (2940/154x/etc) it would be an interesting experiment. My suspicion is that the 3940 is not working correctly in this setup. Unfortunately I don't have alot of time to pursue this right now, I've got a "real job" that is consumming my time... If anything occurs to me I'll get back to you. You might also post a summary of the problem and my suspicions on hackers@freebsd.org. I worked with STefan to get the original PCI stuff working, he might have insite on the 3940 & PCI. [Below is the verbose boot with APIC_IO enabled:] BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value ipi_ihandler_attach: counting ipi irq24's as clk0 irqs ipi_ihandler_attach: counting ipi irq25's as clk0 irqs ipi_ihandler_attach: counting ipi irq26's as clk0 irqs ipi_ihandler_attach: counting ipi irq27's as clk0 irqs Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-SMP #0: Tue Jan 14 18:01:59 EST 1997 kmitch@weenix.guru.org:/usr/src/sys-smp/compile/W FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 io0 (APIC): apic id: 2, version: 0x00170011 Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193130 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 63782912 (62288K bytes) pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12508086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 3 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 mapreg[20] type=1 addr=00009000 size=0010. de0 rev 35 int a irq 19 on pci0:17 Freeing (NOT implimented) irq 9 for ISA cards. mapreg[10] type=1 addr=00006000 size=0080. mapreg[14] type=0 addr=e0800000 size=0080. reg16: ioaddr=0x6000 size=0x80 de0: 21040 [10Mb/s] pass 2.3 de0: address 00:80:48:e8:19:cd de0: enabling 10baseT port chip3 rev 2 on pci0:18 Freeing (NOT implimented) irq 9 for ISA cards. bridge from pci0 to pci1 through 1. mapping regs: io:2280f0f0 mem:dff0d000 pmem:dff0de00 vga0 rev 1 on pci0:19 Freeing (NOT implimented) irq 9 for ISA cards. mapreg[10] type=0 addr=e0000000 size=800000. de1 rev 35 int a irq 16 on pci0:20 Freeing (NOT implimented) irq 11 for ISA cards. mapreg[10] type=1 addr=00006100 size=0080. mapreg[14] type=0 addr=e0801000 size=0080. reg16: ioaddr=0x6100 size=0x80 de1: 21040 [10Mb/s] pass 2.3 de1: address 00:80:48:e8:17:a4 de1: enabling 10baseT port pci0: uses 8388864 bytes of memory from d0000000 upto e080107f. pci0: uses 272 bytes of I/O space from 6000 upto ffff. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 10 on pci1:4 mapreg[10] type=1 addr=0000f000 size=0100. [pci1 uses memory from d0000000 to dfffffff] mapreg[14] type=0 addr=d0000000 size=1000. reg16: ioaddr=0xf000 size=0x100 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A Choosing drivers for scbus configured at 0 ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0x8 (ahc0:0:0): "MICROP 4221-09 1128RF 28RF" type 0 fixed SCSI 2 sd is configured at 0 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) sd0(ahc0:0:0): with 4048 cyls, 9 heads, and an average 109 sectors/track ahc0: target 3 synchronous at 10.0MHz, offset = 0xf (ahc0:3:0): "iomega jaz 1GB H.62" type 0 removable SCSI 2 sd is configured at 1 sd1(ahc0:3:0): Direct-Access sd1(ahc0:3:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) sd1(ahc0:3:0): with 1021 cyls, 64 heads, and an average 32 sectors/track ahc0: target 4 synchronous at 5.0MHz, offset = 0xf (ahc0:4:0): "ARCHIVE Python 28388-XXX 5.28" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x13, drive empty ahc0: target 5 synchronous at 5.0MHz, offset = 0xf (ahc0:5:0): "PLEXTOR CD-ROM PX-6XCS 1.07" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM can't get the size ahc1 rev 0 int a irq 9 on pci1:5 mapreg[10] type=1 addr=0000f100 size=0100. [pci1 uses memory from d0000000 to dfffffff] mapreg[14] type=0 addr=d0001000 size=1000. reg16: ioaddr=0xf100 size=0x100 ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 0 synchronous at 10.0MHz, offset = 0xf (ahc1:0:0): "Quantum XP32150 576D" type 0 fixed SCSI 2 sd2(ahc1:0:0): Direct-Access 2050MB (4199760 512 byte sectors) sd2(ahc1:0:0): with 3907 cyls, 10 heads, and an average 107 sectors/track ahc1: target 1 synchronous at 10.0MHz, offset = 0xf (ahc1:1:0): "CONNER CFP1080S 4649" type 0 fixed SCSI 2 sd3(ahc1:1:0): Direct-Access 1030MB (2110812 512 byte sectors) sd3(ahc1:1:0): with 3658 cyls, 6 heads, and an average 96 sectors/track pci1: uses 8192 bytes of memory from d0000000 upto d0001fff. pci1: uses 512 bytes of I/O space from f000 upto f1ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0: current command byte:0047 psm0: status after reset 00 02 64 psm: status 09 03 c8 (get_mouse_buttons) psm0: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 3 buttons? fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface imasks: bio c0000640, tty f0091092, net f0091092 BIOS Geometries: 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors 1:03fc3f20 0..1020=1021 cylinders, 0..63=64 heads, 1..32=32 sectors 2:0104fe3f 0..260=261 cylinders, 0..254=255 heads, 1..63=63 sectors 3:0082fe3f 0..130=131 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. Enabled INTs: 1, 2, 4, 6, 7, 8, 9, 10, 12, 16, 19, imen: 0x00f6e829 [computer is now hung] From owner-freebsd-smp Tue Jan 14 21:05:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA06116 for smp-outgoing; Tue, 14 Jan 1997 21:05:39 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA06100; Tue, 14 Jan 1997 21:05:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA00551; Tue, 14 Jan 1997 22:05:20 -0700 Message-Id: <199701150505.WAA00551@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: Keith Mitchell cc: hackers@freebsd.org, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Tue, 14 Jan 1997 20:10:58 EST." <199701150110.UAA00835@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jan 1997 22:05:20 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have been looking over your data and saw something "not right". In the first mailing, ie the one with APIC_IO NOT enabled, I see: de0 rev 35 int a irq 9 on pci0:17 ... ^^^^^ ahc1 rev 0 int a irq 9 on pci1:5 ^^^^^ I know that generically PCI INTerrupts can be shared, but I didn't think that they could when redirected via the ISA bus, but perhaps they can, as this version appears to work. Now in the second mailing, ie the one with APIC_IO enabled, I see: de0 rev 35 int a irq 19 on pci0:17 Freeing (NOT implimented) irq 9 for ISA cards. ^^^^^ ... ahc1 rev 0 int a irq 9 on pci1:5 ^^^^^ The "Freeing (NOT implimented) irq 9 for ISA cards." line is saying that since the APIC_IO code is using the CORRECT PCI irq 19 to service the de0 card, it SHOULD be "undirecting" the ISA irq 9 from it. The "NOT implimented" part notes the fact that this code hasn't been written yet (because its chipset dependant and I don't have all the info I need to support all the possible chipsets yet). So we have a situation where the upper level PCI code knows that 2 distinct IRQs are being used for de0 and ahc1 (19 & 9) BUT the hardware is delivering INTs generated by the ahc1 via both the ahc1 vector (irq 9) AND the de0 vector (irq 19). This could explain the missing INTs as well as the "sometimes" locks. Test this theory by booting the APIC_IO SMP kernel with the de0 card removed from the system. Note that with this card removed the BIOS will probably re-assign the PCI INTs, possibly causing de1 to provoke the same problem, remove it also for this test. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Jan 14 21:14:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA07424 for smp-outgoing; Tue, 14 Jan 1997 21:14:05 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA07419 for ; Tue, 14 Jan 1997 21:14:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA00636; Tue, 14 Jan 1997 22:13:43 -0700 Message-Id: <199701150513.WAA00636@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: Chuck Robey cc: smp@freebsd.org Subject: Re: MP-1.4 spec In-reply-to: Your message of "Tue, 14 Jan 1997 23:52:38 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jan 1997 22:13:43 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was browsing the smp web page, seeing how I could contribute more, and I > came across a reference to the mp-1.4 spec. the link was bad, could you > either send me a good link for it, or maybe put the doc up for ftp > somewhere? I want to read it, thanks. I just got this mail earlier today from Intel: >From: Devin Donnelly >To: smp@csn.net >Subject: Intel Support Site Moves >We are migrating our support content to a new server. Please change your >bookmarks to reflect this move and visit us at > our new site, http://support.intel.com. so I imagine most/all my links to the Intel stuff are BROKEN. I will need to start at the above referenced link and refind them all again. Feel free to go looking yourself, I don't know when I will have the time. I may or may not have a local copy around, I'll look... Please forward any new links you find! -- 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----- From owner-freebsd-smp Tue Jan 14 21:27:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA08096 for smp-outgoing; Tue, 14 Jan 1997 21:27:18 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA08086 for ; Tue, 14 Jan 1997 21:27:10 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id AAA25700; Wed, 15 Jan 1997 00:26:34 -0500 (EST) From: Kenneth Merry Message-Id: <199701150526.AAA25700@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701150110.UAA00835@weenix.guru.org> from Keith Mitchell at "Jan 14, 97 08:10:58 pm" To: kmitch@weenix.guru.org (Keith Mitchell) Date: Wed, 15 Jan 1997 00:26:33 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [hackers taken out of CC so folks don't get upset...:)] Keith Mitchell wrote... > I am having a problem getting APIC_IO working on my Tyan Tomcat III > motherboard with SMP. I originally posted to the smp mailing list and > was advised to also post here (by Steve Passe). > > The symptoms are: > > with the APIC_IO option enabled, the kernel boots and then stops > never passing control over to init to finish the boot. At this > point I can usually Ctrl-Alt-Del and reboot although once or twice > it actually locked up the computer. (see boot messages at the > bottom of this message) > > Without APIC_IO it seems to work ok. > > Unfortunately, I don't have another SCSI controller to try. > > Any ideas?? Let me know if I forgot to include a necessary piece of info. > > > Below are various responses from Steve concerning this matter (summary): > > [---- snip of message from steve quoting boot messages.----] > > ... > >Probing for devices on PCI bus 1: > >ahc0 rev 0 int a irq 10 on pci1:4 > > ... > >ahc1 rev 0 int a irq 9 on pci1:5 > > ... > >Enabled INTs: 1, 2, 4, 6, 7, 8, 9, 10, 12, 16, 19, imen: 0x00f6e829 > > as I predicted, it fails to remap the 3940 properly. However it does > appear to leave it at INTs 10 & 9, and INTs 10 & 9 appear to be enabled. > > > [---- Another message from steve ----] > Might be a missing INT problem. If you can borrow another disk controller > (2940/154x/etc) it would be an interesting experiment. My suspicion is that > the 3940 is not working correctly in this setup. > > Unfortunately I don't have alot of time to pursue this right now, I've > got a "real job" that is consumming my time... If anything occurs to me > I'll get back to you. You might also post a summary of the problem and > my suspicions on hackers@freebsd.org. I worked with STefan to get the original > PCI stuff working, he might have insite on the 3940 & PCI. Well, I seem to have a similar problem. I too have a 3940UW, and when I enabled APIC_IO, the kernel would hang right before it should have gone to init. Here's a synopsis of my h/w configuration: ASUS P/I-P65UP5 w/ C-P6ND cpu card, 2x200MHz, 256K Pentium Pros 128MB ram Adaptec 3940UW Quantum Atlas II (Ultra, Wide) Plextor cdrom SMC Etherpower 10/100 Here's boot -v, *without* APIC_IO enabled, don't have a serial console setup: ============================================================================= pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12378086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 mapreg[20] type=1 addr=0000e800 size=0010. de0 rev 18 int a irq 10 on pci0:10 mapreg[10] type=1 addr=0000e000 size=0080. mapreg[14] type=0 addr=fa000000 size=0080. reg16: ioaddr=0xe000 size=0x80 de0: SMC 9332 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:53:3d:e7 de0: enabling 10baseT port bpf: de0 attached chip3 rev 2 on pci0:11 bridge from pci0 to pci1 through 1. mapping regs: io:2280d0d0 mem:f9f0f900 pmem:fbf0fbf0 vga0 rev 1 int a irq 9 on pci0:13 mapreg[10] type=0 addr=f8800000 size=4000. mapreg[14] type=0 addr=fb000000 size=800000. pci0: uses 8405120 bytes of memory from f8800000 upto fbffffff. pci0: uses 144 bytes of I/O space from d000 upto e80f. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 11 on pci1:4 mapreg[10] type=1 addr=0000d800 size=0100. [pci1 uses memory from f9000000 to f9ffffff] mapreg[14] type=0 addr=f9800000 size=1000. reg16: ioaddr=0xd800 size=0x100 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0x8 (ahc0:0:0): "QUANTUM XP34550W LXQ1" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4341MB (8890760 512 byte sectors) sd0(ahc0:0:0): with 5899 cyls, 10 heads, and an average 150 sectors/track ahc1 rev 0 int a irq 10 on pci1:5 mapreg[10] type=1 addr=0000d400 size=0100. [pci1 uses memory from f9000000 to f9ffffff] mapreg[14] type=0 addr=f9000000 size=1000. reg16: ioaddr=0xd400 size=0x100 using shared irq 10. ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 4 synchronous at 10.0MHz, offset = 0xf (ahc1:4:0): "PLEXTOR CD-ROM PX-12CS 1.00" type 5 removable SCSI 2 cd0(ahc1:4:0): CD-ROM can't get the size pci1: uses 8192 bytes of memory from f9000000 upto f9800fff. pci1: uses 512 bytes of I/O space from d400 upto d8ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached lpt1: disabled, not probed. psm0: current command byte:0047 psm0: status after reset 00 02 64 psm: status b1 03 c8 (get_mouse_buttons) psm0: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 3 buttons? fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0000c40, tty c003149a, net c003149a BIOS Geometries: 0:0228fe3f 0..552=553 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. DEVFS: ready to run bpf: tun0 attached bpf: tun1 attached bpf: tun2 attached bpf: sl0 attached bpf: lo0 attached IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry sd0s1: type 0x7, start 63, end = 2040254, size 2040192 : OK sd0s2: type 0xa5, start 2040255, end = 8883944, size 6843690 : OK SMP: All idle procs online. SMP: Starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! ============================================================================= Here is the output of mptable -verbose -dmesg: (this was done with a stock -current kernel) =============================================================================== MPTable, version 2.0.5 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f60b0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f60b0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x8e mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f5caa signature: 'PCMP' base table length: 252 version: 1.1 checksum: 0xd6 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 1 7 0xfbff 0 0x11 AP, usable 6 1 7 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 0 2 2 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 5 2 5 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT conforms conforms 2 8 2 8 INT conforms conforms 2 12 2 12 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT active-lo level 2 11 2 17 INT active-lo level 2 10 2 18 INT active-lo level 2 9 2 19 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 2 0 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=15 # number of INTs options SMP_INVLTLB # #options SMP_PRIVPAGES # BROKEN, DO NOT use! #options SMP_AUTOSTART # BROKEN, DO NOT use! #options SERIAL_DEBUG # com port debug output ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Sun Jan 12 01:52:10 EST 1997 ken@panzer.res.gatech.edu:/usr/src/sys/compile/panzer Calibrating clock(s) relative to mc146818A clock ... i586 clock: 199428199 Hz, i8254 clock: 1193161 Hz CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 134217728 (131072K bytes) avail memory = 129413120 (126380K bytes) DEVFS: ready for devices Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 de0 rev 18 int a irq 10 on pci0:10 de0: SMC 9332 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:53:3d:e7 de0: enabling 10baseT port chip3 rev 2 on pci0:11 vga0 rev 1 int a irq 9 on pci0:13 Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 11 on pci1:4 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "QUANTUM XP34550W LXQ1" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4341MB (8890760 512 byte sectors) ahc1 rev 0 int a irq 10 on pci1:5 ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1 waiting for scsi devices to settle (ahc1:4:0): "PLEXTOR CD-ROM PX-12CS 1.00" type 5 removable SCSI 2 cd0(ahc1:4:0): CD-ROM can't get the size Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1: disabled, not probed. psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 2 buttons? fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. DEVFS: ready to run IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry WARNING: / was not properly dismounted. pid 7463 (conftest), uid 0: exited on signal 11 (core dumped) de0: promiscuous mode enabled de0: promiscuous mode enabled de0: promiscuous mode enabled =============================================================================== And here is my kernel config file. (hope this isn't too much information: =============================================================================== # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.77.2.1 1996/12/21 02:10:50 se Exp $ machine "i386" # cpu "I386_CPU" # cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident panzer maxusers 128 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options CHILD_MAX=128 options OPEN_MAX=128 options SYSVSHM options SYSVSEM options SYSVMSG options KTRACE options MROUTING options IPFIREWALL options IPFIREWALL_VERBOSE options "IPFIREWALL_VERBOSE_LIMIT=100" options IPDIVERT options DEVFS options "MAXMEM=(128*1024)" options MAXCONS=16 # options AHC_TAGENABLE # options AHC_SCBPAGING_ENABLE # options AHC_ALLOW_MEMIO options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=15 # number of INTs #options SMP_INVLTLB # #options SMP_PRIVPAGES # BROKEN, DO NOT use! #options SMP_AUTOSTART # BROKEN, DO NOT use! #options SERIAL_DEBUG # com port debug output config kernel root on sd0 controller isa0 # controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 # tape ft0 at fdc0 drive 2 # controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr # disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr # disk wd2 at wdc1 drive 0 # disk wd3 at wdc1 drive 1 # options ATAPI #Enable ATAPI support for IDE bus # options ATAPI_STATIC #Don't do it as an LKM # device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. # controller ncr0 # controller amd0 # controller ahb0 controller ahc0 options "AHC_FORCE_PIO" # Some motherboards choke on MemI/O, # so use PIO in the ahc driver in the # generic kernel. controller scbus0 device sd0 device od0 #See LINT for possible `od' options. device st0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # device apm0 at isa? disable # Advanced Power Management options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS # PCCARD (PCMCIA) support #controller crd0 #device pcic0 at crd? #device pcic1 at crd? device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device lpt1 at isa? port? tty # device mse0 at isa? port 0x23c tty irq 5 vector mseintr device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 # device fxp0 # device vx0 # device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 3 pseudo-device pty 128 pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 4 pseudo-device snp 3 =============================================================================== And, here's a little kernel-compile benchmark test I did. (similar to what Chuck did) Dual Pentium Pro 200, 256K L2, 128MB RAM, 2 processors online: real/normalized make -j 1, 225.28 real 121.61 user 74.13 sys 1.000 make -j 2, 165.95 real 148.20 user 56.54 sys 1.357 make -j 3, 133.38 real 158.23 user 49.06 sys 1.689 make -j 4, 124.53 real 164.24 user 43.89 sys 1.809 make -j 5, 122.22 real 164.03 user 45.48 sys 1.843 make -j 6, 116.35 real 162.52 user 47.50 sys 1.936 make -j 7, 115.74 real 167.47 user 42.89 sys 1.946 make -j 8, 117.03 real 165.15 user 45.87 sys 1.925 I used the above config file, and did the following for each test: make depend && /usr/bin/time make -j n It doesn't look like I'm getting as much of a performance boost as Chuck did with two processors, (at -j 7, he was getting 2.3 times performance) could it be due to APIC_IO not being enabled? Anyway, thanks for any insight. Overall, though, thinks look good. I notice a difference when the 2nd cpu is active. :) Thanks, Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Tue Jan 14 22:13:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA10741 for smp-outgoing; Tue, 14 Jan 1997 22:13:48 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA10736 for ; Tue, 14 Jan 1997 22:13:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA01002; Tue, 14 Jan 1997 23:12:47 -0700 Message-Id: <199701150612.XAA01002@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: kmitch@weenix.guru.org (Keith Mitchell), smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Wed, 15 Jan 1997 00:26:33 EST." <199701150526.AAA25700@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jan 1997 23:12:47 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Well, I seem to have a similar problem. I too have a 3940UW, and >when I enabled APIC_IO, the kernel would hang right before it should have >gone to init. > ... >de0 rev 18 int a irq 10 on pci0:10 ^^^^^^ > ... >ahc1 rev 0 int a irq 10 on pci1:5 ^^^^^^ Note both the de0 and ahc1 using irq 10. I suspect this might be the problem. Try booting the SMP APIC_IO kernel without the de0 card installed. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Jan 14 22:26:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA11119 for smp-outgoing; Tue, 14 Jan 1997 22:26:49 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA11100 for ; Tue, 14 Jan 1997 22:25:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA01059 for ; Tue, 14 Jan 1997 23:21:55 -0700 Message-Id: <199701150621.XAA01059@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: smp@freebsd.org Subject: 3.0-970114-SNAP as starting point for SMP kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Jan 1997 23:21:55 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordon just announced availability of a 3.0-current SNAP. This would be a good starting point for those wanting to setup an SMP system. Please report any successes (or failures) with this SNAP for SMP. Details for getting from a SNAP to an SMP system are at: http://www.freebsd.org/~fsmp/SMP/getstarted.html ------- Forwarded Message Return-Path: owner-freebsd-announce@freefall.freebsd.org To: announce@freebsd.org Subject: 3.0-970114-SNAP is now available from ftp.freebsd.org Date: Tue, 14 Jan 1997 21:02:29 -0800 Message-ID: <17940.853304549@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-announce@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a short-term snapshot, and won't be released on CDROM (though it will be available on the FTPs site until the next "real" snapshot is available). This snapshot is intended primarily as a quick "sanity check" of 3.0-current and as a starting point resource for the SMP developers; there are no truly significant differences between -current and RELENG_2_2 at this time (hence the short term nature of this snapshot; just as soon as something truly significant happens in 3.0, another snapshot will be done to replace this one). To get it: ftp://ftp.freebsd.org/pub/FreeBSD/3.0-960114-SNAP/ contains all the usual bits. Also please note that the release documentation was NOT updated for this SNAP. Docs on the boot floppy will still reference "2.2 BETA" but everything is actually 3.0-current (and the uname command returns the right thing). Jordan ------- End of Forwarded Message From owner-freebsd-smp Tue Jan 14 23:15:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA12918 for smp-outgoing; Tue, 14 Jan 1997 23:15:53 -0800 (PST) Received: from avatar.avatar.com (avatar.avatar.com [199.33.206.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA12909 for ; Tue, 14 Jan 1997 23:15:50 -0800 (PST) Received: from avatar.avatar.com (kory@avatar.avatar.com [199.33.206.17]) by avatar.avatar.com (8.7.4/8.6.9) with SMTP id XAA09682; Tue, 14 Jan 1997 23:15:15 -0800 (PST) Date: Tue, 14 Jan 1997 23:15:14 -0800 (PST) From: Kory Hamzeh To: Steve Passe cc: smp@freebsd.org Subject: Re: 3.0-970114-SNAP as starting point for SMP kernel In-Reply-To: <199701150621.XAA01059@clem.systemsix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it possible to setup a system with two releases? I would like to try out the 3.0-SNAP for SMP support, but I would like to be able to boot my 2.1.5-RELEASE incase of trouble. Thanks, Kory On Tue, 14 Jan 1997, Steve Passe wrote: > Jordon just announced availability of a 3.0-current SNAP. > This would be a good starting point for those wanting to > setup an SMP system. Please report any successes (or failures) > with this SNAP for SMP. Details for getting from a SNAP > to an SMP system are at: > > http://www.freebsd.org/~fsmp/SMP/getstarted.html > > ------- Forwarded Message > > Return-Path: owner-freebsd-announce@freefall.freebsd.org > To: announce@freebsd.org > Subject: 3.0-970114-SNAP is now available from ftp.freebsd.org > Date: Tue, 14 Jan 1997 21:02:29 -0800 > Message-ID: <17940.853304549@time.cdrom.com> > From: "Jordan K. Hubbard" > Sender: owner-freebsd-announce@freebsd.org > X-Loop: FreeBSD.org > Precedence: bulk > > This is a short-term snapshot, and won't be released on CDROM (though > it will be available on the FTPs site until the next "real" snapshot > is available). > > This snapshot is intended primarily as a quick "sanity check" of > 3.0-current and as a starting point resource for the SMP developers; > there are no truly significant differences between -current and > RELENG_2_2 at this time (hence the short term nature of this snapshot; > just as soon as something truly significant happens in 3.0, another > snapshot will be done to replace this one). > > To get it: > > ftp://ftp.freebsd.org/pub/FreeBSD/3.0-960114-SNAP/ > > contains all the usual bits. > > Also please note that the release documentation was NOT updated for > this SNAP. Docs on the boot floppy will still reference "2.2 BETA" > but everything is actually 3.0-current (and the uname command returns > the right thing). > > Jordan > > ------- End of Forwarded Message > > From owner-freebsd-smp Wed Jan 15 05:44:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA02362 for smp-outgoing; Wed, 15 Jan 1997 05:44:45 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA02353; Wed, 15 Jan 1997 05:44:41 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id IAA00395; Wed, 15 Jan 1997 08:44:27 -0500 (EST) From: Keith Mitchell Message-Id: <199701151344.IAA00395@weenix.guru.org> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701150505.WAA00551@clem.systemsix.com> from Steve Passe at "Jan 14, 97 10:05:20 pm" To: smp@csn.net (Steve Passe) Date: Wed, 15 Jan 1997 08:44:27 -0500 (EST) Cc: hackers@freebsd.org, smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The "Freeing (NOT implimented) irq 9 for ISA cards." line is saying that > since the APIC_IO code is using the CORRECT PCI irq 19 to service the de0 > card, it SHOULD be "undirecting" the ISA irq 9 from it. The "NOT implimented" > part notes the fact that this code hasn't been written yet (because its > chipset dependant and I don't have all the info I need to support all > the possible chipsets yet). So we have a situation where the upper level > PCI code knows that 2 distinct IRQs are being used for de0 and ahc1 (19 & 9) > BUT the hardware is delivering INTs generated by the ahc1 via both the > ahc1 vector (irq 9) AND the de0 vector (irq 19). This could explain the > missing INTs as well as the "sometimes" locks. > > Test this theory by booting the APIC_IO SMP kernel with the de0 card removed > from the system. Note that with this card removed the BIOS will probably > re-assign the PCI INTs, possibly causing de1 to provoke the same problem, > remove it also for this test. In my system, I have the on-board IDE stuff disabled. I also have nothing on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have them marked for PCI/PNP use in my bios yet it still won't use them. After discovering this, I removed one of the ethernet cards like you suggested. The result was it was still sharing (IRQ 10 this time). It didn't use IRQ 9 at all. So then I removed the other ethernet card. Now nothing was sharing an IRQ but the kernel still failed in the same way (not passing control over to init). From owner-freebsd-smp Wed Jan 15 07:09:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA05708 for smp-outgoing; Wed, 15 Jan 1997 07:09:01 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA05701 for ; Wed, 15 Jan 1997 07:08:59 -0800 (PST) Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA22384; Wed, 15 Jan 1997 09:52:00 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA06980; Wed, 15 Jan 1997 09:51:54 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id KAA24754; Wed, 15 Jan 1997 10:59:14 GMT Message-Id: <199701151059.KAA24754@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Keith Mitchell Cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-Reply-To: Your message of "Tue, 14 Jan 1997 20:10:58 EST." <199701150110.UAA00835@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:59:14 +0000 From: Matt Thomas Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What is happening is a limitation of the PCI code. Each PCI slot has four interrupt lines (INTA .. INTD) and then are normally mapped into ISA IRQs. Since most PCI devices only use INTA, since means there is a simple one-to-one mapping. Introducing a PCI-PCI bridge means that INTB .. INTD will also be used. Devices behind the PPB get their INT lines rotated. This rotation is simple (take the device number, add it to the INTx, and AND with 3. 0=INTA 3=INTD). So ahc1 is using INTB and the PCI/APIC needs to how to map this INTB line into the APIC irq. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-smp Wed Jan 15 07:23:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA06292 for smp-outgoing; Wed, 15 Jan 1997 07:23:12 -0800 (PST) Received: from charon.finall.com (charon.finall.com [206.246.160.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA06286 for ; Wed, 15 Jan 1997 07:23:08 -0800 (PST) Received: from exchange.finall.com (exchange.finall.com [206.246.160.132]) by charon.finall.com (8.8.4/8.6.12) with SMTP id KAA09121 for ; Wed, 15 Jan 1997 10:23:05 -0500 (EST) Received: by exchange.finall.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC02CE.1B9242E0@exchange.finall.com>; Wed, 15 Jan 1997 10:23:10 -0500 Message-ID: From: "Jung, Michael" To: "'Keith Mitchell'" Cc: "'FreeBSD-SMP Mailing List'" Subject: RE: Adaptec 3940UW and SMP Date: Wed, 15 Jan 1997 10:23:08 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As a general note I know that some motherboards/systems use int 12/15 for powermanagment. Also, Int 12 is sometime used for on board bus-mice (AST Manhatten). --mikej >-----Original Message----- >From: Keith Mitchell [SMTP:kmitch@weenix.guru.org] >Sent: Wednesday, January 15, 1997 8:44 AM >To: smp@csn.net >Cc: hackers@freebsd.org; smp@freebsd.org >Subject: Re: Adaptec 3940UW and SMP > >> The "Freeing (NOT implimented) irq 9 for ISA cards." line is saying that >> since the APIC_IO code is using the CORRECT PCI irq 19 to service the de0 >> card, it SHOULD be "undirecting" the ISA irq 9 from it. The "NOT >>implimented" >> part notes the fact that this code hasn't been written yet (because its >> chipset dependant and I don't have all the info I need to support all >> the possible chipsets yet). So we have a situation where the upper level >> PCI code knows that 2 distinct IRQs are being used for de0 and ahc1 >>(19 & 9) >> BUT the hardware is delivering INTs generated by the ahc1 via both the >> ahc1 vector (irq 9) AND the de0 vector (irq 19). This could explain the >> missing INTs as well as the "sometimes" locks. >> >> Test this theory by booting the APIC_IO SMP kernel with the de0 card >>removed >> from the system. Note that with this card removed the BIOS will probably >> re-assign the PCI INTs, possibly causing de1 to provoke the same problem, >> remove it also for this test. > >In my system, I have the on-board IDE stuff disabled. I also have >nothing >on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have >them >marked for PCI/PNP use in my bios yet it still won't use them. > >After discovering this, I removed one of the ethernet cards like you >suggested. The result was it was still sharing (IRQ 10 this time). It >didn't >use IRQ 9 at all. So then I removed the other ethernet card. Now >nothing >was sharing an IRQ but the kernel still failed in the same way (not >passing >control over to init). > From owner-freebsd-smp Wed Jan 15 07:57:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA07980 for smp-outgoing; Wed, 15 Jan 1997 07:57:31 -0800 (PST) Received: from trapdoor.aracnet.com (root@trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA07975 for ; Wed, 15 Jan 1997 07:57:29 -0800 (PST) Received: from shelob.aracnet.com (shelob.aracnet.com [204.188.47.2]) by trapdoor.aracnet.com (8.7.4/8.6.9) with ESMTP id HAA18065; Wed, 15 Jan 1997 07:56:48 -0800 From: Chris Browning Recieved: by shelob.aracnet.com (8.7.4) id HAA03362; Wed, 15 Jan 1997 07:59:30 -0800 Message-Id: <199701151559.HAA03362@shelob.aracnet.com> Subject: Re: MP-1.4 spec To: smp@csn.net (Steve Passe) Date: Wed, 15 Jan 1997 07:59:30 -0800 (PST) Cc: chuckr@Glue.umd.edu, smp@freebsd.org In-Reply-To: <199701150513.WAA00636@clem.systemsix.com> from "Steve Passe" at Jan 14, 97 10:13:43 pm Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I was browsing the smp web page, seeing how I could contribute more, and I > > came across a reference to the mp-1.4 spec. the link was bad, could you > > either send me a good link for it, or maybe put the doc up for ftp > > somewhere? I want to read it, thanks. http://www.intel.com/design/pro/datashts/24201605.pdf Enjoy! Chris Disclaimer: I don't speak for anyone :-) From owner-freebsd-smp Wed Jan 15 08:46:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA10392 for smp-outgoing; Wed, 15 Jan 1997 08:46:32 -0800 (PST) Received: from tchnet.tchnet.com (tchnet.tchnet.com [198.109.196.2]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA10387 for ; Wed, 15 Jan 1997 08:46:29 -0800 (PST) Received: (from rnet@localhost) by tchnet.tchnet.com (8.6.12/8.6.9) id LAA25075; Wed, 15 Jan 1997 11:48:41 -0500 Date: Wed, 15 Jan 1997 11:48:41 -0500 (EST) From: "R. A. Nethercott" To: freebsd-smp@freebsd.org Subject: How? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am curious as to what I have to do to get dual processor support on my FreeBSD box. I currently have an ALR Dual P100 with 48M of RAM and I am using 2.1.0-release as my OS. If I have to upgrade to a newer version of BSD will I have to re-enter the passwd.db files? Also, where would I go to get the info that I would/will need to implement smp? Thank you for your time, Roy From owner-freebsd-smp Wed Jan 15 09:02:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA11055 for smp-outgoing; Wed, 15 Jan 1997 09:02:05 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA11048 for ; Wed, 15 Jan 1997 09:02:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA04351; Wed, 15 Jan 1997 10:00:45 -0700 Message-Id: <199701151700.KAA04351@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: Rob Schofield cc: freebsd-smp@freebsd.org Subject: Re: Motherboard & ChipSet pointers? In-reply-to: Your message of "Wed, 15 Jan 1997 12:57:01 +0700." <199701151157.MAA00873@mccomm.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:00:45 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > EISA should be avoided for SMP/technical reasons (which I have gone into > > in detail in the past). I highly recommend the Gigabyte GA586DX if > > you want a P5 system. P6 is an unknown to me. > > Steve, can you briefly re-hash these for me, or point me at a doc I > can look at? This is worrying as I have picked up an EISA-based server > expressly to run BSD! > > Any info gratefully received. Some EISA systems do not connect the system clock (8254) to the IO APIC.This requires "mixed-mode" programming the IO APIC AND the 8259 ICU. I have already written the code to do this and it appears to work. BUT this is a small in-efficiency for hard-clock INTs. So far ALL EISA systems I have seen use the ISA INTs 0-15 redirection capability for routing both EISA AND PCI INTs to the lower 16 ISA INT vectors. some (majority, but NOT all) PCI/ISA systems route the PCI INTs to upper (ie above 16) IO APIC INTs, thus giving you 4 or more extra INT vectors, helping greatly with the typical "not enough INT choices" on the ISA bus. this fact is the major reason I have for avoiding EISA boards. you need to go thru the mptable database to see details about what I am talking about here. -- 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----- From owner-freebsd-smp Wed Jan 15 09:12:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA11657 for smp-outgoing; Wed, 15 Jan 1997 09:12:02 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA11636 for ; Wed, 15 Jan 1997 09:11:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA04449; Wed, 15 Jan 1997 10:11:34 -0700 Message-Id: <199701151711.KAA04449@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: Keith Mitchell cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Wed, 15 Jan 1997 08:44:27 EST." <199701151344.IAA00395@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:11:34 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > In my system, I have the on-board IDE stuff disabled. I also have nothing > on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have them > marked for PCI/PNP use in my bios yet it still won't use them. 14 and 15 are sometimes internally routed from IDE controller to 8259 ICUs within the same piece of silicon (ie BOTH are on same chipset, the motherboard chipset) and the lines are NOT brought out of the chip. this means the MB manufacturer cannot use them on the ISA bus. Why 5 is a problem I have no theory. --- > After discovering this, I removed one of the ethernet cards like you > suggested. The result was it was still sharing (IRQ 10 this time). It didn't > use IRQ 9 at all. So then I removed the other ethernet card. Now nothing > was sharing an IRQ but the kernel still failed in the same way (not passing > control over to init). time for another theory... -- 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----- From owner-freebsd-smp Wed Jan 15 09:31:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA12472 for smp-outgoing; Wed, 15 Jan 1997 09:31:25 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA12466 for ; Wed, 15 Jan 1997 09:31:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA04577; Wed, 15 Jan 1997 10:30:35 -0700 Message-Id: <199701151730.KAA04577@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: "R. A. Nethercott" cc: freebsd-smp@freebsd.org Subject: Re: How? In-reply-to: Your message of "Wed, 15 Jan 1997 11:48:41 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:30:35 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > I am curious as to what I have to do to get dual processor support on my > FreeBSD box. I currently have an ALR Dual P100 with 48M of RAM and I am > using 2.1.0-release as my OS. If I have to upgrade to a newer version of > BSD will I have to re-enter the passwd.db files? Also, where would I go > to get the info that I would/will need to implement smp? start with: http://www.freebsd.org/~fsmp/SMP/SMP.html -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Jan 15 09:36:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA12737 for smp-outgoing; Wed, 15 Jan 1997 09:36:03 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA12714 for ; Wed, 15 Jan 1997 09:36:00 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA28664 for ; Wed, 15 Jan 1997 09:35:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA04604; Wed, 15 Jan 1997 10:33:11 -0700 Message-Id: <199701151733.KAA04604@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: Kory Hamzeh cc: smp@freebsd.org Subject: Re: 3.0-970114-SNAP as starting point for SMP kernel In-reply-to: Your message of "Tue, 14 Jan 1997 23:15:14 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:33:11 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >Is it possible to setup a system with two releases? I would like to try >out the 3.0-SNAP for SMP support, but I would like to be able to boot my >2.1.5-RELEASE incase of trouble. I think that the differences are great enough that you would have to handle them as two different OSes, ie. different partitions, etc. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Jan 15 09:36:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA12783 for smp-outgoing; Wed, 15 Jan 1997 09:36:43 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA12748 for ; Wed, 15 Jan 1997 09:36:16 -0800 (PST) Received: from clem.systemsix.com by mail.crl.com with SMTP id AA17953 (5.65c/IDA-1.5 for ); Wed, 15 Jan 1997 09:35:53 -0800 Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA04559; Wed, 15 Jan 1997 10:28:55 -0700 Message-Id: <199701151728.KAA04559@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: Matt Thomas Cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-Reply-To: Your message of "Wed, 15 Jan 1997 10:59:14 GMT." <199701151059.KAA24754@whydos.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 10:28:55 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > What is happening is a limitation of the PCI code. Each PCI slot has > four interrupt lines (INTA .. INTD) and then are normally mapped into > ISA IRQs. Since most PCI devices only use INTA, since means there is > a simple one-to-one mapping. > > Introducing a PCI-PCI bridge means that INTB .. INTD will also be used. > Devices behind the PPB get their INT lines rotated. This rotation is > simple (take the device number, add it to the INTx, and AND with 3. > 0=INTA 3=INTD). So ahc1 is using INTB and the PCI/APIC needs to how > to map this INTB line into the APIC irq. I don't get to map anything, the MB manufacturer does that, I can only read the MP table and use what it gives me. The MP table in question shows no mapping for the ahc0/1 so they remain redirected thru the ISA bus. Ie, I am expecting them to appear on the same vector levels on the APIC as they appear on the 8259s. Could you expand on how the INTA/B/C/D lines are handled when redirected via the ISA bus? Specifically, how does the ahc1 INTB line get tied to the ISA INT line in a normal setup? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Jan 15 10:38:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA16217 for smp-outgoing; Wed, 15 Jan 1997 10:38:23 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA16208 for ; Wed, 15 Jan 1997 10:38:15 -0800 (PST) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [206.54.227.6]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA28713 for ; Wed, 15 Jan 1997 10:15:26 -0800 (PST) Received: from arabian.sylvester.com (alectrosaurus.execpc.com [169.207.14.19]) by atlantis.nconnect.net (8.8.4/8.7.3) with SMTP id MAA01684; Wed, 15 Jan 1997 12:10:31 -0600 (CST) Message-ID: <32DD1F33.41C67EA6@nconned.net> Date: Wed, 15 Jan 1997 12:17:23 -0600 From: Randy DuCharme X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: "R. A. Nethercott" CC: freebsd-smp@freebsd.org Subject: Re: How? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk R. A. Nethercott wrote: > > I am curious as to what I have to do to get dual processor support on my > FreeBSD box. I currently have an ALR Dual P100 with 48M of RAM and I am > using 2.1.0-release as my OS. If I have to upgrade to a newer version of > BSD will I have to re-enter the passwd.db files? Also, where would I go > to get the info that I would/will need to implement smp? > > Thank you for your time, > > Roy -- Roy, See http://www.freebsd.org/~fsmp/SMP/SMP.html or http://www.freebsd.org/~fsmp/SMP/getstarted.html I had to make on other modifications to my system when I upgraded. I went from 2.1.5 to 2.2SNAP, to -Current/SMP. Enjoy Randy From owner-freebsd-smp Wed Jan 15 11:06:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA17565 for smp-outgoing; Wed, 15 Jan 1997 11:06:47 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA17358 for ; Wed, 15 Jan 1997 11:03:32 -0800 (PST) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA11215; Wed, 15 Jan 1997 13:50:32 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08690; Wed, 15 Jan 1997 13:50:30 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id OAA26586; Wed, 15 Jan 1997 14:57:51 GMT Message-Id: <199701151457.OAA26586@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Steve Passe Cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-Reply-To: Your message of "Wed, 15 Jan 1997 10:28:55 MST." <199701151728.KAA04559@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 14:57:48 +0000 From: Matt Thomas Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > What is happening is a limitation of the PCI code. Each PCI slot has > > four interrupt lines (INTA .. INTD) and then are normally mapped into > > ISA IRQs. Since most PCI devices only use INTA, since means there is > > a simple one-to-one mapping. > > > > Introducing a PCI-PCI bridge means that INTB .. INTD will also be used. > > Devices behind the PPB get their INT lines rotated. This rotation is > > simple (take the device number, add it to the INTx, and AND with 3. > > 0=INTA 3=INTD). So ahc1 is using INTB and the PCI/APIC needs to how > > to map this INTB line into the APIC irq. > > I don't get to map anything, the MB manufacturer does that, I can only read > the MP table and use what it gives me. The MP table in question shows > no mapping for the ahc0/1 so they remain redirected thru the ISA bus. > Ie, I am expecting them to appear on the same vector levels on the APIC > as they appear on the 8259s. Could you expand on how the INTA/B/C/D > lines are handled when redirected via the ISA bus? Specifically, how > does the ahc1 INTB line get tied to the ISA INT line in a normal setup? What needs to be done is to call the PCI BIOS funtion to get the IRQ mapping. However, we don't use the PCI BIOS. I would expect the MP table to show a mapping between a PCI slot and its INT[A-D] lines to the APIC. So while the MP table doesn't have an entry for the ahc0/ahc1, it should have an entry for the PCI-PCI Bridge. Using that information, you can map the INTA line of ahc0 to INTA of ppb0 and INTA of ahc0 to INTB of ppb0. Traditionally, ahc1 INTA gets to an ISA INT by POST processing of the BIOS and the IRQ gets written into the one of the configuration registers of the device. The PCI code reads this register and uses the value; it does no setup since that was done by the BIOS. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-smp Wed Jan 15 11:21:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA18359 for smp-outgoing; Wed, 15 Jan 1997 11:21:01 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA18352; Wed, 15 Jan 1997 11:20:52 -0800 (PST) Received: from schizo.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vkasn-0003yOC; Wed, 15 Jan 97 11:20 PST Received: from critter.dk.tfs.com (critter-home [193.162.32.19]) by schizo.dk.tfs.com (8.8.2/8.7.3) with ESMTP id UAA00710; Wed, 15 Jan 1997 20:20:18 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id UAA28170; Wed, 15 Jan 1997 20:14:39 +0100 (MET) To: Bruce Evans cc: smp@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_bio.c src/sys/vm vm_glue.c vm_pageout.c In-reply-to: Your message of "Wed, 15 Jan 1997 11:05:09 PST." <199701151905.LAA17478@freefall.freebsd.org> Date: Wed, 15 Jan 1997 20:14:39 +0100 Message-ID: <28168.853355679@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701151905.LAA17478@freefall.freebsd.org>, Bruce Evans writes: >bde 97/01/15 11:05:09 > > Modified: sys/kern vfs_bio.c > sys/vm vm_glue.c vm_pageout.c > Log: > Removed redundant spl0()'s from kernel processes. They were work-arounds > for a bug in fork(). Thanks Bruce, I spent much time trying to understand why the &$^$ they were there... Peter, this is probably what foiled your intial attempt to get rid of the idle-procs... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Wed Jan 15 11:51:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA19911 for smp-outgoing; Wed, 15 Jan 1997 11:51:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA19785 for ; Wed, 15 Jan 1997 11:48:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04142; Wed, 15 Jan 1997 12:34:06 -0700 From: Terry Lambert Message-Id: <199701151934.MAA04142@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: mikej@finall.com (Jung, Michael) Date: Wed, 15 Jan 1997 12:34:05 -0700 (MST) Cc: kmitch@weenix.guru.org, smp@freebsd.org In-Reply-To: from "Jung, Michael" at Jan 15, 97 10:23:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As a general note I know that some motherboards/systems > use int 12/15 for powermanagment. Also, Int 12 is sometime used > for on board bus-mice (AST Manhatten). As an aside, Win95 device autoconfiguration will not see the INT 12 usage when you have PNP cards, and will stomp on it. It may be that there isn't a way to safely probe the thing, and it's not the OS's fault... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jan 15 11:55:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA20119 for smp-outgoing; Wed, 15 Jan 1997 11:55:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA20108 for ; Wed, 15 Jan 1997 11:55:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04161; Wed, 15 Jan 1997 12:41:56 -0700 From: Terry Lambert Message-Id: <199701151941.MAA04161@phaeton.artisoft.com> Subject: Re: 3.0-970114-SNAP as starting point for SMP kernel To: smp@csn.net (Steve Passe) Date: Wed, 15 Jan 1997 12:41:56 -0700 (MST) Cc: kory@avatar.com, smp@freebsd.org In-Reply-To: <199701151733.KAA04604@clem.systemsix.com> from "Steve Passe" at Jan 15, 97 10:33:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Is it possible to setup a system with two releases? I would like to try > >out the 3.0-SNAP for SMP support, but I would like to be able to boot my > >2.1.5-RELEASE incase of trouble. > > I think that the differences are great enough that you would have to handle > them as two different OSes, ie. different partitions, etc. Yes. All of the utilities that operate on the kernel memory image (ps and so on) are not sufficiently abstracted through procfs to let them be usable across proc structure changes. The utmp/wtmp record size recently changed, and the change would be in the snapshot. Therefore the utmp/wtmp file would not interoperate between version (who, w, and so on would fail). There are many additional changes similar in scope. Fixing most of these means abstracting the interfaces; this would still fail backward compatability, but *would* guarantee forward compatability across future developement, so it's worth pursuing. Fully abstracting some of the tools (like ps) to operate on data-statites like procfs, means that the tools would no longer be usable against, for instance kernel dump images (kernel dump images can't run FS code to respond to abstract I/O requests). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jan 15 12:47:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA23908 for smp-outgoing; Wed, 15 Jan 1997 12:47:10 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA23903 for ; Wed, 15 Jan 1997 12:47:08 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA28948 for ; Wed, 15 Jan 1997 12:44:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA05550; Wed, 15 Jan 1997 13:37:11 -0700 Message-Id: <199701152037.NAA05550@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: Matt Thomas cc: Keith Mitchell , Kenneth Merry , se@zpr.uni-koeln.de (Stefan Esser), smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Wed, 15 Jan 1997 14:57:48 GMT." <199701151457.OAA26586@whydos.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 13:37:11 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I added STefan to the list as he is the PCI guru. STefan, we are going after the failure of 3940s and the SMP/APIC IO kernel. > What needs to be done is to call the PCI BIOS funtion to get the IRQ > mapping. However, we don't use the PCI BIOS. > > I would expect the MP table to show a mapping between a PCI slot and its > INT[A-D] lines to the APIC. So while the MP table doesn't have an entry > for the ahc0/ahc1, it should have an entry for the PCI-PCI Bridge. Using > that information, you can map the INTA line of ahc0 to INTA of ppb0 and > INTA of ahc0 to INTB of ppb0. not exactly, the details: we have two different style systems failing with the 3940. I'll call them system #1 & #2. you might want to read the MP spec, v1.4, appendix D.3 for details on how PCI/APIC irqs are parsed: http://www.intel.com/design/pro/datashts/242016.htm --- system #1, Tomcat III MB, Keith Mitchell : MP table (abbreviated): Bus: Bus ID Type 0 ISA 1 PCI I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ... INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 ... INT active-lo level 1 20:A 2 16 INT active-lo level 1 19:A 2 17 INT active-lo level 1 18:A 2 18 INT active-lo level 1 17:A 2 19 dmesg output (abbreviated): de0 rev 35 int a irq 19 on pci0:17 Freeing (NOT implimented) irq 9 for ISA cards. ... de1 rev 35 int a irq 16 on pci0:20 Freeing (NOT implimented) irq 11 for ISA cards. ... ahc0 rev 0 int a irq 10 on pci1:4 ... ahc1 rev 0 int a irq 9 on pci1:5 - in the above table PCI bus 0, device 17, irq A is associated with APIC INT 19, in the above table PCI bus 0, device 20, irq A is associated with APIC INT 16, there are no listed associations for bus 1, device[4|5], irq[A|B|C|D] the code uses the upper APIC irqs (16 & 19) for the de devices upon finding them in the MP table. It uses the existing ISA irqs (9 & 10) for the ahc devices since there was nothing remapping them in the MP table. Keith has since reported: >In my system, I have the on-board IDE stuff disabled. I also have nothing >on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have them >marked for PCI/PNP use in my bios yet it still won't use them. > >After discovering this, I removed one of the ethernet cards like you >suggested. The result was it was still sharing (IRQ 10 this time). It didn't >use IRQ 9 at all. So then I removed the other ethernet card. Now nothing >was sharing an IRQ but the kernel still failed in the same way (not passing >control over to init). Keith, could you mail me the boot output for this test (no de device)? --- system #2, ASUS P/I-P65UP5 w/ C-P6ND cpu card, Kenneth Merry : MP table (abbreviated): Bus: Bus ID Type 0 PCI 1 PCI 2 ISA I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ... INT conforms conforms 2 8 2 8 [ NOTE: MP table is missing 9,10,11 from ISA bus listings! ] INT conforms conforms 2 12 2 12 ... INT active-lo level 2 11 2 17 INT active-lo level 2 10 2 18 INT active-lo level 2 9 2 19 dmesg output (abbreviated): de0 rev 18 int a irq 10 on pci0:10 ahc0 rev 0 int a irq 11 on pci1:4 ahc1 rev 0 int a irq 10 on pci1:5 - IMHO, in the above MP table the PCI irqs are not properly declared, according to the rules of 1.4, app. D.3. They are listed as being on the ISA bus, NOT the PCI. The software may or may not be tripping over this. Kenneth, is there a section in your BIOS allowing you to pick the MP spec revision? This behaviour was a "feature" of the original spec, and thus the reason app. D.3 came into being. I seem to remember another system with this same problem (maybe even an ASUS if I remember right...). If possible choose the 1.4 revision, this should change this behaviour. Then try booting the APIC SMP kernel without the de card installed. --- > > Traditionally, ahc1 INTA gets to an ISA INT by POST processing of the BIOS > and the IRQ gets written into the one of the configuration registers of the > device. The PCI code reads this register and uses the value; it does no > setup since that was done by the BIOS. so I assumme this is done by the ahc specific BIOS. I need a little more detail here, please. you said previously that the ahc1 would use INTB. does the PCI INT from ahc1 go to the PCI INTA line or the INTB line? how are the 4 PCI INT lines steered to the one ISA INT line? specifically, are all 4 PCI lines tied to the one ISA line?, or will the BIOS attach the ahc1 INTB line to the ISA INT, ignoring the others as it knows there are unused in this specific case? I'm beginning to wonder if we are fighting a generic "failing" in the MP spec as applies to bridged PCI devices? Is anyone successfully using a bridged PCI device with SMP & APIC_IO? I know all the above can be quite confusing, feel free to ask questions. A big part of the problem here is that the spec can be pretty vague in some areas! I know there is alot I still don't grok... -- 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----- From owner-freebsd-smp Wed Jan 15 13:48:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA28211 for smp-outgoing; Wed, 15 Jan 1997 13:48:05 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA28104 for ; Wed, 15 Jan 1997 13:47:50 -0800 (PST) Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA07067; Wed, 15 Jan 1997 16:34:42 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09851; Wed, 15 Jan 1997 16:34:40 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id RAA27756; Wed, 15 Jan 1997 17:41:59 GMT Message-Id: <199701151741.RAA27756@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Steve Passe Cc: Keith Mitchell , Kenneth Merry , se@zpr.uni-koeln.de (Stefan Esser), smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-Reply-To: Your message of "Wed, 15 Jan 1997 13:37:11 MST." <199701152037.NAA05550@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 17:41:57 +0000 From: Matt Thomas Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi, > > I added STefan to the list as he is the PCI guru. STefan, we are going > after the failure of 3940s and the SMP/APIC IO kernel. > > > What needs to be done is to call the PCI BIOS funtion to get the IRQ > > mapping. However, we don't use the PCI BIOS. > > > > I would expect the MP table to show a mapping between a PCI slot and its > > INT[A-D] lines to the APIC. So while the MP table doesn't have an entry > > for the ahc0/ahc1, it should have an entry for the PCI-PCI Bridge. Using > > that information, you can map the INTA line of ahc0 to INTA of ppb0 and > > INTA of ahc0 to INTB of ppb0. > > > > > Traditionally, ahc1 INTA gets to an ISA INT by POST processing of the BIOS > > and the IRQ gets written into the one of the configuration registers of the > > device. The PCI code reads this register and uses the value; it does no > > setup since that was done by the BIOS. > > so I assumme this is done by the ahc specific BIOS. I need a little more > detail here, please. you said previously that the ahc1 would use INTB. does > the PCI INT from ahc1 go to the PCI INTA line or the INTB line? how are the > 4 PCI INT lines steered to the one ISA INT line? specifically, are all 4 > PCI lines tied to the one ISA line?, or will the BIOS attach the ahc1 INTB line > to the ISA INT, ignoring the others as it knows there are unused in this > specific case? The INTA line for ahc1 gets mapped by the PPB into INTB on the side closest to the CPU. If there was another PPB, the INTB would then get mapped again (depending on the PPBs device number), until finally you arrive at bus 0. The way INT lines are tied to IRQs is completely dependent on the motherboard and the BIOS. The only reliable way to get this information to call the PCI BIOS and get the IRQ mapping. No, the ahc BIOS is completely unaware of this. This is done by the system BIOS. > I'm beginning to wonder if we are fighting a generic "failing" in the MP > spec as applies to bridged PCI devices? Is anyone successfully using a > bridged PCI device with SMP & APIC_IO? I know all the above can be quite > confusing, feel free to ask questions. A big part of the problem here > is that the spec can be pretty vague in some areas! I know there is alot > I still don't grok... I see nothing confusing. You need to backtrack to the first PPB, find its device number, map the device to the appropriate INT line, look up it's mapping in the MP table, and configure it. I was somewhat suprised to not see entires for INTB/C/D (are you not looking for them or are they not present?). -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-smp Wed Jan 15 14:42:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA03264 for smp-outgoing; Wed, 15 Jan 1997 14:42:28 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA03259 for ; Wed, 15 Jan 1997 14:42:26 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id OAA29191 for ; Wed, 15 Jan 1997 14:42:11 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id PAA27712; Wed, 15 Jan 1997 15:40:08 -0700 (MST) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id PAA01822; Wed, 15 Jan 1997 15:40:06 -0700 Date: Wed, 15 Jan 1997 15:40:06 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199701152240.PAA01822@fast.cs.utah.edu> To: matt@lkg.dec.com, smp@csn.net Subject: Re: Adaptec 3940UW and SMP Cc: ken@housing1.stucen.gatech.edu, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --- system #1, Tomcat III MB, Keith Mitchell : MP table (abbreviated): Bus: Bus ID Type 0 ISA 1 PCI I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ... INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 ... INT active-lo level 1 20:A 2 16 INT active-lo level 1 19:A 2 17 INT active-lo level 1 18:A 2 18 INT active-lo level 1 17:A 2 19 dmesg output (abbreviated): de0 rev 35 int a irq 19 on pci0:17 Freeing (NOT implimented) irq 9 for ISA cards. ... de1 rev 35 int a irq 16 on pci0:20 Freeing (NOT implimented) irq 11 for ISA cards. ... ahc0 rev 0 int a irq 10 on pci1:4 ... ahc1 rev 0 int a irq 9 on pci1:5 - >In my system, I have the on-board IDE stuff disabled. I also have nothing >on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have them >marked for PCI/PNP use in my bios yet it still won't use them. Okay, I am guessing, but I am assuming that the wires are hard-wired... So, ahc0 should be on IRQ xx, where xx corresponds to the slot the PPB is in. (Which slot is the Adaptec controller in? The first device should have that IRQ). ach1 should have IRQ 19, as PCI irq 9 is mapped to IRQ 19. Shared with de0. --- system #2, ASUS P/I-P65UP5 w/ C-P6ND cpu card, Kenneth Merry : MP table (abbreviated): Bus: Bus ID Type 0 PCI 1 PCI 2 ISA I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ... INT conforms conforms 2 8 2 8 [ NOTE: MP table is missing 9,10,11 from ISA bus listings! ] INT conforms conforms 2 12 2 12 ... INT active-lo level 2 11 2 17 INT active-lo level 2 10 2 18 INT active-lo level 2 9 2 19 dmesg output (abbreviated): de0 rev 18 int a irq 10 on pci0:10 ahc0 rev 0 int a irq 11 on pci1:4 ahc1 rev 0 int a irq 10 on pci1:5 Again, what slot on Bus 0 is the PPB on? That will give you int A. Int B will be hard to tell where it is mapped, unless the IRQ is shared with annother device, giving half of the answer... ahc0 : IRQ xx ahc1 : IRQ 18 (10 mapped to 18) This should be correct (I'm guessing) since PCI only has 4 IRQs, no matter how they are mapped. Print out the slot number for the PPB chip, and use that for the first device on Bus 1 (or whatever). Again, I agree: mapping IRQs behind bridges does seem tricky. Of course, mapping anything but INT A will give you the same problems! They really should be in the table... Kevin From owner-freebsd-smp Wed Jan 15 15:17:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA05154 for smp-outgoing; Wed, 15 Jan 1997 15:17:59 -0800 (PST) Received: from tis-mail.thepoint.net (tis-backup.thepoint.net [198.6.9.55]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA05146 for ; Wed, 15 Jan 1997 15:17:52 -0800 (PST) Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC0310.671C76D0@tis-mail.thepoint.net>; Wed, 15 Jan 1997 18:17:44 -0500 Message-ID: From: Arlie Davis To: "'Steve Passe'" , "'Keith Mitchell'" Cc: "'smp@freebsd.org'" Subject: RE: Adaptec 3940UW and SMP Date: Wed, 15 Jan 1997 18:17:42 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's time for me to join the fray on this one. We have seven servers, all identical. Each has a dual Pentium ASUS EISA/PCI motherboard (P54NP4, I think). Each server came with a 3c595 Fast Ethernet card and an Adaptec 3940 (dual-chain, but not wide). Each server runs Windows NT 3.51 (some 4.0 now). I had endless problems with these machines until I figured one thing out: The Adaptec 3940 BIOS (or perhaps the native system PCI BIOS) kind of "steals" IRQs from adjacent slots. These machines have Award BIOS. You must manually configure the IRQ for each slot. For example, if the PCI slots looked like this: slot IRQ device 1 5 Adaptec 3940 2 10 3Com 595 3 11 video card 4 15 empty then when the system booted, the 3940 would have allocated IRQs 5 AND 10 to itself. (If the 3940 were in slot four, it would steal the IRQ from slot 1.) No matter what slot I put the 3940 in, it steals the IRQ from the next slot. What's the use of a dual-channel card when I have to leave one PCI slot next to it empty?!?! This is really infuriating. Perhaps on a PCI/ISA PNP system, it would automatically be assigned two unused IRQs, but this never happened on my systems. So, just for fun, make sure that the slots around the 3940 are empty. Try the one above, then the one below, and see if your problems go away, or at least abate. If anyone has anything enlightening to say about this subject, I would love to know. I would especially like to know how to run the 3940s in my systems in such a way that I can still use the other slots. -- arlie P.S. The ASUS motherboard has neither on-board IDE, serial, nor parallel ports. The only thing on it is a mouse-port, hard-wired to IRQ 12. >-----Original Message----- >From: Steve Passe [SMTP:smp@csn.net] >Sent: Wednesday, January 15, 1997 12:12 PM >To: Keith Mitchell >Cc: smp@freebsd.org >Subject: Re: Adaptec 3940UW and SMP > >Hi, > >> In my system, I have the on-board IDE stuff disabled. I also have nothing >> on IRQ 5. Which leaves IRQs: 5, 14, and 15 totally unused. I have them >> marked for PCI/PNP use in my bios yet it still won't use them. >14 and 15 are sometimes internally routed from IDE controller to 8259 ICUs >within the same piece of silicon (ie BOTH are on same chipset, the >motherboard chipset) and the lines are NOT brought out of the chip. this >means the MB manufacturer cannot use them on the ISA bus. Why 5 is a problem >I have no theory. > >--- >> After discovering this, I removed one of the ethernet cards like you >> suggested. The result was it was still sharing (IRQ 10 this time). It >>didn't >> use IRQ 9 at all. So then I removed the other ethernet card. Now nothing >> was sharing an IRQ but the kernel still failed in the same way (not passing >> control over to init). > >time for another theory... > >-- >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----- > From owner-freebsd-smp Wed Jan 15 15:34:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA06661 for smp-outgoing; Wed, 15 Jan 1997 15:34:18 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA06485 for ; Wed, 15 Jan 1997 15:30:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA04843; Wed, 15 Jan 1997 16:09:40 -0700 From: Terry Lambert Message-Id: <199701152309.QAA04843@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Date: Wed, 15 Jan 1997 16:09:40 -0700 (MST) Cc: matt@lkg.dec.com, smp@csn.net, ken@housing1.stucen.gatech.edu, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org In-Reply-To: <199701152240.PAA01822@fast.cs.utah.edu> from "Kevin Van Maren" at Jan 15, 97 03:40:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Again, I agree: mapping IRQs behind bridges does seem tricky. Of course, > mapping anything but INT A will give you the same problems! They really > should be in the table... ...uh, how could they be? This would require his BIOS ROM to know about the Adaptec card plugged into the machine! As someone already pointed out, the PCI-PCI bridge chip identified itself, and should have been seen as INTB due to the PCI 1.0 bridge specification (1.0 is old -- April 5, 1994 -- anyone have a newer one from the PCI SIG that disagrees with mine?). Contact: PCI Spcial Interest Group M/S JFS-51 5200 N.E. Elam Young Parkway Hillsboro, Oregon 97124-6497 (503)696-6111 For current PCI specifications and materials... The real problem is that you really need a bridge-specific driver to be able to ask the bridge chipset itself. Nevertheless, knowing there is a bridge there, you should know INT B will be used from examining the posted MPtable stuff... I think Steve said that code wasn't written? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jan 15 16:08:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA08392 for smp-outgoing; Wed, 15 Jan 1997 16:08:39 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA08382 for ; Wed, 15 Jan 1997 16:08:36 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id RAA00175; Wed, 15 Jan 1997 17:08:00 -0700 (MST) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id RAA08453; Wed, 15 Jan 1997 17:07:57 -0700 Date: Wed, 15 Jan 1997 17:07:57 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199701160007.RAA08453@fast.cs.utah.edu> To: arlie@thepoint.net, kmitch@weenix.guru.org, smp@csn.net Subject: RE: Adaptec 3940UW and SMP Cc: smp@freebsd.org Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, PCI allows shared IRQs... The card shares with the one next to is as "normal" mappings would be: Slot 1: a->1 b->2 c->3 d->4 Slot 2: a->2 b->3 c->4 d->1 Slot 3: a->3 b->4 c->1 d->2 Slot 4: a->4 b->1 c->2 d->3 Of course your mileage may vary...and I've (personally) never seen a device that uses int C or D (maybe quad ethernet cards?) The 3940 uses two ints (A&B) as it has two devices that get mapped to those IRQs. Kevin From owner-freebsd-smp Wed Jan 15 16:41:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA10657 for smp-outgoing; Wed, 15 Jan 1997 16:41:33 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA10622 for ; Wed, 15 Jan 1997 16:41:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA06883; Wed, 15 Jan 1997 17:38:29 -0700 Message-Id: <199701160038.RAA06883@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: Matt Thomas cc: Keith Mitchell , Kenneth Merry , se@zpr.uni-koeln.de (Stefan Esser), smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Wed, 15 Jan 1997 17:41:57 GMT." <199701151741.RAA27756@whydos.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 17:38:28 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I see nothing confusing. You need to backtrack to the first PPB, find its this step of "backtrack"ing is unclear, could you expand? remember that during boot I dont have the benefit of the complete dmesg output that we are analyzing here. The PCI code calls me, it looks like: airq = get_pci_apic_irq (bus_no, device, pciint); if (airq != 0xff) { /* APIC IRQ exists */ rirq = irq; /* 're-directed' IRQ */ irq = airq; /* use APIC IRQ */ } so for: ahc1 rev 0 int a irq 9 on pci1:5 I get: airq = get_pci_apic_irq (1, 5, 0); which is going to map to NOTHING at that point in time. --- >device number, map the device to the appropriate INT line, look up it's >mapping in the MP table, and configure it. this I understand, and could code once the above "backtrack" is understood. > I was somewhat suprised to not see entires for INTB/C/D (are you not >looking for them or are they not present?). they are NOT present. for a variety of MP tables check out: http://www.freebsd.org/~fsmp/SMP/SMP.html/mptable/mptable.html I placed the 2 systems we are discussing in there as #22 & #23 --- so previously the PCI code saw the bridge when it printed: chip3 rev 2 on pci0:18 Freeing (NOT implimented) irq 9 for ISA cards. bridge from pci0 to pci1 through 1. the "Freeing" line is from my code and implies that the PCI code registered an INT for the bridge, the MP table would have mapped pci0:18 to APIC irq 18. so now the bridge is serviced via INT 18, so does this mean that the ahc1 ints go thru there? does it even make sence to register an INT for a bridge, could this be part of the problem? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Jan 15 17:52:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA16828 for smp-outgoing; Wed, 15 Jan 1997 17:52:51 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA16817 for ; Wed, 15 Jan 1997 17:52:49 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id UAA06971; Wed, 15 Jan 1997 20:49:21 -0500 (EST) From: Kenneth Merry Message-Id: <199701160149.UAA06971@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701152037.NAA05550@clem.systemsix.com> from Steve Passe at "Jan 15, 97 01:37:11 pm" To: smp@csn.net (Steve Passe) Date: Wed, 15 Jan 1997 20:49:20 -0500 (EST) Cc: matt@lkg.dec.com, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > system #2, ASUS P/I-P65UP5 w/ C-P6ND cpu card, > Kenneth Merry : > > MP table (abbreviated): > Bus: Bus ID Type > 0 PCI > 1 PCI > 2 ISA > > I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > ... > INT conforms conforms 2 8 2 8 > [ NOTE: MP table is missing 9,10,11 from ISA bus listings! ] > INT conforms conforms 2 12 2 12 > ... > INT active-lo level 2 11 2 17 > INT active-lo level 2 10 2 18 > INT active-lo level 2 9 2 19 > > dmesg output (abbreviated): > > de0 rev 18 int a irq 10 on pci0:10 > ahc0 rev 0 int a irq 11 on pci1:4 > ahc1 rev 0 int a irq 10 on pci1:5 > > - > IMHO, in the above MP table the PCI irqs are not properly > declared, according to the rules of 1.4, app. D.3. They are listed as being > on the ISA bus, NOT the PCI. The software may or may not be tripping over > this. > > Kenneth, is there a section in your BIOS allowing you to pick the MP spec > revision? This behaviour was a "feature" of the original spec, and thus the > reason app. D.3 came into being. I seem to remember another system with > this same problem (maybe even an ASUS if I remember right...). If possible > choose the 1.4 revision, this should change this behaviour. Then try booting > the APIC SMP kernel without the de card installed. Sorry I took so long to get back on this. In a nutshell, this is what I have figured out: standard SMP kernel APIC_IO SMP kernel de0 in, MP v1.1 enabled works hangs right before init de0 in, MP v1.4 enabled hangs hangs de0 out, MP v1.4 enabled works works initially, X crashes it So yes, my bios does have a feature that allows it to switch between MP 1.1 and 1.4. With the SMC card in, both the standard SMP kernel and the APIC_IO SMP kernel hang a couple of lines after the boot prompt. The APIC_IO kernel does work if the SMC card is out, but if I start X (running Accelerated X 2.1) the machine hangs (this is with either one or both processors running, tried it both ways). Or at least the console hangs. Since there wasn't a net card in, I couldn't see whether the whole machine was hung. I was able to get dmesg (truncated due to the limited size of the kernel message buffer, I guess) and mptable output for the APIC_IO kernel with the machine running with MP v1.4 enabled. Here is the dmesg: (hope nothing really important was at the very beginning) ======================================================================== ,MTRR,PGE,MCA,CMOV> real memory = 134217728 (131072K bytes) avail memory = 129380352 (126348K bytes) DEVFS: ready for devices pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12378086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 mapreg[20] type=1 addr=0000e800 size=0010. chip3 rev 2 on pci0:11 bridge from pci0 to pci1 through 1. mapping regs: io:2280d0d0 mem:fae0f980 pmem:fbf0fbf0 vga0 rev 1 int a irq 19 on pci0:13 Freeing (NOT implimented) irq 9 for ISA cards. mapreg[10] type=0 addr=f9000000 size=4000. mapreg[14] type=0 addr=fb000000 size=800000. pci0: uses 8404992 bytes of memory from f9000000 upto fbffffff. pci0: uses 16 bytes of I/O space from d000 upto e80f. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 17 on pci1:4 Freeing (NOT implimented) irq 11 for ISA cards. mapreg[10] type=1 addr=0000d800 size=0100. [pci1 uses memory from f9800000 to faefffff] mapreg[14] type=0 addr=fa000000 size=1000. reg20: virtual=0xf9893000 physical=0xfa000000 size=0x1000 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "QUANTUM XP34550W LXQ1" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4341MB (8890760 512 byte sectors) sd0(ahc0:0:0): with 5899 cyls, 10 heads, and an average 150 sectors/track ahc1 rev 0 int a irq 18 on pci1:5 Freeing (NOT implimented) irq 10 for ISA cards. mapreg[10] type=1 addr=0000d400 size=0100. [pci1 uses memory from f9800000 to faefffff] mapreg[14] type=0 addr=f9800000 size=1000. reg20: virtual=0xf9894000 physical=0xf9800000 size=0x1000 ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 4 synchronous at 10.0MHz, offset = 0xf (ahc1:4:0): "PLEXTOR CD-ROM PX-12CS 1.00" type 5 removable SCSI 2 cd0(ahc1:4:0): CD-ROM can't get the size pci1: uses 8192 bytes of memory from f9800000 upto fa000fff. pci1: uses 512 bytes of I/O space from d400 upto d8ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached lpt1 not found at 0xffffffff psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0060040, tty f000009a, net f000009a BIOS Geometries: 0:0228fe3f 0..552=553 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. DEVFS: ready to run Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 17, 18, imen: 0x00f9fe21 bpf: tun0 attached bpf: tun1 attached bpf: tun2 attached bpf: sl0 attached bpf: lo0 attached IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry sd0s1: type 0x7, start 63, end = 2040254, size 2040192 : OK sd0s2: type 0xa5, start 2040255, end = 8883944, size 6843690 : OK WARNING: / was not properly dismounted. SMP: All idle procs online. ======================================================================== And here is the mptable -verbose -dmesg output: =============================================================================== MPTable, version 2.0.5 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f60b0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f60b0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x8b mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f5caa signature: 'PCMP' base table length: 252 version: 1.4 checksum: 0x9d OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 1 7 0xfbff 0 0x11 AP, usable 6 1 7 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 0 2 2 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 5 2 5 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT conforms conforms 2 8 2 8 INT conforms conforms 2 12 2 12 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT active-lo level 1 4:A 2 17 INT active-lo level 1 5:A 2 18 INT active-lo level 0 13:A 2 19 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 2 0 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=15 # number of INTs options SMP_INVLTLB # #options SMP_PRIVPAGES # BROKEN, DO NOT use! #options SMP_AUTOSTART # BROKEN, DO NOT use! #options SERIAL_DEBUG # com port debug output ------------------------------------------------------------------------------- dmesg output: ,MTRR,PGE,MCA,CMOV> real memory = 134217728 (131072K bytes) avail memory = 129380352 (126348K bytes) DEVFS: ready for devices pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12378086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 mapreg[20] type=1 addr=0000e800 size=0010. chip3 rev 2 on pci0:11 bridge from pci0 to pci1 through 1. mapping regs: io:2280d0d0 mem:fae0f980 pmem:fbf0fbf0 vga0 rev 1 int a irq 19 on pci0:13 Freeing (NOT implimented) irq 9 for ISA cards. mapreg[10] type=0 addr=f9000000 size=4000. mapreg[14] type=0 addr=fb000000 size=800000. pci0: uses 8404992 bytes of memory from f9000000 upto fbffffff. pci0: uses 16 bytes of I/O space from d000 upto e80f. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 17 on pci1:4 Freeing (NOT implimented) irq 11 for ISA cards. mapreg[10] type=1 addr=0000d800 size=0100. [pci1 uses memory from f9800000 to faefffff] mapreg[14] type=0 addr=fa000000 size=1000. reg20: virtual=0xf9893000 physical=0xfa000000 size=0x1000 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "QUANTUM XP34550W LXQ1" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4341MB (8890760 512 byte sectors) sd0(ahc0:0:0): with 5899 cyls, 10 heads, and an average 150 sectors/track ahc1 rev 0 int a irq 18 on pci1:5 Freeing (NOT implimented) irq 10 for ISA cards. mapreg[10] type=1 addr=0000d400 size=0100. [pci1 uses memory from f9800000 to faefffff] mapreg[14] type=0 addr=f9800000 size=1000. reg20: virtual=0xf9894000 physical=0xf9800000 size=0x1000 ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 4 synchronous at 10.0MHz, offset = 0xf (ahc1:4:0): "PLEXTOR CD-ROM PX-12CS 1.00" type 5 removable SCSI 2 cd0(ahc1:4:0): CD-ROM can't get the size pci1: uses 8192 bytes of memory from f9800000 upto fa000fff. pci1: uses 512 bytes of I/O space from d400 upto d8ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached lpt1 not found at 0xffffffff psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0060040, tty f000009a, net f000009a BIOS Geometries: 0:0228fe3f 0..552=553 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. DEVFS: ready to run Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 17, 18, imen: 0x00f9fe21 bpf: tun0 attached bpf: tun1 attached bpf: tun2 attached bpf: sl0 attached bpf: lo0 attached IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry sd0s1: type 0x7, start 63, end = 2040254, size 2040192 : OK sd0s2: type 0xa5, start 2040255, end = 8883944, size 6843690 : OK WARNING: / was not properly dismounted. SMP: All idle procs online. =============================================================================== One interesting thing I found while trying to get my GUS PnP Pro working was that the BIOS has a feature that lets you hardwire a specific interrupt to a specific PCI slot. I tried hardwiring my PCI slots to 11, 10 and 9 (for the 1st three), but it didn't help the APIC_IO kernel to boot. Oh well. I did manage to monkey with the bios and get the machine to get past the SCSI bios with the GUS in. :) (the first time I put the GUS in, the machine hung while trying to probe the SCSI devices, I guess it was an IRQ conflict between the GUS PnP Pro and the 3940UW. You'd think that the PnP stuff in the BIOS would make sure that wouldn't happen...) If there's any more information I can supply, or testing that needs to be done, just let me know. Thanks for all the insight, Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Wed Jan 15 19:48:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA24680 for smp-outgoing; Wed, 15 Jan 1997 19:48:30 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA24590 for ; Wed, 15 Jan 1997 19:47:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id UAA07607; Wed, 15 Jan 1997 20:21:07 -0700 Message-Id: <199701160321.UAA07607@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: matt@lkg.dec.com, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Wed, 15 Jan 1997 20:49:20 EST." <199701160149.UAA06971@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 20:21:07 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Sorry I took so long to get back on this. In a nutshell, this is >what I have figured out: > > standard SMP kernel APIC_IO SMP kernel >de0 in, MP v1.1 enabled works hangs right before init >de0 in, MP v1.4 enabled hangs hangs so there is another problem here, I assume this works OK with the UNI-proc kernel? >de0 out, MP v1.4 enabled works works initially, X crashes it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ as Peter just stated, this could be expected for other reasons involving the npx code. --- >Probing for devices on PCI bus 1: >ahc0 rev 0 int a irq 17 on pci1:4 >Freeing (NOT implimented) irq 11 for ISA cards. > ... >ahc1 rev 0 int a irq 18 on pci1:5 >Freeing (NOT implimented) irq 10 for ISA cards. this is what we want to see, the code picked up the proper APIC_IO irqs from the MP table! --- and these are what the entries should look like (1.4 made the difference) >Bus: Bus ID Type > 0 PCI > 1 PCI > 2 ISA > >I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > ... > INT active-lo level 1 4:A 2 17 > INT active-lo level 1 5:A 2 18 > INT active-lo level 0 13:A 2 19 note how the table both uses the correct PCI syntax AND the 2 PCI busses between 4/5 and 13, ie 4/5 are on pci1 while 13 is on pci0. (although I would be curious as to whether it would still report 2 PCI busses without the 3940 installed...) So the remaining question for this system is why the SMC card hangs the SMP kernel, both APIC_IO and non-APIC, UNLESS it is set for MP spec v1.1 --- > If there's any more information I can supply, or testing that needs >to be done, just let me know. I'll get back to you when I have some free time (several weeks at least...) -- 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----- From owner-freebsd-smp Wed Jan 15 22:12:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA04804 for smp-outgoing; Wed, 15 Jan 1997 22:12:38 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA04799 for ; Wed, 15 Jan 1997 22:12:30 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id BAA09539; Thu, 16 Jan 1997 01:10:50 -0500 (EST) From: Kenneth Merry Message-Id: <199701160610.BAA09539@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701160321.UAA07607@clem.systemsix.com> from Steve Passe at "Jan 15, 97 08:21:07 pm" To: smp@csn.net (Steve Passe) Date: Thu, 16 Jan 1997 01:10:49 -0500 (EST) Cc: matt@lkg.dec.com, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... [ if you want to see the good news, skip down a bit ] > > Sorry I took so long to get back on this. In a nutshell, this is > >what I have figured out: > > > > standard SMP kernel APIC_IO SMP kernel > >de0 in, MP v1.1 enabled works hangs right before init > >de0 in, MP v1.4 enabled hangs hangs > > so there is another problem here, I assume this works OK with the UNI-proc > kernel? Actually, I haven't tried MP v1.4 with the uni-proc kernel. > >de0 out, MP v1.4 enabled works works initially, X crashes it > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > as Peter just stated, this could be expected for other reasons involving > the npx code. Ahh, I see. *sigh* > --- > >Probing for devices on PCI bus 1: > >ahc0 rev 0 int a irq 17 on pci1:4 > >Freeing (NOT implimented) irq 11 for ISA cards. > > ... > >ahc1 rev 0 int a irq 18 on pci1:5 > >Freeing (NOT implimented) irq 10 for ISA cards. > > this is what we want to see, the code picked up the proper APIC_IO irqs > from the MP table! > > --- > and these are what the entries should look like (1.4 made the difference) > > >Bus: Bus ID Type > > 0 PCI > > 1 PCI > > 2 ISA > > > >I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > > ... > > INT active-lo level 1 4:A 2 17 > > INT active-lo level 1 5:A 2 18 > > INT active-lo level 0 13:A 2 19 > > note how the table both uses the correct PCI syntax AND > the 2 PCI busses between 4/5 and 13, ie 4/5 are on pci1 while 13 is on > pci0. (although I would be curious as to whether it would still report > 2 PCI busses without the 3940 installed...) > > So the remaining question for this system is why the SMC card hangs the > SMP kernel, both APIC_IO and non-APIC, UNLESS it is set for MP spec v1.1 Well, I'm not entirely sure why the SMC card was hanging the system, but I do think it had a whole lot to do with the fact that ahc1 (the second channel on the 3940UW) was using the *same* interrupt as the SMC card. As Arlie Davis pointed out, the 3940 cards seem to steal an interrupt from the next PCI slot down. In my case, the SMC card, when it was in, was in the next PCI slot down from the 3940UW. Well, once I realized the 3940 was grabbing an interrupt, I tried what Arlie suggested, and cleared a slot next to the 3940. I now have the following setup: Slot 1: Matrox Millenium (IRQ 11) Slot 2: Adaptec 3940UW (IRQ 10) Slot 3: Empty (IRQ 9) Slot 4: SMC 10/100 card (IRQ 15) Slot 5: Empty (shares IRQ w/ slot 4) Well, *now* the APIC_IO/SMP_INVLTLB kernel works. I can boot up, turn on both processors, etc., no problem. ahc1 now steals IRQ 9 from slot 3, but since there's nothing there, there are no conflicts. I hard-coded all of these interrupts to the slots in the BIOS. The bad thing, though, is that with this setup, it means I won't be able to put anything in slot 3. And if I put anything in slot 5, it'll have to be able to share an interrupt with the SMC card. X still doesn't work in any case, just panics the machine. According to Peter, it's an NPX problem. So, I'm still running the non APIC_IO kernel, since X works under it. In case it helps, here's the boot -v output from my APIC_IO/SMP_INVLTLB kernel. The top part is truncated, not enough room in the kernel message buffer I guess. (anyone know what I need to do to increase the size of it?) ======================================================================== r> rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 mapreg[20] type=1 addr=0000e800 size=0010. de0 rev 18 int a irq 19 on pci0:9 Freeing (NOT implimented) irq 12 for ISA cards. mapreg[10] type=1 addr=0000e000 size=0080. mapreg[14] type=0 addr=fa000000 size=0080. reg16: ioaddr=0xe000 size=0x80 de0: SMC 9332 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:53:3d:e7 de0: enabling 10baseT port bpf: de0 attached chip3 rev 2 on pci0:11 Freeing (NOT implimented) irq 12 for ISA cards. bridge from pci0 to pci1 through 1. mapping regs: io:2280d0d0 mem:f9f0f900 pmem:fbf0fbf0 vga0 rev 1 int a irq 16 on pci0:12 Freeing (NOT implimented) irq 11 for ISA cards. mapreg[10] type=0 addr=f8800000 size=4000. mapreg[14] type=0 addr=fb000000 size=800000. pci0: uses 8405120 bytes of memory from f8800000 upto fbffffff. pci0: uses 144 bytes of I/O space from d000 upto e80f. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 17 on pci1:4 Freeing (NOT implimented) irq 10 for ISA cards. mapreg[10] type=1 addr=0000d800 size=0100. [pci1 uses memory from f9000000 to f9ffffff] mapreg[14] type=0 addr=f9800000 size=1000. reg20: virtual=0xf98ac000 physical=0xf9800000 size=0x1000 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 (ahc0:0:0): "QUANTUM XP34550W LXQ1" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4341MB (8890760 512 byte sectors) sd0(ahc0:0:0): with 5899 cyls, 10 heads, and an average 150 sectors/track ahc1 rev 0 int a irq 18 on pci1:5 Freeing (NOT implimented) irq 9 for ISA cards. mapreg[10] type=1 addr=0000d400 size=0100. [pci1 uses memory from f9000000 to f9ffffff] mapreg[14] type=0 addr=f9000000 size=1000. reg20: virtual=0xf98ad000 physical=0xf9000000 size=0x1000 ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 4 synchronous at 10.0MHz, offset = 0xf (ahc1:4:0): "PLEXTOR CD-ROM PX-12CS 1.00" type 5 removable SCSI 2 cd0(ahc1:4:0): CD-ROM can't get the size pci1: uses 8192 bytes of memory from f9000000 upto f9800fff. pci1: uses 512 bytes of I/O space from d400 upto d8ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached lpt1 not found at 0xffffffff psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in Checking for GUS Plug-n-Play ... Board Vendor ID: GRV0001 Board Serial Number: 00000001 oops I didnt find gus gus0 not found npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0060040, tty f008009a, net f008009a BIOS Geometries: 0:0228fe3f 0..552=553 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. DEVFS: ready to run Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 17, 18, 19, imen: 0x00f1fe21 bpf: tun0 attached bpf: tun1 attached bpf: tun2 attached bpf: sl0 attached bpf: lo0 attached IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry sd0s1: type 0x7, start 63, end = 2040254, size 2040192 : OK sd0s2: type 0xa5, start 2040255, end = 8883944, size 6843690 : OK SMP: All idle procs online. ======================================================================== > --- > > If there's any more information I can supply, or testing that needs > >to be done, just let me know. > > I'll get back to you when I have some free time (several weeks at least...) Well, thanks for all your work! Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Wed Jan 15 23:10:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA06766 for smp-outgoing; Wed, 15 Jan 1997 23:10:28 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA06703 for ; Wed, 15 Jan 1997 23:09:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA08493; Wed, 15 Jan 1997 23:44:28 -0700 Message-Id: <199701160644.XAA08493@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: matt@lkg.dec.com, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Thu, 16 Jan 1997 01:10:49 EST." <199701160610.BAA09539@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 23:44:28 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, good news indeed! >Slot 1: Matrox Millenium (IRQ 11) >Slot 2: Adaptec 3940UW (IRQ 10) >Slot 3: Empty (IRQ 9) >Slot 4: SMC 10/100 card (IRQ 15) >Slot 5: Empty (shares IRQ w/ slot 4) > ... > The bad thing, though, is that with this setup, it means I won't be >able to put anything in slot 3. And if I put anything in slot 5, it'll >have to be able to share an interrupt with the SMC card. I don't think the millenium actually uses irq 11 for anything, how about swapping slots 1 & 2, ie let the ahc1 grab the irq that is being reserved for the vga card (but I *think* is unused)? -- 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----- From owner-freebsd-smp Wed Jan 15 23:31:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA07600 for smp-outgoing; Wed, 15 Jan 1997 23:31:30 -0800 (PST) Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA07595 for ; Wed, 15 Jan 1997 23:31:23 -0800 (PST) From: sthaug@nethelp.no Received: (qmail 10559 invoked by uid 1001); 16 Jan 1997 07:31:05 +0000 (GMT) To: vanmaren@fast.cs.utah.edu Cc: smp@freebsd.org Subject: RE: Adaptec 3940UW and SMP In-Reply-To: Your message of "Wed, 15 Jan 1997 17:07:57 -0700" References: <199701160007.RAA08453@fast.cs.utah.edu> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 16 Jan 1997 08:31:05 +0100 Message-ID: <10557.853399865@verdi.nethelp.no> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Of course your mileage may vary...and I've (personally) never > seen a device that uses int C or D (maybe quad ethernet cards?) The ZNYX ZX314 (4x10BT) and ZX346 (4x100TX) only use INTA. So do the Cogent EM400 and EM440 (both 4x100TX). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-smp Thu Jan 16 03:44:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA17458 for smp-outgoing; Thu, 16 Jan 1997 03:44:51 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA17453 for ; Thu, 16 Jan 1997 03:44:49 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id GAA00415; Thu, 16 Jan 1997 06:44:30 -0500 (EST) From: Keith Mitchell Message-Id: <199701161144.GAA00415@weenix.guru.org> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701160644.XAA08493@clem.systemsix.com> from Steve Passe at "Jan 15, 97 11:44:28 pm" To: smp@csn.net (Steve Passe) Date: Thu, 16 Jan 1997 06:44:30 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Slot 1: Matrox Millenium (IRQ 11) > >Slot 2: Adaptec 3940UW (IRQ 10) > >Slot 3: Empty (IRQ 9) > >Slot 4: SMC 10/100 card (IRQ 15) > >Slot 5: Empty (shares IRQ w/ slot 4) > > ... > > The bad thing, though, is that with this setup, it means I won't be > >able to put anything in slot 3. And if I put anything in slot 5, it'll > >have to be able to share an interrupt with the SMC card. > > I don't think the millenium actually uses irq 11 for anything, how about > swapping slots 1 & 2, ie let the ahc1 grab the irq that is being reserved > for the vga card (but I *think* is unused)? Steve, I modified my setup to be: Slot 1: Ethernet Card (de1) IRQ5 Slot 2: Adaptec 3940UW IRQ9 Slot 3: ATI Mach64 IRQ10 Slot 4: Ethernet Card (de0) IRQ11 With this setup, everything gets mapped to their own IRQ, but the APIC_IO stuff still doesn't work. I included below the verbose boot with APIC_IO on for this setup. IOS basemem (639K) != RTC basemem (640K), setting to BIOS value ipi_ihandler_attach: counting ipi irq24's as clk0 irqs ipi_ihandler_attach: counting ipi irq25's as clk0 irqs ipi_ihandler_attach: counting ipi irq26's as clk0 irqs ipi_ihandler_attach: counting ipi irq27's as clk0 irqs Copyright (c) 1995-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1995, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-SMP #9: Tue Jan 14 18:01:59 EST 1997 kmitch@weenix.guru.org:/usr/src/sys-smp/compile/W FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 io0 (APIC): apic id: 2, version: 0x00170011 Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193137 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 63782912 (62288K bytes) pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12508086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 3 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 mapreg[20] type=1 addr=00009000 size=0010. de0 rev 35 int a irq 19 on pci0:17 Freeing (NOT implimented) irq 5 for ISA cards. mapreg[10] type=1 addr=00006000 size=0080. mapreg[14] type=0 addr=e0800000 size=0080. reg16: ioaddr=0x6000 size=0x80 de0: 21040 [10Mb/s] pass 2.3 de0: address 00:80:48:e8:17:a4 de0: enabling 10baseT port vga0 rev 1 on pci0:18 Freeing (NOT implimented) irq 5 for ISA cards. mapreg[10] type=0 addr=e0000000 size=800000. chip3 rev 2 on pci0:19 Freeing (NOT implimented) irq 5 for ISA cards. bridge from pci0 to pci1 through 1. mapping regs: io:2280f0f0 mem:dff0d000 pmem:dff0de00 de1 rev 35 int a irq 16 on pci0:20 Freeing (NOT implimented) irq 11 for ISA cards. mapreg[10] type=1 addr=00006100 size=0080. mapreg[14] type=0 addr=e0801000 size=0080. reg16: ioaddr=0x6100 size=0x80 de1: 21040 [10Mb/s] pass 2.3 de1: address 00:80:48:e8:19:cd de1: enabling 10baseT port pci0: uses 8388864 bytes of memory from d0000000 upto e080107f. pci0: uses 272 bytes of I/O space from 6000 upto ffff. pci0: subordinate busses from 1 upto 1. Probing for devices on PCI bus 1: ahc0 rev 0 int a irq 10 on pci1:4 mapreg[10] type=1 addr=0000f000 size=0100. [pci1 uses memory from d0000000 to dfffffff] mapreg[14] type=0 addr=d0000000 size=1000. reg16: ioaddr=0xf000 size=0x100 ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A Choosing drivers for scbus configured at 0 ahc0 waiting for scsi devices to settle ahc0: target 0 using 16Bit transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0x8 (ahc0:0:0): "MICROP 4221-09 1128RF 28RF" type 0 fixed SCSI 2 sd is configured at 0 sd0(ahc0:0:0): Direct-Access 1955MB (4004219 512 byte sectors) sd0(ahc0:0:0): with 4048 cyls, 9 heads, and an average 109 sectors/track ahc0: target 3 synchronous at 10.0MHz, offset = 0xf (ahc0:3:0): "iomega jaz 1GB H.62" type 0 removable SCSI 2 sd is configured at 1 sd1(ahc0:3:0): Direct-Access sd1(ahc0:3:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) sd1(ahc0:3:0): with 1021 cyls, 64 heads, and an average 32 sectors/track ahc0: target 4 synchronous at 5.0MHz, offset = 0xf (ahc0:4:0): "ARCHIVE Python 28388-XXX 5.28" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x13, drive empty ahc0: target 5 synchronous at 5.0MHz, offset = 0xf (ahc0:5:0): "PLEXTOR CD-ROM PX-6XCS 1.07" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM can't get the size ahc1 rev 0 int a irq 9 on pci1:5 mapreg[10] type=1 addr=0000f100 size=0100. [pci1 uses memory from d0000000 to dfffffff] mapreg[14] type=0 addr=d0001000 size=1000. reg16: ioaddr=0xf100 size=0x100 ahc1: Reading SEEPROM...done. ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1: Reseting Channel A ahc1: Downloading Sequencer Program...Done ahc1: Probing channel A ahc1 waiting for scsi devices to settle ahc1: target 0 synchronous at 10.0MHz, offset = 0xf (ahc1:0:0): "Quantum XP32150 576D" type 0 fixed SCSI 2 sd2(ahc1:0:0): Direct-Access 2050MB (4199760 512 byte sectors) sd2(ahc1:0:0): with 3907 cyls, 10 heads, and an average 107 sectors/track ahc1: target 1 synchronous at 10.0MHz, offset = 0xf (ahc1:1:0): "CONNER CFP1080S 4649" type 0 fixed SCSI 2 sd3(ahc1:1:0): Direct-Access 1030MB (2110812 512 byte sectors) sd3(ahc1:1:0): with 3658 cyls, 6 heads, and an average 96 sectors/track pci1: uses 8192 bytes of memory from d0000000 upto d0001fff. pci1: uses 512 bytes of I/O space from f000 upto f1ff. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0: current command byte:0047 psm0: status after reset 00 02 64 psm: status 09 03 c8 (get_mouse_buttons) psm0: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0, 3 buttons? fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface imasks: bio c0000640, tty f0091092, net f0091092 BIOS Geometries: 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors 1:03fc3f20 0..1020=1021 cylinders, 0..63=64 heads, 1..32=32 sectors 2:0104fe3f 0..260=261 cylinders, 0..254=255 heads, 1..63=63 sectors 3:0082fe3f 0..130=131 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. Enabled INTs: 1, 2, 4, 6, 7, 8, 9, 10, 12, 16, 19, imen: 0x00f6e829 From owner-freebsd-smp Thu Jan 16 11:22:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA07975 for smp-outgoing; Thu, 16 Jan 1997 11:22:45 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA07970 for ; Thu, 16 Jan 1997 11:22:43 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id OAA00425; Thu, 16 Jan 1997 14:22:26 -0500 (EST) From: Keith Mitchell Message-Id: <199701161922.OAA00425@weenix.guru.org> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701161803.LAA11591@clem.systemsix.com> from Steve Passe at "Jan 16, 97 11:03:20 am" To: smp@csn.net (Steve Passe) Date: Thu, 16 Jan 1997 14:22:25 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think the problem is that the tomcat is not adequately declaring the > info about the bridge routing in the MP table. We have demonstrated > that the 3940 can work on Kenneth Merry's system. The difference is > that his boards MP table better reflects the bridge connection. I can probably > write around this problem, but I dont have the time to attack it right now. > > As a short term fix, try applying this patch to i386/i386/mp_machdep.c. > All it does is stick to the traditional lower 16 irqs, instead of using a mix > as happens now with some MP entries correct (de0/de1) but others failing > (ahc0/ahc1). This is interesting. When I boot it lists the PCI devices and when it lists the adaptec it shows it being on PCI bus 1. ;-) Just as a side note, I tried tyans new bios for my motherboard and it didn't fix the problem, but it did change the order of the BUS listing in the mptable output (ie before it listed ISA first, now it lists PCI first -- still only one PCI though). I did try the patch, but I still couldn't boot. It locked up in the same place. The only difference I saw was not seeing those FREEING messages. I am going to try to contact tyan about the PCI bus not being listed in the MP table. From owner-freebsd-smp Thu Jan 16 12:40:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA12208 for smp-outgoing; Thu, 16 Jan 1997 12:40:39 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA12193 for ; Thu, 16 Jan 1997 12:40:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA12419 for ; Thu, 16 Jan 1997 13:40:12 -0700 Message-Id: <199701162040.NAA12419@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: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Jan 1997 13:40:12 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Summary: We appear to have fixed this problem for 1 system, but not the other. The difference is the way the MP tables declare the 3940 INTerrupts. The working system is more 'definitive', however there *may* be enough info in the non-working system to get around its incomplete MP table info with some coding effort. This assummes that they are redirecting the 3940 irqs properly in hardware on the motherboard. Another part to the solution appears to be insuring that the 3940 doesn't attempt to share INTs with other hardware. This shouldn't be a problem, but... I will not be able to get to this for 3-4 weeks at the earliest. Anyone else wanting to attempt it, feel free. I placed the MP tables for these machines in the database as entries 22,23,24. Thanx to Keith Mitchell and Kenneth Merry for running all the tests, and everyone else for their input. --- I had no idea this was a problem till the other day. Perhaps we should make a definitive list of what doesn't work at the present while there is a lull in the development effort. Please send reports of any failings to the list, (hopefully someone will have time to collect and collate, then I will put up on the web page.) Here's several items for the list: -- From: smp@csn.net - bridged PCI cards don't work in all motherboards (lest we forget!) - every few boots I get: starting system daemons: syslogd. syslogd: cannot create /var/run/log: Address already in use syslogd: child pid 69 exited with return code 1 once this happens it happens every time till I remove /var/run/log & /var/run/syslog.pid. I suspect its something to do with the fact that we are NOT shutting down the 2nd CPU properly during halt. The '/var/run/log' file it complains about is a socket left lying around from the previous run. A quick fix would probably be an "rm -f /var/run/log" preceeding the syslogd creation in /etc/rc (is that where this happens?) -- From: dave adkins >I've noticed that with INVLTLB the 1pg and 2pg invalidates call invlpg which >calls smp_invalidate as well as calling smp_invalidate explicitly. I've >removed the explicit calls to smp_invalidate in the 1pg and 2pg routines >and reduced the number of ipi int27's with no effect on the system's >stability. It reduces the number of sio overflows. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Jan 16 20:54:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA10113 for smp-outgoing; Thu, 16 Jan 1997 20:54:56 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA10108 for ; Thu, 16 Jan 1997 20:54:54 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id XAA21370; Thu, 16 Jan 1997 23:52:28 -0500 (EST) From: Kenneth Merry Message-Id: <199701170452.XAA21370@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701160644.XAA08493@clem.systemsix.com> from Steve Passe at "Jan 15, 97 11:44:28 pm" To: smp@csn.net (Steve Passe) Date: Thu, 16 Jan 1997 23:52:28 -0500 (EST) Cc: matt@lkg.dec.com, kmitch@weenix.guru.org, se@zpr.uni-koeln.de, smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > good news indeed! > > >Slot 1: Matrox Millenium (IRQ 11) > >Slot 2: Adaptec 3940UW (IRQ 10) > >Slot 3: Empty (IRQ 9) > >Slot 4: SMC 10/100 card (IRQ 15) > >Slot 5: Empty (shares IRQ w/ slot 4) > > ... > > The bad thing, though, is that with this setup, it means I won't be > >able to put anything in slot 3. And if I put anything in slot 5, it'll > >have to be able to share an interrupt with the SMC card. > I don't think the millenium actually uses irq 11 for anything, how about > swapping slots 1 & 2, ie let the ahc1 grab the irq that is being reserved > for the vga card (but I *think* is unused)? Indeed, that works. So now things look like this: Slot 1: Adaptec 3940UW (IRQ 11) Slot 2: Matrox Millenium (IRQ 10) Slot 3: Empty (IRQ 9) Slot 4: SMC 10/100 card (IRQ 15) Slot 5: Empty (shares IRQ w/ slot 4) ahc1 now grabs IRQ 10 from the millenium, and things seem to work okay. This will hopefully enable me to add a video capture card at least, and perhaps a second ethernet card. :) Thanks again, Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Thu Jan 16 21:03:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA10487 for smp-outgoing; Thu, 16 Jan 1997 21:03:34 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA10474 for ; Thu, 16 Jan 1997 21:03:28 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.8.4/8.8.4) id PAA08344 for smp@freebsd.org; Fri, 17 Jan 1997 15:03:25 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id PAA17072 for ; Fri, 17 Jan 1997 15:12:38 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by pandora.devetir.qld.gov.au (8.6.10/8.6.12) with ESMTP id PAA20863 for ; Fri, 17 Jan 1997 15:05:30 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id FAA13014 for ; Fri, 17 Jan 1997 05:04:38 GMT Message-Id: <199701170504.FAA13014@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 2.0beta 12/23/96 To: smp@freebsd.org Subject: Floating point probs? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 15:04:38 +1000 From: Stephen Hocking Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After perusing the list for a while I hear that "there are some floating point problems with the SMP code". What problems, and when do they arise (I'm thinking of buying the Gigabyte 586dx MB soon)? Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-smp Thu Jan 16 21:41:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA11828 for smp-outgoing; Thu, 16 Jan 1997 21:41:09 -0800 (PST) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA11821 for ; Thu, 16 Jan 1997 21:41:02 -0800 (PST) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id NAA03128; Fri, 17 Jan 1997 13:40:32 +0800 (WST) Message-Id: <199701170540.NAA03128@spinner.DIALix.COM> X-Mailer: exmh version 2.0beta 12/23/96 To: Stephen Hocking cc: smp@freebsd.org Subject: Re: Floating point probs? In-reply-to: Your message of "Fri, 17 Jan 1997 15:04:38 +1000." <199701170504.FAA13014@netfl15a.devetir.qld.gov.au> Date: Fri, 17 Jan 1997 13:40:31 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stephen Hocking wrote: > > > After perusing the list for a while I hear that "there are some floating poin t > problems with the SMP code". What problems, and when do they arise (I'm > thinking of buying the Gigabyte 586dx MB soon)? My personal feeling is that the problems are of the same order as the Shuttle Challenger's problems. I don't really know how to fix it, because I have not researched how the fpu interlocking works and really don't know what the right approach is. I am not 100% sure of the magnitude of the problem either. Simple floating point seems to work quite safely, but the heavy demands of the X servers pushes it over the edge. Perhaps somebody would like to fill in the gaps in my understanding and correct my bad assumptions.. As I understand it (in a standard kernel): * npxproc is the pointer to the process that has been allocated the FPU. * if npxproc == curproc, obviously it's running in the foreground. * if the process takes an interrupt while a long running fpu operation is in progress, it can be switched out (npxproc != cpuproc). * if a process wants to use the fpu and curproc != npxproc (ie: another process's FPU operation is still running), the FPU is halted, the FPU state is stored in npxproc's pcb and the new process is either given a new fpu context if it's never used it, or it's old fpu context is restored from it's pcb. * if the FPU traps with a completion signal (trap 16?, was irq 13), the result is stored in the sleeping process's pcb (npxproc != curproc), or the current process gets the result. * when the kernel wants to use the FPU (for the i586 fast copying etc), it has to jump through all sorts of hoops to "get" the fpu to itself. Things I don't know or am not sure about: * Is the state saving lazy? ie: does the process indicated in npxproc have an up to date pcb when it's switched out, or is the process's state "held" only on the FPU? * can a process be the "owner" of the FPU even though it's sleeping or on the run queue and not using the FPU? Does it have it's ownership taken away when it's finished, or does it keep it indefinately until something else uses it? * If it's indefinate, this is a SMP killer. Imagine the process owning the FPU on cpu#0 is scheduled onto cpu#1. cpu#1 would know nothing about the fpu state on cpu#0, or the fact that the process owns the fpu "over there". It could also be allocated ownership of cpu#1's fpu as well. What if cpu#0 wants to kick the process off the fpu and saves the fpu#0 state in the proc's pcb while it's busy running on cpu#1? I don't know the "right" answer. I assume that caching the last proc's fpu state in the fpu is a win, if that's what we do. I think some combination of "binding" fpu-active processes onto cpu's might be needed, and/or flushing all fpu state out into the processes pcb as it heads back to the run queue. > Stephen Cheers, -Peter From owner-freebsd-smp Thu Jan 16 22:00:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA12747 for smp-outgoing; Thu, 16 Jan 1997 22:00:11 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA12634 for ; Thu, 16 Jan 1997 21:59:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA15160; Thu, 16 Jan 1997 22:49:18 -0700 Message-Id: <199701170549.WAA15160@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: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Thu, 16 Jan 1997 23:52:28 EST." <199701170452.XAA21370@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Jan 1997 22:49:18 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > I don't think the millenium actually uses irq 11 for anything, how about > > swapping slots 1 & 2, ie let the ahc1 grab the irq that is being reserved > > for the vga card (but I *think* is unused)? > > Indeed, that works. So now things look like this: > > Slot 1: Adaptec 3940UW (IRQ 11) > Slot 2: Matrox Millenium (IRQ 10) > Slot 3: Empty (IRQ 9) > Slot 4: SMC 10/100 card (IRQ 15) > Slot 5: Empty (shares IRQ w/ slot 4) > > ahc1 now grabs IRQ 10 from the millenium, and things seem to work > okay. This will hopefully enable me to add a video capture card at least, > and perhaps a second ethernet card. :) could you expand on the comment "(shares IRQ w/ slot 4)"? I visited the ASUS site an noticed that there were 5 (NOT 4) slots on this board and thought perhaps that that was done by making 2 PCI busses on the motherboard proper. Thus I wasn't sure if you were seeing PCI0 and PCI1 because of this fact, or because the BIOS was smart enough to see the PCI bridge on the 3940. Since both ahc and ed0 are in the 1st 4 slots, and presumably the MP table/dmesg shows them on pci1 and pci0, respectively, it appears to be the result of a BIOS 'doing the good thing'! This is re-enforced by the MP table for the same ASUS board owned by someone else that has no bridge cards and shows only 1 PCI bus (MP table database entry #5). -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Jan 16 22:22:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA13505 for smp-outgoing; Thu, 16 Jan 1997 22:22:10 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA13500 for ; Thu, 16 Jan 1997 22:22:08 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id XAA05910; Thu, 16 Jan 1997 23:22:02 -0700 (MST) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id XAA00178; Thu, 16 Jan 1997 23:21:57 -0700 Date: Thu, 16 Jan 1997 23:21:57 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199701170621.XAA00178@fast.cs.utah.edu> To: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The Tyan Titan Pro (you have the MP table) also has 5 PCI slots on ONE PCI bus. Two of the slots get mapped to the same int. However, the MPTABLE only had 4 listed -- I haven't investigated further (but the table is in ROM). Kevin From owner-freebsd-smp Thu Jan 16 22:36:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA14097 for smp-outgoing; Thu, 16 Jan 1997 22:36:41 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA14091 for ; Thu, 16 Jan 1997 22:36:38 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id BAA22619; Fri, 17 Jan 1997 01:36:35 -0500 (EST) From: Kenneth Merry Message-Id: <199701170636.BAA22619@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701170549.WAA15160@clem.systemsix.com> from Steve Passe at "Jan 16, 97 10:49:18 pm" To: smp@csn.net (Steve Passe) Date: Fri, 17 Jan 1997 01:36:34 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > > Indeed, that works. So now things look like this: > > > > Slot 1: Adaptec 3940UW (IRQ 11) > > Slot 2: Matrox Millenium (IRQ 10) > > Slot 3: Empty (IRQ 9) > > Slot 4: SMC 10/100 card (IRQ 15) > > Slot 5: Empty (shares IRQ w/ slot 4) > > > > ahc1 now grabs IRQ 10 from the millenium, and things seem to work > > okay. This will hopefully enable me to add a video capture card at least, > > and perhaps a second ethernet card. :) > could you expand on the comment "(shares IRQ w/ slot 4)"? I visited the > ASUS site an noticed that there were 5 (NOT 4) slots on this board and thought > perhaps that that was done by making 2 PCI busses on the motherboard proper. > Thus I wasn't sure if you were seeing PCI0 and PCI1 because of this fact, or > because the BIOS was smart enough to see the PCI bridge on the 3940. > Since both ahc and ed0 are in the 1st 4 slots, and presumably the > MP table/dmesg shows them on pci1 and pci0, respectively, it appears to be > the result of a BIOS 'doing the good thing'! This is re-enforced by the > MP table for the same ASUS board owned by someone else that has no > bridge cards and shows only 1 PCI bus (MP table database entry #5). Well, the manual isn't very revealing about whether there are actually one or two PCI busses on the board. The 5th slot is a a "shared" PCI/ISA slot, and it also has an ASUS MediaBus connector in line with the PCI connector. Here's what the board manual says about slot 5 and interrupts: "IMPORTANT: PCI Slots 4 & 5 share the same IRQ. If using PCI cards on both slots 4 & 5, make sure taht the drivers support "Share IRQ" or that one card does not need an IRQ assignment. Conflicts will arise on PCI Slots 4 & 5 taht will make the system unstable." In the bios, you can hardwire the interrupt for slots 1, 2, 3 by themselves. Slots 4 and 5 are lumped together, one IRQ for both. This probably isn't news, but just in case it is, in the C-P6ND (cpu daughtercard) manual, it says: "All PCI bus slots on the system use INTA#, thus all installed cards must be set to this value." That comment is in the section that talks about the bios interrupt assignment stuff. So, based on what you said, and the fact that it doesn't assign another IRQ to that slot, I'd bet that they just tacked on another slot, and didn't put a bridge chip on the board. (just a guess, I could be wrong of course. :) ) If it'll help, I can always look around the boards for bridge chips. :) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Thu Jan 16 23:07:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA15111 for smp-outgoing; Thu, 16 Jan 1997 23:07:18 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA15106 for ; Thu, 16 Jan 1997 23:07:16 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id CAA23020; Fri, 17 Jan 1997 02:07:11 -0500 (EST) From: Kenneth Merry Message-Id: <199701170707.CAA23020@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <1.5.4.32.19970117065159.0072fe60@internode.net> from Doug Russell at "Jan 16, 97 11:51:59 pm" To: drussell@internode.net (Doug Russell) Date: Fri, 17 Jan 1997 02:07:09 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Russell wrote... > At 01:10 AM 1/16/97 -0500, you wrote: > > >Slot 1: Matrox Millenium (IRQ 11) > >Slot 2: Adaptec 3940UW (IRQ 10) > >Slot 3: Empty (IRQ 9) > >Slot 4: SMC 10/100 card (IRQ 15) > >Slot 5: Empty (shares IRQ w/ slot 4) > > > The bad thing, though, is that with this setup, it means I won't be > >able to put anything in slot 3. And if I put anything in slot 5, it'll > >have to be able to share an interrupt with the SMC card. > > Aren't you stuck, no matter what? If the 3940 needs to use both int A and B > of it's slot, doesn't that necissarily mean that you can only run 3 cards > (assuming no interrupt sharing)? Actually... Does the video card REALLY > use the interrupt? Don't most cards have a jumper to disable interrupt use? You're right, it turns out that the video card didn't really need the interrupt... > If it doesn't use IRQ11, can't you put the Adaptec in slot 4, so it uses 15 > and 11? What does the ABCD map look like on slot 5? Is it the same as slot > 4? Slot 4 is A->15, B->11, C->10, D->9, right? Is 5 the same for all 4? The board only uses INT A, according to the manual. > I'm also assuming the 3940 can't share an interrupt with itself, (the other > half of itself, I mean... :-) ) otherwise they wouldn't have made it use INT > B as well, right? Well, it does use INT A for both channels: ahc0 rev 0 int a irq 11 on pci1:4 [ ... ] ahc1 rev 0 int a irq 10 on pci1:5 > Hmmm... Unfortunately I don't know enough about the PCI spec to know how > the whole INT A..D, mapping to ISA IRQs, etc. works. I guess I need to do > some reading. :-) I assume that the four (normal, in your case 5) PCI > slots always use the same physical lines for each slot. ie, you cannot > somehow map an additional line onto one of the slots. yes? There are only four IRQ's for 5 slots. Slots 4 and 5 share the same IRQ. So in order to have cards in both 4 and 5, I would assume that the cards would have to be able to share interrupts, or one of the cards would just not use an interrupt. (like a video card, perhaps) This is the setup I have now, it seems to work fine: Slot 1: Adaptec 3940UW (IRQ 11) Slot 2: Matrox Millenium (IRQ 10) Slot 3: Empty (IRQ 9) Slot 4: SMC 10/100 card (IRQ 15) Slot 5: Empty (shares IRQ w/ slot 4) The second channel of the 3940 grabs IRQ 10, and video still works fine. > Too bad you can't just jumper things around like you can with ISA interrupts. > My friends love this machine.... :-) [ ... ] Yeah, in a way I miss the way that you could unambiguously hardwire things to one specific interrupt, and not have to worry about some setup program mucking things up. At least I have the ability to hardwire specific interrupts to specific slots, though. The BIOS in this thing also lets you reserve specific interrupts for "legacy" ISA cards. The rest of the interrupts are fair game for the bios' PnP setup code. Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Thu Jan 16 23:11:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA15244 for smp-outgoing; Thu, 16 Jan 1997 23:11:05 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA15181 for ; Thu, 16 Jan 1997 23:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA15623; Fri, 17 Jan 1997 00:02:13 -0700 Message-Id: <199701170702.AAA15623@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: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Thu, 16 Jan 1997 23:21:57 MST." <199701170621.XAA00178@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 00:02:13 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > The Tyan Titan Pro (you have the MP table) also has 5 PCI slots on > ONE PCI bus. Two of the slots get mapped to the same int. > However, the MPTABLE only had 4 listed -- I haven't investigated > further (but the table is in ROM). ^^^^^^^^^^^^^^^^^^^^^^^ I have a theory about this, specifically that just because the mptable program finds the table in "the BIOS", it doesn't mean that the data is in ROM. Most modern MBs shadow the BIOS from ROM/FLASH to RAM for speed improvements. This means that they could dynamically build the MP table however they wanted. Note how we see the MP table for the ASUS change when going from MP spec 1.1 to 1.4, even though it is at the same address in the BIOS. Also note how it shows 1 PCI bus without a PCI bridge card, but 2 with, and how the INT assignments change according to card placement and BIOS settings. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Jan 16 23:11:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA15259 for smp-outgoing; Thu, 16 Jan 1997 23:11:44 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA15254 for ; Thu, 16 Jan 1997 23:11:40 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id AAA06495; Fri, 17 Jan 1997 00:11:37 -0700 (MST) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id AAA01053; Fri, 17 Jan 1997 00:11:37 -0700 Date: Fri, 17 Jan 1997 00:11:37 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199701170711.AAA01053@fast.cs.utah.edu> To: smp@csn.net, vanmaren@fast.cs.utah.edu Subject: Re: Adaptec 3940UW and SMP Cc: smp@freebsd.org Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> further (but the table is in ROM). Well, considering it *always* lists two CPUs, I'm not too hopeful :( From owner-freebsd-smp Thu Jan 16 23:36:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA15850 for smp-outgoing; Thu, 16 Jan 1997 23:36:04 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA15798 for ; Thu, 16 Jan 1997 23:35:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA15776; Fri, 17 Jan 1997 00:26:40 -0700 Message-Id: <199701170726.AAA15776@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: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 01:36:34 EST." <199701170636.BAA22619@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 00:26:39 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Well, the manual isn't very revealing about whether there are > actually one or two PCI busses on the board. The 5th slot is a a "shared" > PCI/ISA slot, and it also has an ASUS MediaBus connector in line with the > PCI connector. Here's what the board manual says about slot 5 and > interrupts: > > "IMPORTANT: PCI Slots 4 & 5 share the same IRQ. If using PCI cards on both > slots 4 & 5, make sure taht the drivers support "Share IRQ" or that one > card does not need an IRQ assignment. Conflicts will arise on PCI Slots 4 > & 5 taht will make the system unstable." so it appears that you might be able to put the 3940 into slot4 and the vga into slot5, the SMC in any of the others, and have 2 free, usable slots --- > > In the bios, you can hardwire the interrupt for slots 1, 2, 3 by > themselves. Slots 4 and 5 are lumped together, one IRQ for both. This > ... > That comment is in the section that talks about the bios interrupt > assignment stuff. So, based on what you said, and the fact that it doesn't > assign another IRQ to that slot, I'd bet that they just tacked on another > slot, and didn't put a bridge chip on the board. (just a guess, I could be > wrong of course. :) ) so this is where I get a little confused... I thought in the past the typical board limitation of 4 PCI slots was based on the LINE[ABCD] situation. Early PCI MBs sometimes used LINEA for slot1, LINEB for slot2, etc. I was thinking that now they route the LINEA pin from each card to the LINE[ABCD] inputs of the PCI_ISA bridge chip, hence the magic of the number 4. Is this so, or do these PCI slot/LINEA INTs go directly to the MB ISA redirector hardware? If so, what is magic about 4 (slots)? Stated another way, why does the 5th slot need to be shared? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Jan 16 23:42:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA16069 for smp-outgoing; Thu, 16 Jan 1997 23:42:51 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA16059 for ; Thu, 16 Jan 1997 23:42:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA15826; Fri, 17 Jan 1997 00:31:21 -0700 Message-Id: <199701170731.AAA15826@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: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: smp@csn.net, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 00:11:37 MST." <199701170711.AAA01053@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 00:31:20 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >> further (but the table is in ROM). > Well, considering it *always* lists two CPUs, I'm not too hopeful :( that would tend to say this particular MB does have a static table in ROM, bummer! I have had other tables sent to me where there was only one CPU in the board, and the table reflected that fact... -- 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----- From owner-freebsd-smp Thu Jan 16 23:50:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA16225 for smp-outgoing; Thu, 16 Jan 1997 23:50:27 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA16191 for ; Thu, 16 Jan 1997 23:49:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA15883; Fri, 17 Jan 1997 00:41:56 -0700 Message-Id: <199701170741.AAA15883@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: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 02:07:09 EST." <199701170707.CAA23020@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 00:41:56 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > At least I have the ability to hardwire specific interrupts to >specific slots, though. this is a useful feature that many MBs DON'T provide... --- > The BIOS in this thing also lets you reserve >specific interrupts for "legacy" ISA cards. The rest of the interrupts are >fair game for the bios' PnP setup code. this is common to most/all of the SMP MBs I have looked at. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Jan 17 00:09:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA16748 for smp-outgoing; Fri, 17 Jan 1997 00:09:31 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA16743 for ; Fri, 17 Jan 1997 00:09:28 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id DAA23565; Fri, 17 Jan 1997 03:09:25 -0500 (EST) From: Kenneth Merry Message-Id: <199701170809.DAA23565@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701170726.AAA15776@clem.systemsix.com> from Steve Passe at "Jan 17, 97 00:26:39 am" To: smp@csn.net (Steve Passe) Date: Fri, 17 Jan 1997 03:09:24 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > Hi, > > > Well, the manual isn't very revealing about whether there are > > actually one or two PCI busses on the board. The 5th slot is a a "shared" > > PCI/ISA slot, and it also has an ASUS MediaBus connector in line with the > > PCI connector. Here's what the board manual says about slot 5 and > > interrupts: > > > > "IMPORTANT: PCI Slots 4 & 5 share the same IRQ. If using PCI cards on both > > slots 4 & 5, make sure taht the drivers support "Share IRQ" or that one > > card does not need an IRQ assignment. Conflicts will arise on PCI Slots 4 > > & 5 taht will make the system unstable." > so it appears that you might be able to put the 3940 into slot4 and the > vga into slot5, the SMC in any of the others, and have 2 free, usable slots Well, perhaps, perhaps not. Since slots 4 and 5 share the same interrupt, the 3940 can't grab the same interrupt again, so it would probably wrap around and grab the interrupt from slot 1. Arlie Davis mentioned something about that: > then when the system booted, the 3940 would have allocated IRQs 5 AND 10 > to itself. (If the 3940 were in slot four, it would steal the IRQ from > slot 1.) No matter what slot I put the 3940 in, it steals the IRQ from > the next slot. Also, I think I remember having a problem with the system hanging on the SCSI bios load when I stuck the 3940 in slot 4 or maybe 5 one time...not sure. I'd have to do it again to verify that. > --- > > > > In the bios, you can hardwire the interrupt for slots 1, 2, 3 by > > themselves. Slots 4 and 5 are lumped together, one IRQ for both. This > > ... > > That comment is in the section that talks about the bios interrupt > > assignment stuff. So, based on what you said, and the fact that it doesn't > > assign another IRQ to that slot, I'd bet that they just tacked on another > > slot, and didn't put a bridge chip on the board. (just a guess, I could be > > wrong of course. :) ) > so this is where I get a little confused... I thought in the past the > typical board limitation of 4 PCI slots was based on the LINE[ABCD] > situation. Early PCI MBs sometimes used LINEA for slot1, LINEB for > slot2, etc. I was thinking that now they route the LINEA pin from each > card to the LINE[ABCD] inputs of the PCI_ISA bridge chip, hence the magic > of the number 4. Is this so, or do these PCI slot/LINEA INTs go directly > to the MB ISA redirector hardware? If so, what is magic about 4 (slots)? > Stated another way, why does the 5th slot need to be shared? I thought it was more of a bus length thing, something about the number of loads on the bus. (standard disclaimers apply, it's really just a vague recollection, I'm sure someone on the list knows..) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Fri Jan 17 00:18:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA17094 for smp-outgoing; Fri, 17 Jan 1997 00:18:59 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA17073 for ; Fri, 17 Jan 1997 00:17:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id BAA16113 for ; Fri, 17 Jan 1997 01:14:15 -0700 Message-Id: <199701170814.BAA16113@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: smp@FreeBSD.ORG Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 00:26:39 MST." <199701170726.AAA15776@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 01:14:15 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > so this is where I get a little confused... I thought in the past the > typical board limitation of 4 PCI slots was based on the LINE[ABCD] > situation. Early PCI MBs sometimes used LINEA for slot1, LINEB for > slot2, etc. I was thinking that now they route the LINEA pin from each > card to the LINE[ABCD] inputs of the PCI_ISA bridge chip, hence the magic > of the number 4. Is this so, or do these PCI slot/LINEA INTs go directly > to the MB ISA redirector hardware? If so, what is magic about 4 (slots)? > Stated another way, why does the 5th slot need to be shared? doing some research I have concluded that the magic about '4' is that all the chipsets (Neptune,Triton,Natoma) have exactly 4 PCI-ISA redirection registers on them, probably because of the PCI LINE[ABCD] design. So they can only redirect to 4 distinct targets, requireing the "merging" of INTs when getting to slot 5 and above. I suspect that in all other areas it is really a unique PCI slot (wishful thinking?) Whether this limitation applies to the APIC I still don't know... When Peter and I were first getting his EISA disk controller working our experiments as to programming the redirector for edge/level, etc. were very confusing and inconclusive. If anyone has any insight to the specifics of the redirector/APIC connections on the MB, I would love to hear them. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Jan 17 09:58:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA16691 for smp-outgoing; Fri, 17 Jan 1997 09:58:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA16686 for ; Fri, 17 Jan 1997 09:58:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08699; Fri, 17 Jan 1997 10:44:02 -0700 From: Terry Lambert Message-Id: <199701171744.KAA08699@phaeton.artisoft.com> Subject: Re: Floating point probs? To: peter@spinner.dialix.com (Peter Wemm) Date: Fri, 17 Jan 1997 10:44:02 -0700 (MST) Cc: sysseh@devetir.qld.gov.au, smp@freebsd.org In-Reply-To: <199701170540.NAA03128@spinner.DIALix.COM> from "Peter Wemm" at Jan 17, 97 01:40:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > After perusing the list for a while I hear that "there are some > > floating point problems with the SMP code". What problems, and > > when do they arise (I'm thinking of buying the Gigabyte 586dx MB soon)? > > My personal feeling is that the problems are of the same order as the > Shuttle Challenger's problems. > > I don't really know how to fix it, because I have not researched how the > fpu interlocking works and really don't know what the right approach is. Call Richard Feynman's son. He will probably put your CPU in a glass of ice water while you discuss the problem in great gory detail... (Just another Challenger reference to match the first). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Fri Jan 17 10:03:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA16837 for smp-outgoing; Fri, 17 Jan 1997 10:03:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA16829 for ; Fri, 17 Jan 1997 10:03:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08712; Fri, 17 Jan 1997 10:49:23 -0700 From: Terry Lambert Message-Id: <199701171749.KAA08712@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: smp@csn.net (Steve Passe) Date: Fri, 17 Jan 1997 10:49:22 -0700 (MST) Cc: vanmaren@fast.cs.utah.edu, smp@freebsd.org In-Reply-To: <199701170702.AAA15623@clem.systemsix.com> from "Steve Passe" at Jan 17, 97 00:02:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The Tyan Titan Pro (you have the MP table) also has 5 PCI slots on > > ONE PCI bus. Two of the slots get mapped to the same int. > > However, the MPTABLE only had 4 listed -- I haven't investigated > > further (but the table is in ROM). > ^^^^^^^^^^^^^^^^^^^^^^^ > I have a theory about this, specifically that just because the mptable > program finds the table in "the BIOS", it doesn't mean that the data is > in ROM. Most modern MBs shadow the BIOS from ROM/FLASH to RAM for > speed improvements. This means that they could dynamically build the > MP table however they wanted. Note how we see the MP table for the ASUS > change when going from MP spec 1.1 to 1.4, even though it is at the > same address in the BIOS. Also note how it shows 1 PCI bus without > a PCI bridge card, but 2 with, and how the INT assignments change according > to card placement and BIOS settings. An engineer at Dell assured me that on at least one of their machines, the table was in ROM. This was after a discussion of the MPTable, and how it could be adversely affected by a memory test (back when people were talking about memory tests). He commented that he hadn't considered the possibility when advocating a memory test be done, since Dell places their tables in ROM (as is permitted by the spec). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Fri Jan 17 10:09:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA17016 for smp-outgoing; Fri, 17 Jan 1997 10:09:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA17006 for ; Fri, 17 Jan 1997 10:08:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08724; Fri, 17 Jan 1997 10:53:49 -0700 From: Terry Lambert Message-Id: <199701171753.KAA08724@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: ken@housing1.stucen.gatech.edu (Kenneth Merry) Date: Fri, 17 Jan 1997 10:53:49 -0700 (MST) Cc: drussell@internode.net, smp@freebsd.org In-Reply-To: <199701170707.CAA23020@housing1.stucen.gatech.edu> from "Kenneth Merry" at Jan 17, 97 02:07:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Too bad you can't just jumper things around like you can with ISA interrupts. > > My friends love this machine.... :-) > [ ... ] > > Yeah, in a way I miss the way that you could unambiguously hardwire > things to one specific interrupt, and not have to worry about some setup > program mucking things up. > > At least I have the ability to hardwire specific interrupts to > specific slots, though. The BIOS in this thing also lets you reserve > specific interrupts for "legacy" ISA cards. The rest of the interrupts are > fair game for the bios' PnP setup code. You guys are insane. The point of using PCI is to *never* have to worry about configuring cards so the software can find them; instead, the specification requires that the cards be unambiguously probeable. The ISA PnP crap doesn't work with legacy cards, but certainly works with on-board ISA-bridged components (which there shouldn't be any of because of their stupid limitations), and with newer cards. The BIOS in a PCI/ISA box should do the PnP for the ISA. In any case, having to jumper anything for any reason is insanely lazy hardware design. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Fri Jan 17 10:19:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA17325 for smp-outgoing; Fri, 17 Jan 1997 10:19:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA17314 for ; Fri, 17 Jan 1997 10:19:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA03220 for ; Fri, 17 Jan 1997 10:19:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08745; Fri, 17 Jan 1997 11:03:41 -0700 From: Terry Lambert Message-Id: <199701171803.LAA08745@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: smp@csn.net (Steve Passe) Date: Fri, 17 Jan 1997 11:03:41 -0700 (MST) Cc: ken@housing1.stucen.gatech.edu, smp@FreeBSD.ORG In-Reply-To: <199701170726.AAA15776@clem.systemsix.com> from "Steve Passe" at Jan 17, 97 00:26:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well, the manual isn't very revealing about whether there are > > actually one or two PCI busses on the board. The 5th slot is a a "shared" > > PCI/ISA slot, and it also has an ASUS MediaBus connector in line with the > > PCI connector. Here's what the board manual says about slot 5 and > > interrupts: > > > > "IMPORTANT: PCI Slots 4 & 5 share the same IRQ. If using PCI cards on both > > slots 4 & 5, make sure taht the drivers support "Share IRQ" or that one > > card does not need an IRQ assignment. Conflicts will arise on PCI Slots 4 > > & 5 taht will make the system unstable." > > so it appears that you might be able to put the 3940 into slot4 and the > vga into slot5, the SMC in any of the others, and have 2 free, usable slots Or... 'make sure that the drivers support "Share IRQ"', and you will also solve the problem without any of this additional crap. One caveat: the system may not "know" a card is inserted in slot 5 if there is not a card inserted in slot 4 (depending on how frobbed together the hardware is). > so this is where I get a little confused... I thought in the past the > typical board limitation of 4 PCI slots was based on the LINE[ABCD] > situation. Early PCI MBs sometimes used LINEA for slot1, LINEB for > slot2, etc. I was thinking that now they route the LINEA pin from each > card to the LINE[ABCD] inputs of the PCI_ISA bridge chip, hence the magic > of the number 4. Is this so, or do these PCI slot/LINEA INTs go directly > to the MB ISA redirector hardware? If so, what is magic about 4 (slots)? > Stated another way, why does the 5th slot need to be shared? The LINE[ABCD] situation is not the reason. The reason for 4 slots is the bus drivers couldn't handle more than 4 sources/sinks on a single chip. It's true that some designs used one line per slot (a *good* idea, IMO, since it means you can skip the sharing decode in the non-bridged case, and get a bit more speed out of the thing by servicing multiple slots concurrently). However, those boards were generally from the Intel Server Division; the boards they sold to the public (ie: most of the early PCI machines from most of the systems vendors like Dell, Gateway, etc., but not Compaq) were from the Intel OEM Products Division. The OEM Products Division boards *always* shared the same INT between all the slots. This pissed me off enough that I delayed buying a PCI machine for a long time. It used to be that FreeBSD couldn't handle more than one PCI card in one of these machines because the drivers couldn't do "shared". Since the FreeBSD drivers have since been fixed, I don't understand the "conflict"... is it that there are one or more drivers that *haven't* been fixed? All of the drivers should be able to share interrupts. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Fri Jan 17 10:38:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA18312 for smp-outgoing; Fri, 17 Jan 1997 10:38:38 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA18307 for ; Fri, 17 Jan 1997 10:38:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA19002; Fri, 17 Jan 1997 11:37:07 -0700 Message-Id: <199701171837.LAA19002@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: Terry Lambert cc: smp@FreeBSD.ORG Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 11:03:41 MST." <199701171803.LAA08745@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 11:37:06 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Terry said: > One caveat: the system may not "know" a card is inserted in slot 5 > if there is not a card inserted in slot 4 (depending on how frobbed > together the hardware is). I don't think we are having this problem. > ... It used to be that FreeBSD couldn't handle > more than one PCI card in one of these machines because the drivers > couldn't do "shared". > > Since the FreeBSD drivers have since been fixed, I don't understand > the "conflict"... is it that there are one or more drivers that > *haven't* been fixed? All of the drivers should be able to share > interrupts. This confuses me also. We were fighting several problems at the same time, so that might not really be the case, ie SHARING might NOT have been a problem. -- 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----- From owner-freebsd-smp Fri Jan 17 12:24:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA23734 for smp-outgoing; Fri, 17 Jan 1997 12:24:14 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA23726; Fri, 17 Jan 1997 12:24:11 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-2.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA02575 (5.67b/IDA-1.5); Fri, 17 Jan 1997 21:24:07 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id VAA06810; Fri, 17 Jan 1997 21:23:29 +0100 (CET) Message-Id: Date: Fri, 17 Jan 1997 21:22:08 +0100 From: se@freebsd.org (Stefan Esser) To: kmitch@weenix.guru.org (Keith Mitchell) Cc: hackers@freebsd.org, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP References: <199701150110.UAA00835@weenix.guru.org> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <199701150110.UAA00835@weenix.guru.org>; from Keith Mitchell on Jan 14, 1997 20:10:58 -0500 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 14, kmitch@weenix.guru.org (Keith Mitchell) wrote: > I am having a problem getting APIC_IO working on my Tyan Tomcat III > motherboard with SMP. I originally posted to the smp mailing list and > was advised to also post here (by Steve Passe). Since this appears to be a PCI and SMP related problem, I want to look into this from the PCI point of view. But I'm currently totally overloaded with work, and won't have any spare time to spend for a few more days :( I'll scan the other messages belonging to this thread, and will look for questions that have a quick answer. Everything else will have to wait, sorry ... Regards, STefan From owner-freebsd-smp Fri Jan 17 12:40:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA24480 for smp-outgoing; Fri, 17 Jan 1997 12:40:51 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA24475 for ; Fri, 17 Jan 1997 12:40:48 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-17.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA02586 (5.67b/IDA-1.5 for ); Fri, 17 Jan 1997 21:37:12 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id VAA06829; Fri, 17 Jan 1997 21:36:31 +0100 (CET) Message-Id: Date: Fri, 17 Jan 1997 21:35:11 +0100 From: se@freebsd.org (Stefan Esser) To: ken@housing1.stucen.gatech.edu (Kenneth Merry) Cc: smp@csn.net (Steve Passe), matt@lkg.dec.com, kmitch@weenix.guru.org, smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP References: <199701160321.UAA07607@clem.systemsix.com> <199701160610.BAA09539@housing1.stucen.gatech.edu> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <199701160610.BAA09539@housing1.stucen.gatech.edu>; from Kenneth Merry on Jan 16, 1997 01:10:49 -0500 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 16, ken@housing1.stucen.gatech.edu (Kenneth Merry) wrote: > Well, I'm not entirely sure why the SMC card was hanging the system, > but I do think it had a whole lot to do with the fact that ahc1 (the second > channel on the 3940UW) was using the *same* interrupt as the SMC card. As Interrupt sharing must be supported for PCI cards, and it does in the non-SMP case ... > Arlie Davis pointed out, the 3940 cards seem to steal an interrupt from the > next PCI slot down. In my case, the SMC card, when it was in, was in the > next PCI slot down from the 3940UW. This is one common scheme: INTB of slot 2 is connected to INTA of slot 1, INTC of 2 to INTB of 1 and so on ... This distributes the interrupt lines of a multi-function card (or a card with a PPB) over the range of interrupt lines assigned to (upto) three neighbour cards' INTA ... > Well, once I realized the 3940 was grabbing an interrupt, I tried > what Arlie suggested, and cleared a slot next to the 3940. I now have the > following setup: > > Slot 1: Matrox Millenium (IRQ 11) > Slot 2: Adaptec 3940UW (IRQ 10) > Slot 3: Empty (IRQ 9) > Slot 4: SMC 10/100 card (IRQ 15) > Slot 5: Empty (shares IRQ w/ slot 4) > > Well, *now* the APIC_IO/SMP_INVLTLB kernel works. I can boot up, > turn on both processors, etc., no problem. ahc1 now steals IRQ 9 from slot > 3, but since there's nothing there, there are no conflicts. I hard-coded > all of these interrupts to the slots in the BIOS. Hmmm, there shouldn't be any conflicts! But I did not check, whether shared interrupts do really work in the SMP case. There might be some range check preventing IRQs > 15 from being shared, for example, or other assumptions that fail ... > The bad thing, though, is that with this setup, it means I won't be > able to put anything in slot 3. And if I put anything in slot 5, it'll > have to be able to share an interrupt with the SMC card. Please allow for some time (a few days) to have me check this. > de0 rev 18 int a irq 19 on pci0:9 > Freeing (NOT implimented) irq 12 for ISA cards. > chip3 rev 2 on pci0:11 > Freeing (NOT implimented) irq 12 for ISA cards. > vga0 rev 1 int a irq 16 on pci0:12 > Freeing (NOT implimented) irq 11 for ISA cards. > ahc0 rev 0 int a irq 17 on pci1:4 > Freeing (NOT implimented) irq 10 for ISA cards. > ahc1 rev 0 int a irq 18 on pci1:5 > Freeing (NOT implimented) irq 9 for ISA cards. Hmmm, I seem to remember an implied 16 IRQ limit in the PCI code. This should be easy to fix, though ... Let me see: Please try again, with PCI_MAX_IRQ increased to 24 (see /sys/pci/pci.c). I don't have the time to verify, that this indeed the correct fix, but it may give a hint ... Regards, STefan From owner-freebsd-smp Fri Jan 17 13:07:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA25587 for smp-outgoing; Fri, 17 Jan 1997 13:07:01 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA25582; Fri, 17 Jan 1997 13:06:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA19748; Fri, 17 Jan 1997 14:06:33 -0700 Message-Id: <199701172106.OAA19748@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: se@freebsd.org (Stefan Esser) cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 21:35:11 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 14:06:32 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Hmmm, I seem to remember an implied 16 IRQ limit in the PCI code. > This should be easy to fix, though ... > > Let me see: > > Please try again, with PCI_MAX_IRQ increased to 24 (see /sys/pci/pci.c). > I don't have the time to verify, that this indeed the correct fix, but > it may give a hint ... I believe PCI_MAX_IRQ is properly increased to 24 in all the necessary places, I know it works properly in general as many of us are using PCI cards >IRQ15. /sys/pci/pcibus.h: #if defined( APIC_IO ) #define PCI_MAX_IRQ (24) #else #define PCI_MAX_IRQ (16) #endif /* APIC_IO */ -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Jan 17 13:22:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA26429 for smp-outgoing; Fri, 17 Jan 1997 13:22:57 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA26373; Fri, 17 Jan 1997 13:22:32 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-9.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA02759 (5.67b/IDA-1.5); Fri, 17 Jan 1997 22:22:20 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id WAA06957; Fri, 17 Jan 1997 22:22:21 +0100 (CET) Message-Id: Date: Fri, 17 Jan 1997 22:22:21 +0100 From: se@freebsd.org (Stefan Esser) To: smp@csn.net (Steve Passe) Cc: se@freebsd.org (Stefan Esser), smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP References: <199701172106.OAA19748@clem.systemsix.com> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <199701172106.OAA19748@clem.systemsix.com>; from Steve Passe on Jan 17, 1997 14:06:32 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 17, smp@csn.net (Steve Passe) wrote: > I believe PCI_MAX_IRQ is properly increased to 24 in all the necessary places, > I know it works properly in general as many of us are using PCI > cards >IRQ15. Ok. I forgot about this patch ... I still think there is a problem with the installation of the shared PCI interrupt handler, if I read the log messages corerctly. Are there actually motherboards, that have a PCI BIOS capable of assigning memory and I/O mappings to devices behind PPBs, but fail to setup the interrupt routing correctly ? I've seen a few MBs, that probe at most two levels of bridges deep (i.e. do support a AH3940 behind another PPB, but not in a PCI bus extension box, which got two PPBs (back to back) between its slots and the primary PCI bus). Regards, STefan From owner-freebsd-smp Fri Jan 17 13:58:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA29213 for smp-outgoing; Fri, 17 Jan 1997 13:58:53 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA29192; Fri, 17 Jan 1997 13:58:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA20041; Fri, 17 Jan 1997 14:58:23 -0700 Message-Id: <199701172158.OAA20041@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: se@freebsd.org (Stefan Esser) cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 22:22:21 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 14:58:23 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, STefan wrote: > I still think there is a problem with the installation > of the shared PCI interrupt handler, if I read the log > messages corerctly. I tend to agree, and we would want to ask Kenneth Merry to run tests of that for us as his system now works with the 3940 in all other respects. By this I mean I believe he can now run the SMP kernel with APIC_IO enabled, and the 3940 booting the system properly. --- > Are there actually motherboards, that have a PCI BIOS > capable of assigning memory and I/O mappings to devices > behind PPBs, but fail to setup the interrupt routing > correctly ? That is still an unknown for the system that currently fails with the 3940. The primary issue is that the BIOS fails to create accurate information in the MP table it builds (or the problem might be that the table is hard coded in the ROM and thus CAN'T build info about a bridged PCI card) I just sent another patch to its owner for testing as to whether the routing is there even though the info isn't, Ill post as soon as we know. My best guess is that the physical routing is there, but that the MP table is incomplete. -- 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----- From owner-freebsd-smp Fri Jan 17 18:48:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA16882 for smp-outgoing; Fri, 17 Jan 1997 18:48:54 -0800 (PST) Received: from weenix.guru.org (unix.guru.org [198.82.200.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA16875 for ; Fri, 17 Jan 1997 18:48:52 -0800 (PST) Received: (from kmitch@localhost) by weenix.guru.org (8.8.4/8.8.4) id VAA01165; Fri, 17 Jan 1997 21:48:43 -0500 (EST) Date: Fri, 17 Jan 1997 21:48:43 -0500 (EST) From: Keith Mitchell Message-Id: <199701180248.VAA01165@weenix.guru.org> To: smp@csn.net (Steve Passe) Cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP X-Newsreader: TIN [UNIX 1.3 unoff BETA release 961025] Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > That is still an unknown for the system that currently fails with the > 3940. The primary issue is that the BIOS fails to create accurate information > in the MP table it builds (or the problem might be that the table is hard coded > in the ROM and thus CAN'T build info about a bridged PCI card) I just > sent another patch to its owner for testing as to whether the routing is there > even though the info isn't, Ill post as soon as we know. My best guess is that > the physical routing is there, but that the MP table is incomplete. Steve, I think the MPtable is in ROM. Now that I think about it, it displayed two CPUs when I ran mptable even when only one was installed and the APIC was jumpered off. From owner-freebsd-smp Fri Jan 17 20:28:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA20220 for smp-outgoing; Fri, 17 Jan 1997 20:28:17 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id UAA20214 for ; Fri, 17 Jan 1997 20:28:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA21887; Fri, 17 Jan 1997 21:27:54 -0700 Message-Id: <199701180427.VAA21887@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: Keith Mitchell cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 21:48:43 EST." <199701180248.VAA01165@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 21:27:54 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > That is still an unknown for the system that currently fails with the > > 3940. The primary issue is that the BIOS fails to create accurate information > > in the MP table it builds (or the problem might be that the table is hard coded > > in the ROM and thus CAN'T build info about a bridged PCI card) I just > > sent another patch to its owner for testing as to whether the routing is there > > even though the info isn't, Ill post as soon as we know. My best guess is that > > the physical routing is there, but that the MP table is incomplete. > > Steve, > > I think the MPtable is in ROM. Now that I think about it, it displayed two > CPUs when I ran mptable even when only one was installed and the APIC was > jumpered off. > I think the evidence supports this conclusion in several ways, and this would explain why the MP table has no clues about the bridged card. However since the card works when run thru the regular ICUs is suggests that the BIOS does get the PCI bus setup properly, and thus that we should be able to make it work via the APIC unless they did something bogus in the design of the APIC subsystem. I was hopeful that that last patch I sent would do the trick. Still would like to see the console dump I requested for clues... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Jan 17 20:34:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA20405 for smp-outgoing; Fri, 17 Jan 1997 20:34:51 -0800 (PST) Received: from trapdoor.aracnet.com (root@trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA20399 for ; Fri, 17 Jan 1997 20:34:47 -0800 (PST) Received: from cbrowni2-home (ppp-r29.aracnet.com [205.238.13.31]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id UAA15556 for ; Fri, 17 Jan 1997 20:33:39 -0800 Message-ID: <32E04E41.5D04@aracnet.com> Date: Fri, 17 Jan 1997 20:14:57 -0800 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.01 (WinNT; U) MIME-Version: 1.0 To: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP References: <199701170707.CAA23020@housing1.stucen.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There are only four IRQ's for 5 slots. Slots 4 and 5 share the > same IRQ. So in order to have cards in both 4 and 5, I would assume that > the cards would have to be able to share interrupts, or one of the cards > would just not use an interrupt. (like a video card, perhaps) This is the > setup I have now, it seems to work fine: > > Slot 1: Adaptec 3940UW (IRQ 11) > Slot 2: Matrox Millenium (IRQ 10) > Slot 3: Empty (IRQ 9) > Slot 4: SMC 10/100 card (IRQ 15) > Slot 5: Empty (shares IRQ w/ slot 4) > > The second channel of the 3940 grabs IRQ 10, and video still works > fine. Why not place the 3940UW in slot 4. That way, it will share an interrupt with the other channel of the 3940UW. It should be given that this card can share an interrupt with itself. I believe I have used this card in this configuration. Then you could also move the Millenium to Slot 5 and still have two empty, USABLE, PCI slots. I am pretty sure that the Millenium doesn't use any interrupt (as most video cards don't), so this should be a safe configuration. Personally, I can't believe that they would design a MB with hardwired interrupts. You should be able to have a PCI slot without ANY interrupt assigned. In addition, they all use INTA? That is kinda a waste. Sounds like that kinda kludged the interrupt mapping into the system. Chris From owner-freebsd-smp Fri Jan 17 20:41:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA20706 for smp-outgoing; Fri, 17 Jan 1997 20:41:27 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA20699; Fri, 17 Jan 1997 20:41:17 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id XAA06172; Fri, 17 Jan 1997 23:41:04 -0500 (EST) From: Kenneth Merry Message-Id: <199701180441.XAA06172@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701172158.OAA20041@clem.systemsix.com> from Steve Passe at "Jan 17, 97 02:58:23 pm" To: smp@csn.net (Steve Passe) Date: Fri, 17 Jan 1997 23:41:03 -0500 (EST) Cc: se@freebsd.org, smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > STefan wrote: > > I still think there is a problem with the installation > > of the shared PCI interrupt handler, if I read the log > > messages corerctly. > > I tend to agree, and we would want to ask Kenneth Merry to run tests of that > for > us as his system now works with the 3940 in all other respects. By this I mean > I believe he can now run the SMP kernel with APIC_IO enabled, and the 3940 > booting the system properly. Yeah, things work fine with the APIC_IO kernel, or at least it boots on the 3940 the system comes up normally, etc... I haven't really flogged it with APIC_IO enabled. (since X only runs without it enabled) Just let me know if there are any tests you want me to run and I'll give 'em a try. Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Fri Jan 17 20:59:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA21269 for smp-outgoing; Fri, 17 Jan 1997 20:59:49 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA21262 for ; Fri, 17 Jan 1997 20:59:47 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id XAA06284; Fri, 17 Jan 1997 23:59:42 -0500 (EST) From: Kenneth Merry Message-Id: <199701180459.XAA06284@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <32E04E41.5D04@aracnet.com> from Chris Browning at "Jan 17, 97 08:14:57 pm" To: cbrown@aracnet.com Date: Fri, 17 Jan 1997 23:59:41 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Browning wrote... > > There are only four IRQ's for 5 slots. Slots 4 and 5 share the > > same IRQ. So in order to have cards in both 4 and 5, I would assume that > > the cards would have to be able to share interrupts, or one of the cards > > would just not use an interrupt. (like a video card, perhaps) This is the > > setup I have now, it seems to work fine: > > > > Slot 1: Adaptec 3940UW (IRQ 11) > > Slot 2: Matrox Millenium (IRQ 10) > > Slot 3: Empty (IRQ 9) > > Slot 4: SMC 10/100 card (IRQ 15) > > Slot 5: Empty (shares IRQ w/ slot 4) > > > > The second channel of the 3940 grabs IRQ 10, and video still works > > fine. > Why not place the 3940UW in slot 4. That way, it will share an > interrupt with the other > channel of the 3940UW. It should be given that this card can share an > interrupt with itself. > I believe I have used this card in this configuration. Then you could > also move the Millenium to > Slot 5 and still have two empty, USABLE, PCI slots. I am pretty sure > that the Millenium doesn't > use any interrupt (as most video cards don't), so this should be a safe > configuration. Hmm, yeah, that might well work. It's working fine as-is, though. I'll probably get around to testing things with at least 4 slots full before too long, though. > Personally, I can't believe that they would design a MB with hardwired > interrupts. You should be > able to have a PCI slot without ANY interrupt assigned. In addition, > they all use INTA? That is > kinda a waste. Sounds like that kinda kludged the interrupt mapping > into the system. Well, actually, I hardwired the interrupts (11, 10, 9, etc.) in the BIOS. Normally they are automatically assigned, I just did them myself so I would know which interrupt was getting assigned to which slot. I could probably go back to automatic assignment without any problems. All of the slots do use INTA, though. (the manual is fairly clear on that) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Fri Jan 17 21:24:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA23238 for smp-outgoing; Fri, 17 Jan 1997 21:24:26 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA23224 for ; Fri, 17 Jan 1997 21:24:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA22187; Fri, 17 Jan 1997 22:24:00 -0700 Message-Id: <199701180524.WAA22187@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: cbrown@aracnet.com cc: smp@FreeBSD.ORG Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Fri, 17 Jan 1997 20:14:57 PST." <32E04E41.5D04@aracnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Jan 1997 22:24:00 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > There are only four IRQ's for 5 slots. Slots 4 and 5 share the > > same IRQ. So in order to have cards in both 4 and 5, I would assume that > > the cards would have to be able to share interrupts, or one of the cards > > would just not use an interrupt. (like a video card, perhaps) This is the > > setup I have now, it seems to work fine: > > > > Slot 1: Adaptec 3940UW (IRQ 11) > > Slot 2: Matrox Millenium (IRQ 10) > > Slot 3: Empty (IRQ 9) > > Slot 4: SMC 10/100 card (IRQ 15) > > Slot 5: Empty (shares IRQ w/ slot 4) > > > > The second channel of the 3940 grabs IRQ 10, and video still works > > fine. > > Why not place the 3940UW in slot 4. That way, it will share an > interrupt with the other > channel of the 3940UW. It should be given that this card can share an > interrupt with itself. > I believe I have used this card in this configuration. Then you could > also move the Millenium to > Slot 5 and still have two empty, USABLE, PCI slots. this is the conclusion I jumped to but it (I think) wont do the trick. I believe this is what is actually done on the MB: slot1, PCI INTA -> PIRQ0 slot1, PCI INTB -> PIRQ1 slot1, PCI INTC -> PIRQ2 slot1, PCI INTD -> PIRQ3 slot2, PCI INTA -> PIRQ1 slot2, PCI INTB -> PIRQ2 slot2, PCI INTC -> PIRQ3 slot2, PCI INTD -> PIRQ0 slot3, PCI INTA -> PIRQ2 slot3, PCI INTB -> PIRQ3 slot3, PCI INTC -> PIRQ0 slot3, PCI INTD -> PIRQ1 slot4, PCI INTA -> PIRQ3 slot4, PCI INTB -> PIRQ0 slot4, PCI INTC -> PIRQ1 slot4, PCI INTD -> PIRQ2 slot5, PCI INTA -> PIRQ3 slot5, PCI INTB -> PIRQ0 slot5, PCI INTC -> PIRQ1 slot5, PCI INTD -> PIRQ2 Looking at slots 4 & 5 above you can see how a card in slot4 OR slot5 would have its PCI INTB sent to PIRQ0, effectively slot1's INTA. PIRQ# are the PCI-ISA irq redirection channels on the MB chipset. There are exactly 4 such channels on the Neptune/Triton/Natoma chipsets. These are how the PCI INTs get magically sent to the ISA bus. They have nothing to do (that I can determine) with how the PCI INTs get to the IO APIC, that (sometimes) is a different piece of silicon. For each PIRQ# there is a redirection register that can be programmed for any of the usable ISA INTs (ie NOT 0,1,2,6,8), sending the associated PCI INT to the programmed ISA INT pin (ie the 8259 channel# pin). The bottom line is that given the 4 PIRQ channels of the Neptune/Triton/Natoma chipsets you can only have 4 distinct PCI INTs on a MB when using the traditional 8259 IUCs, unless the MB maker adds additional redirection circuitry (unlikely). However the IO APIC needs no such redirection circuit and has 24 channels (Neptune only has 16) so more distinct PCI INTs could be had in such a MB. For instance my SMP board has 21: 16 ISA, 4 PCI, and a system management INT (ie green power managment). --- > Personally, I can't believe that they would design a MB with hardwired > interrupts. You should be > able to have a PCI slot without ANY interrupt assigned. In addition, > they all use INTA? That is > kinda a waste. Sounds like that kinda kludged the interrupt mapping > into the system. I don't know where this style mapping came from but it seems (in my limited knowledge) to be common on MBs these days. I suppose it was meant to make life easier for end users, not having to strap cards for specific INT pins. I would think it possible for a card maker to strap both INT[AB] of a bridged card to PCI INTA (as an option) allowing the use of only 1 PCI INT line in an OS that can handle SHARED INTs, but perhaps there is something about the PCI spec that disallows this? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Jan 17 23:29:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA29534 for smp-outgoing; Fri, 17 Jan 1997 23:29:12 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA29529 for ; Fri, 17 Jan 1997 23:29:10 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id CAA07347; Sat, 18 Jan 1997 02:28:44 -0500 (EST) From: Kenneth Merry Message-Id: <199701180728.CAA07347@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701180524.WAA22187@clem.systemsix.com> from Steve Passe at "Jan 17, 97 10:24:00 pm" To: smp@csn.net (Steve Passe) Date: Sat, 18 Jan 1997 02:28:43 -0500 (EST) Cc: cbrown@aracnet.com, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, with all the talk of interrupts, I got a bit curious and did a few tests with my system to see how things would work. In summary, the way slots go on my system, according to the manual is that PCI slots 1-3 have unique interrupts, and slots 4 and 5 share the same interrupt. (Steve gave a much more detailed assessment of how things work...) Before I started these tests, my original, working (i.e. for Uniprocessor, APIC_IO and non-APIC_IO kernels) configuration looked like this: Slot 1: Adaptec 3940UW (IRQ 11) Slot 2: Matrox Millenium (IRQ 10) Slot 3: no card (IRQ 9) Slot 4: SMC 10/100 (IRQ 14) Slot 5: no card (shares IRQ 14 w/ slot 4) I hard-coded each of the above IRQ values in the BIOS for each slot. I then changed things around so that all of the interrupt assignments were autoconfigured by the BIOS. On boot, the BIOS prints out the interrupt assignments and class names of the various PCI boards. Here's the way it assigned the interrupts: Slot 1: SMC 10/100 (IRQ 5) Slot 4: Adaptec 3940UW (IRQ 14 for channel 1, IRQ 3 for channel 2) Slot 5: Matrox Millenium (IRQ 3) With the BIOS set to enable MP spec v1.4, I got the following results: Uniprocessor: works fine Non-APIC_IO SMP: hangs(1) APIC_IO SMP: hangs(1) 1) Both kernels would hang after the following (approx.) message: BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value With the BIOS set to enable MP spec v1.1, I got the following results: Uniprocessor: works fine Non-APIC_IO SMP: works fine APIC_IO SMP: hangs(2) 2) The APIC_IO kernel would hang right before the kernel should go over to init. Ctrl-Alt-Del did work to reboot it at that point. The only difference between the above configuration and my old configuration was that I let the BIOS automatically configure the interrupts on the cards. So things seemed to work better when I manually configured the interrupts. Perhaps there was a conflict? I have disabled the on board second serial port (IRQ 3), and the LPT port (IRQ 7), and the on board IDE controllers (IRQ 14 + 15). I do, however, have a Gravis Ultrasound PnP Pro. Theoretically, the BIOS would be able to work out any potential interrupt conflicts, since it is a PnP card... So, just to make it interesting, I moved the cards around to the following configuration: Slot 1: SMC 10/100 (autoconfig by BIOS) Slot 2: no card (autoconfig by BIOS) Slot 3: no card (autoconfig by BIOS) Slot 4: Adaptec 3940UW (autoconfig by BIOS) Slot 5: Matrox Millenium (autoconfig, shares IRQ w/ slot 4) This was the most difficult combination of things that I could think of, or rather close to it. I guess it would be more accurate to say that this was the most practical way to assign the slots, suggested by both Steve and Chris. The BIOS assigned the interrupts like this: Slot 1: SMC 10/100 (IRQ 14) Slot 4: Adaptec 3940UW (IRQ 3 for channel 1, IRQ 14 for channel 2) Slot 5: Matrox Millenium (IRQ 3) With MP spec v1.4 enabled in the BIOS, I got the following results: Uniprocessor: works fine Non-APIC_IO SMP: hangs(1) APIC_IO SMP: hangs(1) Windows NT 4.0: works fine 1) Both kernels would hang after the following (approx.) message: BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value With MP spec v1.1 enabled in the BIOS, I got the following results: Uniprocessor: works fine Non-APIC_IO SMP: works fine APIC_IO SMP: hangs(2) 2) The APIC_IO kernel would hang right before the kernel should go over to init. Ctrl-Alt-Del did work to reboot it at that point. So, in short, for the new slot configuration, I get the same results as I did for the old slot configuration. Once again, I tried hardwiring the interrupts to the various slots. here is the way I configured it: Slot 1: SMC 10/100 (IRQ 11) Slot 2: no card (IRQ 10) Slot 3: no card (IRQ 9) Slot 4: Adaptec 3940UW (IRQ 14) Slot 5: Matrox Millenium (shares IRQ 14 w/ slot 4) The BIOS printout confirmed that the interrupts were assigned as follows: Slot 1: SMC 10/100 (IRQ 11) Slot 4: Adaptec 3940UW (IRQ 14 for channel 1, IRQ 11 for channel 2) Slot 5: Matrox Millenium (IRQ 14) And with MP spec v1.4 enabled in the BIOS, I got the following results: Uniprocessor: works fine Non-APIC_IO SMP: works fine APIC_IO SMP: works fine All I can say is go figure. In all cases, the Uniprocessor kernel works without a hitch. The APIC_IO kernel has trouble with the MP v1.1 spec. Both versions of the SMP kernel didn't work when the system assigned the interrupts to the PCI cards. Things did work when I assigned interrups in the 11-10-9-14 order. Well, at least now I am fairly confident that I'll be able to add two more cards to the system and get them working. If anyone wants dmesg or mptable or whatever outputs for one (or more?) of these configurations, let me know. Perhaps this will help in understanding how this board works... Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Fri Jan 17 23:33:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA29663 for smp-outgoing; Fri, 17 Jan 1997 23:33:48 -0800 (PST) Received: from relay.internode.net (mail.internode.net [198.161.228.50]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA29658 for ; Fri, 17 Jan 1997 23:33:45 -0800 (PST) Received: from [198.161.228.109] by relay.internode.net (SMTPD32-3.02) id A90F86F010C; Sat, 18 Jan 1997 00:17:35 -0700 Message-Id: <1.5.4.32.19970118074328.00707424@internode.net> X-Sender: drussell@internode.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 00:43:28 -0700 To: cbrown@aracnet.com, smp@freebsd.org From: Doug Russell Subject: Re: Adaptec 3940UW and SMP Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:14 PM 1/17/97 -0800, Chris Browning wrote: >Why not place the 3940UW in slot 4. That way, it will share an interrupt with >the other channel of the 3940UW. It should be given that this card can share >an interrupt with itself. I believe I have used this card in this >configuration. Then you could also move the Millenium to Slot 5 and still have >two empty, USABLE, PCI slots. I am pretty sure that the Millenium doesn't >use any interrupt (as most video cards don't), so this should be a safe >configuration. Personally, I can't believe that they would design a MB with >hardwired interrupts. You should be able to have a PCI slot without ANY >interrupt assigned. In addition, they all use INTA? That is >kinda a waste. Sounds like that kinda kludged the interrupt mapping >into the system. (Anyone who knows more about this than I do, feel free to correct me here...) I don't think that is right. This is how I understand the interrupt stuff on the PCI bus: On the physical connector, pin A06 is INTA, A07 is INTC, B07 is INTB, and B08 is INTD. BUT, each physical connector rotates the int down one spot. Hmmm... How can I illustrate this. Lets try this..... the ---- lines represent physical traces on the board, and the INTA..INTD represent the name of the PHYSICAL PIN on the connector. (even though they move on my chart below, I am meaning to represent what the CARD sees as INTA..INTD....) SLOT1 SLOT2 SLOT3 SLOT4 IRQ ON CHIPSET INTA----INTD----INTC----INTB--------> PCI FIRST IRQ INTB----INTA----INTD----INTC--------> PCI SECOND IRQ INTC----INTB----INTA----INTD--------> PCI THIRD IRQ INTD----INTC----INTB----INTA--------> PCI FOURTH IRQ Take hypothetical PCI Network card Bob. Bob always uses IRQA of it's slot. Now, if we put Bob in slot 1, it uses the FIRST IRQ. If we put in slot 2, it uses the SECOND IRQ, etc. Now, lets say Bob had an IRQ select jumper (as does an early DEC DC21x4 based card that I use in one of my servers here in the house) that lets you select A, B, C, OR D as the interrupt line to use. If you set this jumper to A, and Bob is in Slot 1, it uses the FIRST IRQ. If you put it in slot 2, jumpered to A, it uses the SECOND IRQ. Slot 3, Jumpered A, uses the THIRD... etc. If you jumper it to B in slot 1, it will use the SECOND IRQ. If you jumper it to B in slot 2, it will use the THIRD IRQ... Again, correct me if I'm wrong, anyone. Now, the 3490 card apparently uses BOTH the INTA and INTB pins of it's slot. Therefore, if you put it in slot 1, it uses the FIRST and SECOND interrupt lines. If you put it in slot 2, it uses SECOND and THIRD. If you put it in slot 4, it uses the FOURTH and *FIRST*.. By this logic, if you put the 3940 in a fifth slot (and the fifth slot appears to be effectively a duplicate connector to slot 4 in this case), it will behave exactly as in slot 4, and again use the FOURTH and FIRST line. Here in lies the catch. Because it doesn't physically have a little finger that reaches over and grabs the INTA line (pin A6, remember) of the next slot over, it won't help to put it in slot 4. It will still use the FOURTH and FIRST lines, because INTB of slot 4 is the FIRST interrupt line. As far as I can tell, the only way to be able to put a card in the slot next to the 3940 (this INCLUDES PUTTING A CARD IN SLOT 1 if the 3940 is in slot 4/5) is if the drivers can share the INT, or if the card next down the chain doesn't use an INT at all (as I assume video cards, for example, usually don't). Does this make any sense, everyone? Or am I out to lunch? >configuration. Personally, I can't believe that they would design a MB with >hardwired interrupts. You should be able to have a PCI slot without ANY Actually, when I look at it, what SHOULD have been done, is to have a seperate interrupt line (or a couple of lines... whatever) go to each physical socket from the chip which handles the interrupts. The chip then should route IRQs accordingly to each slot as required. My brain hurts. :-) Later...... From owner-freebsd-smp Sat Jan 18 01:33:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA03563 for smp-outgoing; Sat, 18 Jan 1997 01:33:10 -0800 (PST) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA03558 for ; Sat, 18 Jan 1997 01:33:06 -0800 (PST) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.4/8.8.4) id EAA10357; Sat, 18 Jan 1997 04:33:03 -0500 (EST) From: Kenneth Merry Message-Id: <199701180933.EAA10357@housing1.stucen.gatech.edu> Subject: Re: Adaptec 3940UW and SMP In-Reply-To: <199701180728.CAA07347@housing1.stucen.gatech.edu> from Kenneth Merry at "Jan 18, 97 02:28:43 am" To: ken@housing1.stucen.gatech.edu (Kenneth Merry) Date: Sat, 18 Jan 1997 04:33:02 -0500 (EST) Cc: smp@csn.net, cbrown@aracnet.com, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Kenneth Merry wrote... > > Well, with all the talk of interrupts, I got a bit curious and did > a few tests with my system to see how things would work. In summary, the > way slots go on my system, according to the manual is that PCI slots 1-3 > have unique interrupts, and slots 4 and 5 share the same interrupt. (Steve > gave a much more detailed assessment of how things work...) > > Before I started these tests, my original, working (i.e. for > Uniprocessor, APIC_IO and non-APIC_IO kernels) configuration looked like > this: > > Slot 1: Adaptec 3940UW (IRQ 11) > Slot 2: Matrox Millenium (IRQ 10) > Slot 3: no card (IRQ 9) > Slot 4: SMC 10/100 (IRQ 14) > Slot 5: no card (shares IRQ 14 w/ slot 4) > > I hard-coded each of the above IRQ values in the BIOS for each > slot. > > I then changed things around so that all of the interrupt assignments > were autoconfigured by the BIOS. > > On boot, the BIOS prints out the interrupt assignments and class > names of the various PCI boards. Here's the way it assigned the > interrupts: > > Slot 1: SMC 10/100 (IRQ 5) > Slot 4: Adaptec 3940UW (IRQ 14 for channel 1, IRQ 3 for channel 2) > Slot 5: Matrox Millenium (IRQ 3) I made a mistake here, it should actually be: Slot 1: Adaptec 3940UW (IRQ 14 for channel 1, IRQ 3 for channel 2) Slot 2: Matrox Millenium (IRQ 3) Slot 4: SMC 10/100 (IRQ 5) Steve gets credit for pointing out the brain-o. :) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Sat Jan 18 10:28:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA22918 for smp-outgoing; Sat, 18 Jan 1997 10:28:45 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA22911; Sat, 18 Jan 1997 10:28:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA27932; Sat, 18 Jan 1997 11:28:27 -0700 Message-Id: <199701181828.LAA27932@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: smp@freebsd.org cc: se@freebsd.org (Stefan Esser), Keith Mitchell , Kenneth Merry Subject: Adaptec 3940UW and SMP, Summary #2 Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 18 Jan 1997 11:28:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, [ my mailer burped so I don't know if this was sent or not, please excuse if its a duplicate! ] Keith Mitchel reports his 3940 now working with the latest patches I sent him, so now both systems work with the 3940. The other system (Kenneth Merry) has some problems when allowing the BIOS to autoconfigure, but hand-selecting the INT values can come up with a system that works (new net card is also hanging but reason for that is not known yet, probably just another flavor of the previous conflicts...) There was discussion during this thread of there possible being a problem with shared PCI INTs and SMP. That appears to NOT be the case. The problems we actually saw were based on other subtle facts. We have demonstrated working SHARED PCI INTs with these systems once getting around the TRUE problems. Thanx to Keith and Ken for all their help running tests, and everyone else who contributed! --------------------------- So a list of known problems. I invented a new tag for inclusion in mail to allow easy searches of the SMP mail database: SMP_PROBLEM. This tag should only be applied to a problem THE FIRST TIME it is reported. Ie, I am looking for something that will "grep" a list of know problems. Once you have found a problem of interest you can grep for that problems name to find other references to it. This brings up the issue of when we should start to use send-pr to track SMP bugs??? --- SMP_PROBLEM: PnP board failure PnP boards can cause problems as I have not yet implimented code to "undirect" PCI INTs when sent to the APIC. Since an upper ( >15 ) INT is registered in place of the original ( <=15 ) the original may be assigned later by a PnP card. BUT the lower INT line is NOT un-redirected. This means both the PCI hardware (via the redirect hardware) AND the PnP card are yanking on the same lower INT line, causing random problems. solution: disable the PnP aspects of a board, use the BIOS "legacy ISA" settings. --- SMP_PROBLEM: static (ROM based) MP tables and PCI bridge cards. Some(most?) BIOS have a hard-coded MP table in ROM, meaning that bridged PCI cards and other complex PCI setups will NOT be properly described in the MP table. As such, insufficient info exists in the table to properly setup the APIC for these cards. solution: I got around this by examining the boot output and MP table, then hacking a patch for mp_machdep.c to "do the good thing" when handed bad info from the MP table during boot. This solution is specific to ONE MB with ONE specific PCI bridge card (3940) placed in a SPECIFIC PCI slot. So obviously it ain't the right solution. This solution can be applied to any other situations that require it if necessary in the short term. In the long term this will have to be handled by either "ROGUE" card coding, or possibly analyzing the PCI system ourselves and modifying our in-core MP table as appropriate. This "modification" is probably the correct approach as I expect to see alot of "funky" MP tables in the future. The spec just leaves too much to the imagination! -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Jan 18 11:07:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA24097 for smp-outgoing; Sat, 18 Jan 1997 11:07:30 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA24090 for ; Sat, 18 Jan 1997 11:07:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA28115 for ; Sat, 18 Jan 1997 12:07:21 -0700 Message-Id: <199701181907.MAA28115@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: smp@freefall.freebsd.org Subject: SMP_PROBLEM: BIOS needs MP spec 1.4 setting In-reply-to: Your message of "Sat, 18 Jan 1997 11:28:26 MST." <199701181828.LAA27932@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jan 1997 12:07:21 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I forgot to document another problem we encountered during the 3940 thread: --- SMP_PROBLEM: BIOS needs MP spec 1.4 setting we have discoverd that some BIOS have a setting for which version of the MP spec to use: 1.1 or 1.4. When such a setting is available 1.4 should be used. solution: set BIOS to MP spec 1.4 when available. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Jan 18 12:08:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26358 for smp-outgoing; Sat, 18 Jan 1997 12:08:24 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26348 for ; Sat, 18 Jan 1997 12:08:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA28446 for ; Sat, 18 Jan 1997 13:08:06 -0700 Message-Id: <199701182008.NAA28446@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: smp@freefall.freebsd.org Subject: SMP_PROBLEM: systems with >1 PCI bus may fail In-reply-to: Your message of "Sat, 18 Jan 1997 12:07:21 MST." <199701181907.MAA28115@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jan 1997 13:08:06 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, SMP_PROBLEM: systems with >1 PCI bus may fail mp spec appendix D.2 specifies that when MORE than 1 PCI bus exists the PCI busses should be assigned IDs first, using actual PCI bus numbers. Then ids are assigned to other busses using whatever numbers are free. BIOS with ONLY ONE PCI bus on the MOTHERBOARD often list the ISA/EISA bus first, thus makeing the one and only PCI bus have ID 1. When a PCI bridge card exists in the system another PCI bus then exists, causing the PCI bus numbering (ie ID #s) to be incorrect. Even when no such card exists, having the ISA bus first causes the PCI bus id to NOT match the actual PCI bus #. This makes identifying PCI bus:device:int info from the MP table INTs section difficult (prone to error). To work around this problem the current code ignores the bus ID when identifying PCI INT associations, causing possible errors with multiple PCI bus systems. solution: 1: reorder the bus ids and the bus id entries in the INT section of the MP table to reflect true PCI bus semantics. 2: start using the bus id fields in the lookups. this will require additional code in sys/i386/i386/mp_machdep.c and possibly some sys/pci modules. see MP spec v1.4, D.2 & D.3 for details on required format. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Jan 18 12:12:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26676 for smp-outgoing; Sat, 18 Jan 1997 12:12:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26671 for ; Sat, 18 Jan 1997 12:12:36 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA12287; Sat, 18 Jan 1997 12:57:47 -0700 From: Terry Lambert Message-Id: <199701181957.MAA12287@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: ken@housing1.stucen.gatech.edu (Kenneth Merry) Date: Sat, 18 Jan 1997 12:57:46 -0700 (MST) Cc: cbrown@aracnet.com, smp@freebsd.org In-Reply-To: <199701180459.XAA06284@housing1.stucen.gatech.edu> from "Kenneth Merry" at Jan 17, 97 11:59:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Why not place the 3940UW in slot 4. That way, it will share an > > interrupt with the other channel of the 3940UW. > > Hmm, yeah, that might well work. It's working fine as-is, though. > I'll probably get around to testing things with at least 4 slots full > before too long, though. The PCI channels are not allocated that way. They are allocated this way: ,-. ,-. ,-. ,-. ,-. A ----| |-. ,-| |-. ,-| |-. ,-| |--------| | |s| \ / |s| \ / |s| \ / |s| |s| B ----|l|-. `/---|l|-. `/---|l|-. `/---|l|--------|l| |o| \/ |o| \/ |o| \/ |o| |o| C ----|t|-./`----|t|-./`----|t|-./`----|t|--------|t| |1| /\ |2| /\ |3| /\ |4| |5| D ----| |- `----| |- `----| |- `----| |--------| | `-' `-' `-' `-' `-' This is called "daisy-chaining". A PCI card using one interrupt always takes connector 'A', unless some idiot board designer out-clevers himself. A PCI card using two interrupts always takes connectors 'A' and connector 'B'. A 3940 in slot 1 will take A+B, slot 2 will take D+A, slot 3 will take C+D, and slot 4 (or slot 5) will take B+C. Technically, the thing does *NOT* steal the interrupt "belonging" to the next slot. Many (older) PCI cards will allow you to jumper the board (or use NVRAM settings) so that the card will take connector 'A', 'B', 'C', or 'D'. Many stupid motherboard designs (especially older boards from the Intel OEM products division) didn't daisy-chain. Without the daisy-chaining, cards inserted in any slot would always allocate 'A'. This is stupid because shared interrupts are stupid: if you have multiple devices on the same interrupt, then you must query each device using the interrupt to ask it "did you generate this interrupt?". In addition, you must service the interrupts for the sharing devices *consecutively*, instead of *concurrently*. For an SMP system this is wasteful, since it means you can't service one of two concurrent interrupts on a share line on different processors. A PCI chipset design is not required to daisy-chain. In fact, the Apple and Motorolla bridge chipsets assign a seperate hardware interrupt per INT line per slot; because there are seperate line drivers for these things, they can also support a lot more slots without bridging things. The Intel design has to daisy-chain because it is a lazy design; it has the 4 slot limit because of the line drivers having to drive 4 slots per driver instead of 1. To give Intel credit: they were working from the perspective that they had an ISA machine which they were bridging PCI slots into the design. This is a stupid perspective, since all machines should be PCI, and ISA should DIE DIE DIE, or at the very least, the ISA stuff should be bridged to the PCI in a predominantly PCI design. This would let you remap an internally share ISA interrupts on the rational (PCI) side of the bridge. #ifdef EDITORIAL Hmmm... the Alpha 21064/21066 works this way; so do all the Motorolla PPC chips... looks like Intel's the only one married to ISA-dictated designs. Pity... ISA-dictated designs are only 15 years out of date. #endif /* EDITORIAL*/ PCI-PCI bridges compliant with the 1.0 PCI-PCI bridge specification (April, 1994) will internally daisy-chain interrupts to allow card cage fanouts using a passive PCI backplane to be built (ie: insert a card into the main machine, and you get 4 more PCI slots; or you can build a machine with a PCI-PCI bridge integrated on it, and offer 7 (or 8) PSI slots on a single motherboard. Lessons: 1) Putting a card using two interrupts into slot 4 of a 5 PCI "shared slot" design will not cause the card to use the same interrupt for both channels of the internally bridged device. 2) INT A-D are not interrupts, they are mappings to interrupts by a bridge chipset. 3) Intel PCI bridge chipsets: Bad. Apple/Motorolla PCI bridge chipsets: Good. 4) Intel OEM products divisions motherboards (at least the old ones): Bad. ASUS motherboards: Good. 5) ISA slots: Bad. PCI slots: Good. 6) PCI cards that allow you to jumper which INT A-D is assigned to which channel: Good. Adaptec 3940's: Unknown. 7) Sharing Interrupts: Allowed, Required to be supported, but Bad. One interrupt per device: Not always possible, but Good. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Sat Jan 18 12:15:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26863 for smp-outgoing; Sat, 18 Jan 1997 12:15:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26855 for ; Sat, 18 Jan 1997 12:15:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA12301; Sat, 18 Jan 1997 13:01:43 -0700 From: Terry Lambert Message-Id: <199701182001.NAA12301@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: smp@csn.net (Steve Passe) Date: Sat, 18 Jan 1997 13:01:43 -0700 (MST) Cc: cbrown@aracnet.com, smp@FreeBSD.ORG In-Reply-To: <199701180524.WAA22187@clem.systemsix.com> from "Steve Passe" at Jan 17, 97 10:24:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Personally, I can't believe that they would design a MB with hardwired > > interrupts. You should be > > able to have a PCI slot without ANY interrupt assigned. In addition, > > they all use INTA? That is > > kinda a waste. Sounds like that kinda kludged the interrupt mapping > > into the system. > > I don't know where this style mapping came from but it seems (in my limited > knowledge) to be common on MBs these days. I suppose it was meant to make > life easier for end users, not having to strap cards for specific INT pins. > I would think it possible for a card maker to strap both INT[AB] of a bridged > card to PCI INTA (as an option) allowing the use of only 1 PCI INT line > in an OS that can handle SHARED INTs, but perhaps there is something about > the PCI spec that disallows this? It came from a bridge chpset that was intent on mapping PCI devices into a predominantly ISA architecture. The error was in allowing the architecture to be predominantly ISA to save Intel's market for ISA multi-I/O and other motherboard chipsets dependent on ISA interfacing, The correct soloution is to go to internally PCI machines, and if you want to dip the PCI Vestal Virgin into the Raw Sewage of ISA, you can bridge ISA to the PCI instead of the other way around. Just my unbiased opinion, of course. 8-) 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Sat Jan 18 12:18:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26990 for smp-outgoing; Sat, 18 Jan 1997 12:18:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26985 for ; Sat, 18 Jan 1997 12:18:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA12315; Sat, 18 Jan 1997 13:04:04 -0700 From: Terry Lambert Message-Id: <199701182004.NAA12315@phaeton.artisoft.com> Subject: Re: Adaptec 3940UW and SMP To: ken@housing1.stucen.gatech.edu (Kenneth Merry) Date: Sat, 18 Jan 1997 13:04:04 -0700 (MST) Cc: smp@csn.net, cbrown@aracnet.com, smp@FreeBSD.ORG In-Reply-To: <199701180728.CAA07347@housing1.stucen.gatech.edu> from "Kenneth Merry" at Jan 18, 97 02:28:43 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Uniprocessor: works fine > Non-APIC_IO SMP: works fine > APIC_IO SMP: hangs(2) > > 2) The APIC_IO kernel would hang right before the kernel should go over to > init. Ctrl-Alt-Del did work to reboot it at that point. > > The only difference between the above configuration and my old > configuration was that I let the BIOS automatically configure the > interrupts on the cards. So things seemed to work better when I manually > configured the interrupts. Perhaps there was a conflict? PCI interrupt sharing is (apparently) not corectly supported by the APIC I/O. This should be corrected, since non-SMP systems with APIC's should probably be running APIC I/O anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Sat Jan 18 15:14:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA04290 for smp-outgoing; Sat, 18 Jan 1997 15:14:16 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA04284 for ; Sat, 18 Jan 1997 15:14:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA29399; Sat, 18 Jan 1997 16:12:37 -0700 Message-Id: <199701182312.QAA29399@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: Terry Lambert cc: smp@freebsd.org Subject: Re: Adaptec 3940UW and SMP In-reply-to: Your message of "Sat, 18 Jan 1997 13:04:04 MST." <199701182004.NAA12315@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jan 1997 16:12:37 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >PCI interrupt sharing is (apparently) not corectly supported by the >APIC I/O. This should be corrected, since non-SMP systems with APIC's >should probably be running APIC I/O anyway. I believe the problem here is the one I documented earlier as: > PnP board failure > >PnP boards can cause problems as I have not yet implimented code to "undirect" >PCI INTs when sent to the APIC. Since an upper ( >15 ) INT is registered >in place of the original ( <=15 ) the original may be assigned later by >a PnP card. BUT the lower INT line is NOT un-redirected. >This means both the PCI hardware (via the redirect hardware) AND the PnP >card are yanking on the same lower INT line, causing random problems. > >solution: > >disable the PnP aspects of a board, use the BIOS "legacy ISA" settings. --- Note his following test: > The BIOS printout confirmed that the interrupts were assigned as >follows: > >Slot 1: SMC 10/100 (IRQ 11) ^^^^^^^ >Slot 4: Adaptec 3940UW (IRQ 14 for channel 1, IRQ 11 for channel 2) ^^^^^^ >Slot 5: Matrox Millenium (IRQ 14) > > And with MP spec v1.4 enabled in the BIOS, I got the following >results: > >Uniprocessor: works fine >Non-APIC_IO SMP: works fine >APIC_IO SMP: works fine APIC PCI INTerrupt sharing is working on the PCI bus. One genuine problem is when an ISA card trys to re-cycle the unused (but STILL redirected) PCI INT. Another is that the info contained in SOME spec 1.1 MP tables is incorrect is a few unique cases (bridged chips, multiple PCI busses) causing the APIC to be misprogrammed. The general solutions are known, its just a matter of finding the time to impliment them! -- Steve Passe | powered by smp@csn.net | FreeBSD