From owner-freebsd-smp Sun Aug 22 17:24: 8 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1A1BD154CD for ; Sun, 22 Aug 1999 17:23:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA00824; Sun, 22 Aug 1999 17:23:40 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 17:23:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230023.RAA00824@apollo.backplane.com> To: Luoqi Chen Cc: freebsd-smp@FreeBSD.ORG Subject: Weird infinite lockup in splx() (in IFCPL_UNLOCK) w/ latest CURRENT/SMP Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I had a weird lockup w/ the latest CURRENT while doing an installworld. I tracked the lockup down to an infinite loop in the current process... an infinite loop in splx()! I've never had this lockup before so I believe it to be due to some recent change. The lockup occured during very heavy use of the lockmgr on the same vnode lock (the uudecode binary) during a parallel installworld. My kernel was as of today, 22Aug. This is on a 2xPIII/450 SMP box. I believe there to be a race condition somewhere. -Matt ... #9 0xc021f1e6 in scgetc (sc=0xc02a37e0, flags=2) at ../../dev/syscons/syscons.c:3782 #10 0xc021aef1 in sckbdevent (thiskbd=0xc02b4d20, event=0, arg=0xc02a37e0) at ../../dev/syscons/syscons.c:663 #11 0xc021481f in atkbd_intr (kbd=0xc02b4d20, arg=0x0) at ../../dev/kbd/atkbd.c:439 #12 0xc024b764 in atkbd_isa_intr (arg=0xc02b4d20) at ../../isa/atkbd_isa.c:123 #13 0xc0243194 in splx (ipl=3224034576) at ../../i386/isa/ipl_funcs.c:275 ^^^^^^^ it was looping splx, in IFCPL_UNLOCK. #14 0xc014c158 in lockmgr (lkp=0xc02add10, flags=2, interlkp=0x0, p=0xcc745ec0) at ../../kern/kern_lock.c:360 #15 0xc0205513 in kmem_alloc_wait (map=0xc02add10, size=69632) at ../../vm/vm_kern.c:436 #16 0xc0149375 in execve (p=0xcc745ec0, uap=0xcc7a3f80) at ../../kern/kern_exec.c:126 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Aug 22 19:10:50 1999 Delivered-To: freebsd-smp@freebsd.org Received: from noc.santacruz.org (noc.santacruz.org [209.133.111.168]) by hub.freebsd.org (Postfix) with ESMTP id 33A7E14FDF for ; Sun, 22 Aug 1999 19:10:42 -0700 (PDT) (envelope-from klynn@santacruz.org) Received: by noc.santacruz.org (Postfix, from userid 1003) id 551FCCD20; Sun, 22 Aug 1999 19:13:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by noc.santacruz.org (Postfix) with ESMTP id 47918CD18 for ; Sun, 22 Aug 1999 19:13:12 -0700 (PDT) Date: Sun, 22 Aug 1999 19:13:12 -0700 (PDT) From: Kevin Lynn To: freebsd-smp@freebsd.org Subject: Another SMP capable MB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got SMP running on this N440BX hardware with 2 p2-400's and it's absolutely rock solid. Here's the mptable.. =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f7300 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x4a mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009ed60 signature: 'PCMP' base table length: 252 version: 1.4 checksum: 0x5d OEM ID: 'INTEL ' Product ID: 'N440BX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 164 extended table checksum: 206 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 5 1 0x183fbff 0 0x11 AP, usable 6 5 1 0x183fbff -- Bus: Bus ID Type 0 PCI 1 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 1 0 2 0 INT active-hi edge 1 1 2 1 INT active-hi edge 1 0 2 2 INT active-hi edge 1 3 2 3 INT active-hi edge 1 4 2 4 INT active-hi edge 1 5 2 5 INT active-hi edge 1 6 2 6 INT active-hi edge 1 7 2 7 INT active-hi edge 1 8 2 8 INT active-hi level 1 9 2 9 INT active-hi level 1 10 2 10 INT active-hi level 1 11 2 11 INT active-hi edge 1 12 2 12 INT active-hi edge 1 13 2 13 INT active-hi edge 1 14 2 14 INT active-hi edge 1 15 2 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 1 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 -- bus ID: 0 address type: memory address address base: 0x10000000 address range: 0xea100000 -- bus ID: 0 address type: prefetch address address base: 0xfa100000 address range: 0x3f00000 -- bus ID: 0 address type: memory address address base: 0xfe000000 address range: 0xe00000 -- bus ID: 0 address type: memory address address base: 0xfef00000 address range: 0x1100000 -- bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- bus ID: 0 address type: memory address address base: 0xd0000 address range: 0x18000 -- bus ID: 1 bus info: 0x01 parent bus ID: 0-- bus ID: 0 address modifier: add predefined range: 0x00000000-- bus ID: 0 address modifier: add predefined range: 0x00000001 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Aug 22 19:34:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 083E21541F for ; Sun, 22 Aug 1999 19:34:22 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from nonpc.cs.rice.edu (nonpc.cs.rice.edu [128.42.1.219]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id VAA13952; Sun, 22 Aug 1999 21:34:21 -0500 (CDT) Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.3/8.7.3) id VAA49390; Sun, 22 Aug 1999 21:34:21 -0500 (CDT) Date: Sun, 22 Aug 1999 21:34:21 -0500 From: Alan Cox To: Matthew Dillon Cc: Luoqi Chen , freebsd-smp@FreeBSD.ORG Subject: Re: Weird infinite lockup in splx() (in IFCPL_UNLOCK) w/ latest CURRENT/SMP Message-ID: <19990822213421.E47586@nonpc.cs.rice.edu> References: <199908230023.RAA00824@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199908230023.RAA00824@apollo.backplane.com>; from Matthew Dillon on Sun, Aug 22, 1999 at 05:23:40PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Aug 22, 1999 at 05:23:40PM -0700, Matthew Dillon wrote: > I had a weird lockup w/ the latest CURRENT while doing an installworld. > > I tracked the lockup down to an infinite loop in the current process... > an infinite loop in splx()! > > I've never had this lockup before so I believe it to be due to > some recent change. The lockup occured during very heavy use of > the lockmgr on the same vnode lock (the uudecode binary) during a > parallel installworld. > > My kernel was as of today, 22Aug. This is on a 2xPIII/450 SMP box. > > I believe there to be a race condition somewhere. > > -Matt > > ... > #9 0xc021f1e6 in scgetc (sc=0xc02a37e0, flags=2) > at ../../dev/syscons/syscons.c:3782 > #10 0xc021aef1 in sckbdevent (thiskbd=0xc02b4d20, event=0, arg=0xc02a37e0) > at ../../dev/syscons/syscons.c:663 > #11 0xc021481f in atkbd_intr (kbd=0xc02b4d20, arg=0x0) > at ../../dev/kbd/atkbd.c:439 > #12 0xc024b764 in atkbd_isa_intr (arg=0xc02b4d20) at ../../isa/atkbd_isa.c:123 > #13 0xc0243194 in splx (ipl=3224034576) at ../../i386/isa/ipl_funcs.c:275 > > ^^^^^^^ it was looping splx, in IFCPL_UNLOCK. > Are you sure about this? There's no loop in IFCPL_UNLOCK or splx (proper) for that matter. Only the IFCPL_LOCK at the beginning and the splz at the end contain loops within them. > #14 0xc014c158 in lockmgr (lkp=0xc02add10, flags=2, interlkp=0x0, p=0xcc745ec0) > at ../../kern/kern_lock.c:360 > #15 0xc0205513 in kmem_alloc_wait (map=0xc02add10, size=69632) > at ../../vm/vm_kern.c:436 > #16 0xc0149375 in execve (p=0xcc745ec0, uap=0xcc7a3f80) > at ../../kern/kern_exec.c:126 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Aug 22 20:49:37 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 29AE014E2F for ; Sun, 22 Aug 1999 20:49:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA01534; Sun, 22 Aug 1999 20:49:27 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 20:49:27 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230349.UAA01534@apollo.backplane.com> To: Alan Cox Cc: Luoqi Chen , freebsd-smp@FreeBSD.ORG Subject: Re: Weird infinite lockup in splx() (in IFCPL_UNLOCK) w/ latest CURRENT/SMP References: <199908230023.RAA00824@apollo.backplane.com> <19990822213421.E47586@nonpc.cs.rice.edu> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> I had a weird lockup w/ the latest CURRENT while doing an installworld. :> :> I tracked the lockup down to an infinite loop in the current process... :> an infinite loop in splx()! :> :> I've never had this lockup before so I believe it to be due to :> some recent change. The lockup occured during very heavy use of :> the lockmgr on the same vnode lock (the uudecode binary) during a :> parallel installworld. :> :> My kernel was as of today, 22Aug. This is on a 2xPIII/450 SMP box. :> :> I believe there to be a race condition somewhere. :> :> -Matt :> :> ... :> #9 0xc021f1e6 in scgetc (sc=0xc02a37e0, flags=2) :> at ../../dev/syscons/syscons.c:3782 :> #10 0xc021aef1 in sckbdevent (thiskbd=0xc02b4d20, event=0, arg=0xc02a37e0) :> at ../../dev/syscons/syscons.c:663 :> #11 0xc021481f in atkbd_intr (kbd=0xc02b4d20, arg=0x0) :> at ../../dev/kbd/atkbd.c:439 :> #12 0xc024b764 in atkbd_isa_intr (arg=0xc02b4d20) at ../../isa/atkbd_isa.c:123 :> #13 0xc0243194 in splx (ipl=3224034576) at ../../i386/isa/ipl_funcs.c:275 :> :> ^^^^^^^ it was looping splx, in IFCPL_UNLOCK. :> : :Are you sure about this? There's no loop in IFCPL_UNLOCK or splx (proper) :for that matter. Only the IFCPL_LOCK at the beginning and the splz at :the end contain loops within them. Hmm. Here's a dissasembly: 0xc024316c : pushl %ebx 0xc024316d : movl 0x8(%esp,1),%ebx 0xc0243171 : pushl $0xc02c1940 0xc0243176 : call 0xc0234324 0xc024317b : movl %ebx,0xc029e4b0 0xc0243181 : notl %ebx 0xc0243183 : movl 0xc029e4d4,%eax 0xc0243188 : andl %eax,%ebx 0xc024318a : pushl $0xc02c1940 0xc024318f : call 0xc023439c 0xc0243194 : addl $0x8,%esp <---------- 0xc0243197 : testl %ebx,%ebx 0xc0243199 : je 0xc02431b1 0xc024319b : movl $0xa0,%eax 0xc02431a0 : addl %fs:0x0,%eax 0xc02431a7 : cmpl $0x0,(%eax) 0xc02431aa : jne 0xc02431b1 0xc02431ac : call 0xc0227b70 0xc02431b1 : popl %ebx 0xc02431b2 : ret I'm confused. The machine was definitely locked up --- it was definitely in an infinite loop (there were a lot of runnable processes but not running processes except the one that was stuck looping in supervisor mode). ping worked, and ctl-alt-esc worked, so interrupts worked, but nothing else. This is an unlock call, perhaps the kmem_alloc_wait() is stuck in a tight loop and I just happened to catch it in the sti. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Aug 22 21: 6:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E505414D3E for ; Sun, 22 Aug 1999 21:06:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA01611; Sun, 22 Aug 1999 21:04:34 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 21:04:34 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230404.VAA01611@apollo.backplane.com> To: Alan Cox Cc: Luoqi Chen , freebsd-smp@FreeBSD.ORG Subject: Re: Weird infinite lockup in splx() (in IFCPL_UNLOCK) w/ latest CURRENT/SMP References: <199908230023.RAA00824@apollo.backplane.com> <19990822213421.E47586@nonpc.cs.rice.edu> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> #9 0xc021f1e6 in scgetc (sc=0xc02a37e0, flags=2) :> at ../../dev/syscons/syscons.c:3782 :> #10 0xc021aef1 in sckbdevent (thiskbd=0xc02b4d20, event=0, arg=0xc02a37e0) :> at ../../dev/syscons/syscons.c:663 :> #11 0xc021481f in atkbd_intr (kbd=0xc02b4d20, arg=0x0) :> at ../../dev/kbd/atkbd.c:439 :> #12 0xc024b764 in atkbd_isa_intr (arg=0xc02b4d20) at ../../isa/atkbd_isa.c:123 :> #13 0xc0243194 in splx (ipl=3224034576) at ../../i386/isa/ipl_funcs.c:275 :> :> ^^^^^^^ it was looping splx, in IFCPL_UNLOCK. :> : :Are you sure about this? There's no loop in IFCPL_UNLOCK or splx (proper) :for that matter. Only the IFCPL_LOCK at the beginning and the splz at :the end contain loops within them. : :> #14 0xc014c158 in lockmgr (lkp=0xc02add10, flags=2, interlkp=0x0, p=0xcc745ec0) :> at ../../kern/kern_lock.c:360 :> #15 0xc0205513 in kmem_alloc_wait (map=0xc02add10, size=69632) :> at ../../vm/vm_kern.c:436 All I can think of is that kmem_alloc_wait() is in a tight loop which means that the tsleep() call is not sleeping the process. cold isn't set, panicstr is from my 'panic from debugger' after the fact. priority is PVM so PCATCH isn't set. I am at a complete loss. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Aug 22 21:45:59 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 27C8A14D8C for ; Sun, 22 Aug 1999 21:45:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA01758; Sun, 22 Aug 1999 21:45:03 -0700 (PDT) (envelope-from dillon) Date: Sun, 22 Aug 1999 21:45:03 -0700 (PDT) From: Matthew Dillon Message-Id: <199908230445.VAA01758@apollo.backplane.com> To: Alan Cox , Luoqi Chen , freebsd-smp@FreeBSD.ORG Subject: cripes, found it (was Re: Weird infinite lockup in splx()) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cripes. I think it's a tight loop between two or more high priority system processes. Here's what is going on: kmem_alloc_wait() locks a vm_map, tries to find space, and if it fails it unlocks the map and then tsleep's on the map. What happens when you have two processes doing this? You would think it would be ok. But it isn't. Because the very first field of the vm_map structure is a lock structure. The locking functions are using the *SAME* wait address as the kmem_alloc_wait and kmem_free_wakeup code! Since we can get the locks just fine, if you have more then one process in this section of code the N processes rotate between each other due to the vm_map_unlock() calls waking up the tsleep() in the other process's kmem_alloc_wait. !!!! Oops. Ok, but how to fix? I am going to try to simply switch the first two fields in the vm_map structure so the lock does not sleep on the same address as kmem_alloc_wait. I believe this will fix the problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Aug 23 23:28:52 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id CC6071576A for ; Mon, 23 Aug 1999 23:28:38 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04637; Mon, 23 Aug 1999 23:28:12 -0700 (PDT) Date: Wed, 18 Aug 1999 11:36:35 -0700 (PDT) Message-Id: <199908240628.XAA04637@gilliam.users.flyingcroc.net> From: Charles Randall To: freebsd-smp@FreeBSD.ORG Subject: SMP differences between -stable and -current (RE: wine and SMP) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Note: only to -smp] Which of those limitations also apply to -current? Charles -----Original Message----- From: Bruce Albrecht [mailto:bruce@zuhause.mn.org] ... Even though SMP is supported in -stable, you must recognize that it's a fairly weak implementation. For the most part, there's only one kernel lock, so in general, you can't have more than one CPU doing kernel stuff, even though the two kernel requests (for example, two separate disk controllers, or two NICs) are independent of each other. There's no processor affinity. A threaded process can't have multiple threads running simultaneously on multiple CPUs. I'm sure there are other deficiencies I've left out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Aug 28 23:55:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from tahoe.cinenet.net (ns1.cinenet.net [198.147.76.65]) by hub.freebsd.org (Postfix) with ESMTP id F3F3114BEA for ; Sat, 28 Aug 1999 23:55:40 -0700 (PDT) (envelope-from sraja@cinenet.net) Received: from hermosa.cinenet.net (hermosa.cinenet.net [198.147.76.90]) by tahoe.cinenet.net (8.8.6/8.8.6) with SMTP id XAA05904 for ; Sat, 28 Aug 1999 23:55:38 -0700 (PDT) Date: Sat, 28 Aug 1999 23:55:37 -0700 (PDT) From: Suresh Rajagopalan To: freebsd-smp@freebsd.org Subject: SMP freezes on 3.2-STABLE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been trying to track down continual freezes on 3 servers running 3.2-STABLE. The machines are very busy web servers and simply freeze randomly after 2-5 days of uptime. There is no response from the console at the point of freeze. I cannot get it to dump core either. Machines are PIII-450 on ASUS P2B-D motherboards with 256Mb of RAM & 800M swap. All machines are NFS clients mounting off a Solaris X86 server. The output of mptable is attached below. I've tried MP 1.4 as well as 1.1. I don't know if this is a problem with 3.x in general, and I have read about larger sites like yahoo running smp-stable. If some of you are running SMP in a busy web/nfs enviroment, I'd love to hear from you. Any help is appreciated. -Suresh MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f6e50 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0xe7 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f6a40 signature: 'PCMP' base table length: 252 version: 1.4 checksum: 0xca OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 124 extended table checksum: 178 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 7 2 0x387fbff 0 0x11 AP, usable 6 7 2 0x387fbff -- 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 PIN# 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 9 2 9 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 15 INT active-lo level 1 0:A 2 16 INT active-lo level 0 4:D 2 19 INT active-lo level 0 10:A 2 18 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 2 0 255 0 NMI active-hi edge 2 0 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 -- bus ID: 0 address type: memory address address base: 0x10000000 address range: 0xd2ee0000 -- bus ID: 0 address type: prefetch address address base: 0xe2ee0000 address range: 0x5120000 -- bus ID: 0 address type: memory address address base: 0xe8000000 address range: 0x18000000 -- bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- bus ID: 2 bus info: 0x01 parent bus ID: 0-- bus ID: 0 address modifier: add predefined range: 0x00000000-- bus ID: 0 address modifier: add predefined range: 0x00000001 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message