From owner-freebsd-smp Mon May 21 16:32:40 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snoopy.akamba.com (ns1.akamba.com [65.105.229.254]) by hub.freebsd.org (Postfix) with ESMTP id EE43937B424 for ; Mon, 21 May 2001 16:32:32 -0700 (PDT) (envelope-from madsen@akamba.com) Received: from mail01.akamba.com (mailhost.akamba.com [10.10.0.52]) by snoopy.akamba.com (8.11.2/8.11.2) with ESMTP id f4LNWWa07640 for ; Mon, 21 May 2001 16:32:32 -0700 (PDT) Received: by mailhost.akamba.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 16:32:32 -0700 Message-ID: From: Steve Madsen To: "'freebsd-smp@freebsd.org'" Subject: Supporting old-style SMP in drivers Date: Mon, 21 May 2001 16:32:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I apologize in advance for the questions, as I know that most discussion here relates to the new implementation. I've done several searches and can't seem to find information on the SMP implementation in 3.x and 4.x. I'm trying to hunt down a bug in a network driver that only occurs when running on an SMP kernel (4.2, to be exact). Is there a site or document somewhere that explains the SMP implementation in 3.x and 4.x? Is only one CPU ever permitted in the kernel, even when an interrupt fires? If yes, when will that interrupt be serviced? Are there any locking primitives that can or should be used for synchronization? The problem I'm seeing is that occasionally, the kernel will cease delivering interrupts to my handler. I can poke the NIC and generate an interrupt, but the handler is never invoked. I can examine the PCI registers from a user-space application and see that the interrupt was generated (and is not masked by the card). It just never gets handled and cleared. I did see some vaguely similar problems in the bug database. Here is the output of "mptable -dmesg -verbose": ============================================================================ === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009f800 searching CMOS 'top of mem' @ 0x0009f400 (637K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f72d0 ---------------------------------------------------------------------------- --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f72d0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x41 mode: Virtual Wire ---------------------------------------------------------------------------- --- MP Config Table Header: physical address: 0x0009f960 signature: 'PCMP' base table length: 252 version: 1.1 checksum: 0x7c OEM ID: 'INTEL ' Product ID: 'N440BX ' 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 7 2 0x387fbff 0 0x11 AP, usable 6 7 2 0x387fbff -- 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 level 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 ---------------------------------------------------------------------------- --- # 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 ---------------------------------------------------------------------------- --- dmesg output: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE #34: Mon May 21 16:15:43 PDT 2001 madsen@s18.test.akamba.com:/usr/src/sys/compile/AKAMBA-SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x387fbff real memory = 536805376 (524224K bytes) avail memory = 515620864 (503536K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc0378000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 cb0: mem 0xfa000000-0xfa0fffff irq 11 at device 11.0 on pci0 cb0: Ethernet address 00:30:76:01:10:8c cb0: driver is using old-style compatability shims ncr0: port 0x1400-0x14ff mem 0xfa200000-0xfa200fff,0xfa203000-0xfa2030ff irq 11 at device 13.0 on pci0 ncr1: port 0x1800-0x18ff mem 0xfa201000-0xfa201fff,0xfa203400-0xfa2034ff irq 10 at device 13.1 on pci0 fxp0: port 0x1060-0x107f mem 0xfa100000-0xfa1fffff,0xfa204000-0xfa204fff irq 5 at device 15.0 on pci0 fxp0: Ethernet address 00:a0:c9:ac:fe:94 isab0: at device 18.0 on pci0 isa0: on isab0 atapci0: port 0x1050-0x105f at device 18.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1080-0x109f irq 10 at device 18.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Timecounter "PIIX" frequency 3579545 Hz chip1: port 0x1040-0x104f at device 18.3 on pci0 pci0: at 20.0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 cb0 XXX: driver didn't set ifq_maxlen SMP: AP CPU #1 Launched! ad0: 9641MB [19590/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s1a cb0: not multicast capable, IPv6 not enabled ============================================================================ === -- Steve Madsen Akamba Corporation, http://www.akamba.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon May 21 20:54:32 2001 Delivered-To: freebsd-smp@freebsd.org Received: from midten.fast.no (midten.fast.no [213.188.8.11]) by hub.freebsd.org (Postfix) with ESMTP id 66E2A37B422 for ; Mon, 21 May 2001 20:54:28 -0700 (PDT) (envelope-from Tor.Egge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [213.188.8.11]) by midten.fast.no (8.9.3/8.9.3) with ESMTP id FAA73467; Tue, 22 May 2001 05:54:18 +0200 (CEST) Message-Id: <200105220354.FAA73467@midten.fast.no> To: madsen@akamba.com Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Supporting old-style SMP in drivers From: Tor.Egge@fast.no In-Reply-To: Your message of "Mon, 21 May 2001 16:32:31 -0700" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 May 2001 05:54:18 +0200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The problem I'm seeing is that occasionally, the kernel will cease > delivering interrupts to my handler. I can poke the NIC and generate an > interrupt, but the handler is never invoked. I can examine the PCI > registers from a user-space application and see that the interrupt was > generated (and is not masked by the card). It just never gets handled and > cleared. Your problem might be caused by a workaround for a broken MP table on Micronics W6Li machines. The IOAPIC is programmed for the default ISA interrupt type (active-high edge-triggered) for entries in the MP table described as active-high level-triggered ISA interrupts. To disable the workaround, apply this patch. If the machine hangs during boot then you can revert the patch and change the workaround to switch polarity instead of trigger mode. Index: mpapic.c =================================================================== RCS file: /usr/ncvs/src/sys/i386/i386/mpapic.c,v retrieving revision 1.37.2.4 diff -u -r1.37.2.4 mpapic.c --- mpapic.c 2000/09/30 02:49:32 1.37.2.4 +++ mpapic.c 2001/05/22 03:15:01 @@ -234,7 +234,7 @@ (pin < IOAPIC_ISA_INTS) && (irq == pin) && (apic_polarity(apic, pin) == 0x1) && - (apic_trigger(apic, pin) == 0x3)) { + (apic_trigger(apic, pin) == 0x3) && 0) { /* * A broken BIOS might describe some ISA * interrupts as active-high level-triggered. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 22 11:38:59 2001 Delivered-To: freebsd-smp@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 985A237B422; Tue, 22 May 2001 11:38:55 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo.feral.com [192.67.166.71]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f4MIcrc53197; Tue, 22 May 2001 11:38:54 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 22 May 2001 11:38:53 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: smp@FreeBSD.ORG Subject: more recursive mutex panics- help me out with the One True way? :-) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After overnight run, I got: isp1: kthread up release simq lrecursed on non-recursive lock (sleep mutex) process lock @ ../../kern/kern_lock.c:262 first acquired @ ../../kern/kern_sig.c:447 panic: recurse panic Stopped at hangs irretrievably (can't send BREAK to break to DDB any more- hasn't worked on pc164 for months) The kthread in question: static void isp_kthread(void *arg) { int wasfrozen; struct ispsoftc *isp = arg; mtx_lock(&isp->isp_lock); for (;;) { isp_prt(isp, ISP_LOGALL, "kthread checking FC state"); while (isp_fc_runstate(isp, 2 * 1000000) != 0) { msleep(&lbolt, &isp->isp_lock, PRIBIO, "isp_fc_worker", 0); } wasfrozen = isp->isp_osinfo.simqfrozen & SIMQFRZ_LOOPDOWN; isp->isp_osinfo.simqfrozen &= ~SIMQFRZ_LOOPDOWN; if (wasfrozen && isp->isp_osinfo.simqfrozen == 0) { isp_prt(isp, ISP_LOGALL, "kthread up release simq"); ISPLOCK_2_CAMLOCK(isp); xpt_release_simq(isp->isp_sim, 1); CAMLOCK_2_ISPLOCK(isp); } cv_wait(&isp->isp_osinfo.kthread_cv, &isp->isp_lock); } } And the lock transitions to acquire Giant on entry to CAM are: #define ISPLOCK_2_CAMLOCK(isp) \ mtx_unlock(&(isp)->isp_lock); mtx_lock(&Giant) #define CAMLOCK_2_ISPLOCK(isp) \ mtx_unlock(&Giant); mtx_lock(&(isp)->isp_lock) So- 2 questions: 1. Are the defines for grabbing/releasing Giant acceptable in kthread context? 2. Is the msleep on lbolt a bad idea? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 22 13:37:37 2001 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2008137B422 for ; Tue, 22 May 2001 13:37:33 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f4MKbVK49546; Tue, 22 May 2001 13:37:31 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f4MKbUx42250; Tue, 22 May 2001 13:37:30 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 22 May 2001 13:37:30 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: RE: more recursive mutex panics- help me out with the One True w Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 22-May-01 Matthew Jacob wrote: > > After overnight run, I got: > > isp1: kthread up release simq > lrecursed on non-recursive lock (sleep mutex) process lock @ > ../../kern/kern_lock.c:262 > first acquired @ ../../kern/kern_sig.c:447 > panic: recurse > panic > Stopped at That doesn't seem to be from any problems in your code. I'm somewhat curious why lockmgr is being called during a signal operation however, as that seems to be the problem you've run into. I'd need a backtrace to be more certain however. > So- 2 questions: > > > 1. Are the defines for grabbing/releasing Giant acceptable in kthread > context? They look fine. > 2. Is the msleep on lbolt a bad idea? The msleep is fine, the &lbolt part I'm not an expert on, so I'm not sure if it is evil or not. :) > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 22 14:34:59 2001 Delivered-To: freebsd-smp@freebsd.org Received: from munin.odin-corporation.com (munin.odin-corporation.com [216.233.173.18]) by hub.freebsd.org (Postfix) with ESMTP id 3933F37B43F for ; Tue, 22 May 2001 14:34:51 -0700 (PDT) (envelope-from lars@odin-corporation.com) Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.11.3/8.11.1) with ESMTP id f4MLXvc93969; Tue, 22 May 2001 16:33:58 -0500 (CDT) (envelope-from lars@odin-corporation.com) Message-ID: <3B0ADB45.180C9C6D@odin-corporation.com> Date: Tue, 22 May 2001 16:33:57 -0500 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: Tor.Egge@fast.no Cc: smp@FreeBSD.ORG Subject: Re: Any reason why we don't use irqs above 15 on SMP systems? References: <3B0034CA.D6692771@odin-corporation.com> <200105151531.RAA48069@midten.fast.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tor.Egge@fast.no wrote: > > Hi, > > A while back I seem to recall that if you ran on an SMP system, that you > > would end up with essentially 32 irqs. That doesn't seem to happen any > > more. This particular motherboard (Supermicro P6DNE) is configured with > > PNP OS set to yes. That is the only way I can get this box up and > > running. Otherwise, it assigns every PCI board irq 11, and a that > > point, no interupts are comming through. > > On -stable, it's 24 low level interrupt handlers. > > The binding of (APIC id, intpin) pairs to low level interrupt handler > numbers is deferred for PCI devices until the probe routine asks for > which interrupt the device uses. The first free low level interrupt > handler is then allocated for that (APIC id, intpin) pair. > > Multiple PCI devices described in the MP table as sharing the same > (APIC id, intpin) pair will share the same low level interrupt > handler. > > - Tor Egge Hi Tor, Part of my problem is that my PNP gus ISA sound card ends up on irq 11, which also gets assigned to the video card (when pnp os = TRUE) or to all my PCI cards (when PNP os = FALSE). I am assuming that it is my bios that is building a poor or incorrect mptable. On this particular system, the PCI devices never gets irqs above 15. I don't yet know if that is related to : Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 7 IOAPIC #0 intpin 17 -> irq 5 IOAPIC #0 intpin 18 -> irq 9 IOAPIC #0 intpin 19 -> irq 11 IOAPIC #0 intpin 20 -> irq 15 APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0 I was thinking of taking intpin 18,19 and 20 and hard code them to irq 16,17, and 18. I had a patch for this a couple of years ago that worked well, and I might just have to figure out how to do the same again. Thanks for the feedback, Lars Gratulere med vel overstått 17 mai. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue May 22 15:22:47 2001 Delivered-To: freebsd-smp@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 0A37337B42C; Tue, 22 May 2001 15:22:31 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo.feral.com [192.67.166.71]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f4MMMRc55964; Tue, 22 May 2001 15:22:28 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 22 May 2001 15:22:26 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: smp@FreeBSD.ORG Subject: RE: more recursive mutex panics- help me out with the One True w In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > lrecursed on non-recursive lock (sleep mutex) process lock @ > > ../../kern/kern_lock.c:262 > > first acquired @ ../../kern/kern_sig.c:447 > > panic: recurse > > panic > > Stopped at > > That doesn't seem to be from any problems in your code. I'm somewhat > curious why lockmgr is being called during a signal operation however, > as that seems to be the problem you've run into. I'd need a backtrace > to be more certain however. > > > So- 2 questions: > > > > > > 1. Are the defines for grabbing/releasing Giant acceptable in kthread > > context? > > They look fine. Great! THanks! > > > 2. Is the msleep on lbolt a bad idea? > > The msleep is fine, the &lbolt part I'm not an expert on, so I'm not sure > if it is evil or not. :) Actually, I think it might have been the msleep that might have caused all of this. Instead of sleeping on lbolt, I do: msleep(isp_kthread, &isp->isp_lock, PRIBIO, "isp_fcthrd", hz); which is a lot cleaner and closer to what I wanted anyway (nobody will wake me up- but I just wanted to sleep with the lock off for a second). I've been running my tests since this morning and I haven't died yet- it used to do within a few hours. Well, we'll see. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 24 7:28:26 2001 Delivered-To: freebsd-smp@freebsd.org Received: from web11305.mail.yahoo.com (web11305.mail.yahoo.com [216.136.131.208]) by hub.freebsd.org (Postfix) with SMTP id D283E37B422 for ; Thu, 24 May 2001 07:28:24 -0700 (PDT) (envelope-from ddavid_3@yahoo.com) Message-ID: <20010524142824.12915.qmail@web11305.mail.yahoo.com> Received: from [216.138.192.203] by web11305.mail.yahoo.com; Thu, 24 May 2001 10:28:24 EDT Date: Thu, 24 May 2001 10:28:24 -0400 (EDT) From: David David Reply-To: ddavid@ican.net Subject: SMP-MB List To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Just came across this list here: http://people.freebsd.org/~fsmp/SMP/hardware.html which did not have my board mentioned. http://www.tekram.com/Hot_Products.asp?Product=P6B40D-A5 It's no longer being made, but i have been using it since FreeBSD-3.4 with no problems to date. Cheers David _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu May 24 10:21:57 2001 Delivered-To: freebsd-smp@freebsd.org Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E60437B422; Thu, 24 May 2001 10:21:48 -0700 (PDT) (envelope-from sbe30510@post.netlink.se) Received: from usr01.netlink.se (usr01.netlink.se [212.242.42.10]) by cicero0.cybercity.dk (Postfix) with ESMTP id E1705102ABB; Thu, 24 May 2001 19:21:44 +0200 (CEST) Received: from tjafs (port388.cvx3-mal.ppp.netlink.se [62.66.14.135]) by usr01.netlink.se (8.10.1/8.10.1) with SMTP id f4OHLrV14172; Thu, 24 May 2001 19:21:53 +0200 (CEST) Reply-To: From: "Mattias Berge" To: , , , Subject: Date: Thu, 24 May 2001 19:23:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have sme major problems with getting the SMP support to work. My machine is a Compaq Proliant 380D with dual 733 mhz pIII processors. I run FreeBSD 4.3-REL. I have added the two SMP lines in my kernel conf and delöeted the I*86_CPU that I do not need. Then I compiled the kernel and rebooted, and it hangs in boot when it says: Changing APIC ID for IO APIC #0 from 0 to 8 on chip Programming 35 pins in IOAPIC #0 IOAPIC #0 intpin -> irq 0 Anyone expiriance (and solved) a similar problem? Please reply to this mail, since Im not a member of any list. Thanks in advance, Mattias Berge Atos Medical AB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat May 26 2:10:17 2001 Delivered-To: freebsd-smp@freebsd.org Received: from alma.tavrida.net (alma.tavrida.net [193.220.126.131]) by hub.freebsd.org (Postfix) with ESMTP id 3B9BE37B422; Sat, 26 May 2001 02:10:03 -0700 (PDT) (envelope-from kirill@tavrida.net) Received: from localhost (kirill@localhost) by alma.tavrida.net (8.11.3/8.11.3) with ESMTP id f4Q99bj89418; Sat, 26 May 2001 12:09:42 +0300 (EEST) Date: Sat, 26 May 2001 12:09:37 +0300 (EEST) From: Kirill To: Cc: , , , Subject: Re: your mail In-Reply-To: Message-ID: <20010526120647.N89280-100000@alma.tavrida.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 24 May 2001, Mattias Berge wrote: > Hi, I have sme major problems with getting the SMP support to work. > My machine is a Compaq Proliant 380D with dual 733 mhz pIII processors. > I run FreeBSD 4.3-REL. > I have added the two SMP lines in my kernel conf and delöeted the I*86_CPU > that I do not need. > Then I compiled the kernel and rebooted, and it hangs in boot when it says: > > Changing APIC ID for IO APIC #0 from 0 to 8 on chip > Programming 35 pins in IOAPIC #0 > IOAPIC #0 intpin -> irq 0 Change your OS type in BIOS to Linux, and upgrade your BIOS if you have older one. Kirill kirill@tavrida.net > > Anyone expiriance (and solved) a similar problem? > Please reply to this mail, since Im not a member of any list. > Thanks in advance, > > Mattias Berge > Atos Medical AB > > > 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