From owner-freebsd-smp Sun Aug 24 00:22:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19906 for smp-outgoing; Sun, 24 Aug 1997 00:22:39 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19901 for ; Sun, 24 Aug 1997 00:22:35 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id CAA07355 for ; Sun, 24 Aug 1997 02:22:31 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma007334; Sun, 24 Aug 97 02:22:18 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id CAA04192 for ; Sun, 24 Aug 1997 02:22:17 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Sun, 24 Aug 1997 02:22:17 -0500 (CDT) From: Kyle Mestery To: freebsd-smp@freebsd.org Subject: New code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, the new changes Steve committed tonite do not work for me. Immediatly after the kernel finishes loading, it reboots. Config: Tyan Tomcat II, dual 120s 64MB RAM EIDE disks I noticed you just sent mail with a fix for the previous person who had troubles with the new code. SHould I try that also and see if it works? Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Sun Aug 24 00:53:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20976 for smp-outgoing; Sun, 24 Aug 1997 00:53:28 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20971 for ; Sun, 24 Aug 1997 00:53:26 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id BAA10823; Sun, 24 Aug 1997 01:53:22 -0600 (MDT) Message-Id: <199708240753.BAA10823@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Kyle Mestery cc: freebsd-smp@FreeBSD.ORG Subject: Re: New code In-reply-to: Your message of "Sun, 24 Aug 1997 02:22:17 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 01:53:22 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Hi, the new changes Steve committed tonite do not work for me. Immediatly > after the kernel finishes loading, it reboots. Config: > > Tyan Tomcat II, dual 120s > 64MB RAM > EIDE disks > > I noticed you just sent mail with a fix for the previous person who had > troubles with the new code. SHould I try that also and see if it works? first try undefining REAL_IFCPL in i386/include/param.h. if that fixes it try the changes in the mail you refer to. if undefing REAL_IFCPL doesn't help, undefine all the other REAL_XXX defines in param.h, -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun Aug 24 02:26:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA24332 for smp-outgoing; Sun, 24 Aug 1997 02:26:44 -0700 (PDT) Received: from caleche.kecl.ntt.co.jp (elysium.kecl.ntt.co.jp [129.60.192.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA24327 for ; Sun, 24 Aug 1997 02:26:40 -0700 (PDT) Received: from localhost by caleche.kecl.ntt.co.jp (8.8.7/kecl2.0/r8v7-M2-nishio) with ESMTP id SAA00290; Sun, 24 Aug 1997 18:27:44 +0900 (JST) To: smp@FreeBSD.ORG Subject: Re: HEADS UP: need status reports!!! In-Reply-To: Your message of "Sat, 23 Aug 1997 13:53:19 -0600" References: <199708231953.NAA08121@Ilsa.StevesCafe.com> X-Mailer: Mew version 1.54 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970824182743N.nishio@elysium.kecl.ntt.co.jp> Date: Sun, 24 Aug 1997 18:27:43 +0900 From: NISHIO Shuichi X-Dispatcher: impost version 0.95+ (Nov. 26, 1996) Lines: 37 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Steve Passe Subject: HEADS UP: need status reports!!! Date: Sat, 23 Aug 1997 13:53:19 -0600 Message-ID: <199708231953.NAA08121@Ilsa.StevesCafe.com> > Who has tried SMP sources dated August 1 or newer? > > if so: > What was your result, success or failure? Seems to be running fine, although I am experiencing slowdown in outbound transfers of de driver(from 6.5-7.5MB/s to 2.5-4.5MB/s). Inbound transfers are just the same as before (6.5-7.5MB/s). I am still not sure what changes are causing this slowdown. (might be due to the changes in the de driver on 8/3) > What basic hardware: motherboard make & model, P5/P6? Tyan S1668D ATX, dual P6 200MHz. > Is this the first attempt to run SMP on this hardware? No. > Did you start with a SNAP or cvsuped source tree? > What date? CVsuped on 8/23, from cvsup.jp.freebsd.org (a mirror at Japan), plus additional lines to pci_apic_pin() for using the 5th PCI slot. Previously I was using a cvsuped source on 7/28 with PEND_INTS defined. Nishio Shuichi From owner-freebsd-smp Sun Aug 24 03:25:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA26108 for smp-outgoing; Sun, 24 Aug 1997 03:25:57 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA26091 for ; Sun, 24 Aug 1997 03:25:46 -0700 (PDT) Received: (qmail 861 invoked by uid 1000); 24 Aug 1997 10:26:05 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199708231953.NAA08121@Ilsa.StevesCafe.com> Date: Sun, 24 Aug 1997 03:26:05 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Steve Passe Subject: RE: HEADS UP: need status reports!!! Cc: smp@FreeBSD.ORG, Dirk Froemberg Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Steve Passe; On 23-Aug-97 you wrote: ... > I need a show of hands: > > Who has tried SMP sources dated August 1 or newer? > > if so: > What was your result, success or failure? > What basic hardware: motherboard make & model, P5/P6? > Is this the first attempt to run SMP on this hardware? > Did you start with a SNAP or cvsuped source tree? > What date? In addition to what we discussed already, when starting X11, the mouse is frozen. (P6DNH) sources as of Friday night. Simon From owner-freebsd-smp Sun Aug 24 05:36:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA00517 for smp-outgoing; Sun, 24 Aug 1997 05:36:37 -0700 (PDT) Received: from mhub1.tc.umn.edu (0@mhub1.tc.umn.edu [128.101.131.51]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA00505 for ; Sun, 24 Aug 1997 05:36:31 -0700 (PDT) Received: from gold.tc.umn.edu by mhub1.tc.umn.edu; Sun, 24 Aug 97 07:36:29 -0500 Received: from pub-12-c-41.dialup.umn.edu by gold.tc.umn.edu; Sun, 24 Aug 97 07:36:28 -0500 Date: Sun, 24 Aug 1997 07:37:01 -0500 (CDT) From: dave adkins To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include param.h src/sys/i386/isa apic_ipl.s apic_vector.s icu_ipl.s ipl.s ipl_funcs.c src/sys/i386/i386 exception.s locore.s microtime.s simplelock.s In-Reply-To: <199708240623.AAA10435@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 24 Aug 1997, Steve Passe wrote: > > this is what I was looking for. try modifying i386/isa/ipl_funcs.c: > > move all the GENSPL() targets: > > from b4 the GENSPL2() macro to just after it, ie with the 2 existing > GENSPL2() targets: > > GENSPL2(splhigh, cpl = HWI_MASK | SWI_MASK) > GENSPL2(spltty, cpl |= tty_imask) > > then change them all from GENSPL to GENSPL2. reenable REAL_IFCPL and see > if that works. > Steve, The move from GENSPL to GENSPL2 fixes the problem. An splxxx must be called before smp is active. Thanks dave adkins From owner-freebsd-smp Sun Aug 24 10:32:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10730 for smp-outgoing; Sun, 24 Aug 1997 10:32:14 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA10704; Sun, 24 Aug 1997 10:32:03 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id CAA28007; Mon, 25 Aug 1997 02:18:02 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id CAA06795; Mon, 25 Aug 1997 02:16:34 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id CAA00503; Mon, 25 Aug 1997 02:16:29 +0900 (JST) Message-Id: <199708241716.CAA00503@peace.calm.imasy.or.jp> To: smp@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: need status reports!!! In-Reply-To: Your message of "Sun, 24 Aug 1997 14:03:25 +0900" <199708240503.OAA05086@peace.calm.imasy.or.jp> References: <199708240503.OAA05086@peace.calm.imasy.or.jp> X-Mailer: Mew version 1.89 on XEmacs 20.3 (Bratislava) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_25_02:16:25_1997_41)--" Content-Transfer-Encoding: 7bit Date: Mon, 25 Aug 1997 02:16:28 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970820 Lines: 423 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ----Next_Part(Mon_Aug_25_02:16:25_1997_41)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a boot time problem with a -current kernel cvsuped at August 25. The kernel hangs at very begining of boot time with following messages: boot: Booting 0:sd(0,a)kernel @ 0x100000 text=0xd5000 data=0x16000 bss=0x4bf3c symbols=[+0xc4+0x4+0x11b38+0x4+0x174ba] Can't find file kernel.config total=0x25fffa entry point=0x100000 A kernel cvsuped at August 23 had no problem. What's happen around the recent 2 days? I'm using on a IWILL DP6NS with dual Pentium Pro 180MHz. The output of mptable with a kernel cvsuped at August 23 and my configuration file are as follows: ----Next_Part(Mon_Aug_25_02:16:25_1997_41)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit =============================================================================== MPTable, version 2.0.13 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: 0x000f0eb0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0eb0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xc2 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f0ec4 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0xc8 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 6 1 9 0xfbff 1 0x11 AP, usable 6 1 9 0xfbff -- 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 INT# ExtINT conforms conforms 1 0 2 0 INT conforms conforms 1 1 2 1 INT conforms conforms 1 0 2 2 INT conforms conforms 1 3 2 3 INT conforms conforms 1 4 2 4 INT conforms conforms 1 5 2 5 INT conforms conforms 1 6 2 6 INT conforms conforms 1 7 2 7 INT conforms conforms 1 8 2 8 INT conforms conforms 1 9 2 9 INT conforms conforms 1 10 2 10 INT conforms conforms 1 11 2 11 INT conforms conforms 1 12 2 12 INT conforms conforms 1 13 2 13 INT conforms conforms 1 14 2 14 INT conforms conforms 1 15 2 15 INT active-lo level 0 12:A 2 16 INT active-lo level 0 9:A 2 17 INT active-lo level 0 10:A 2 18 INT active-lo level 0 11:A 2 19 SMI conforms conforms 1 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0:A 255 0 NMI conforms conforms 0 0:A 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # 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-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Sat Aug 23 12:25:33 JST 1997 ume@peace.calm.imasy.or.jp:/usr/src/sys/compile/PEACE CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 67108864 (65536K bytes) avail memory = 62832640 (61360K bytes) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 ahc0: rev 0x00 int a irq 17 on pci0.9.0 ahc0: Using left over BIOS settings ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4134MB (8467200 512 byte sectors) cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM cd present [332219 x 2048 byte records] vga0: rev 0x01 int a irq 18 on pci0.10.0 vx0: <3COM 3C905 Fast Etherlink XL PCI> rev 0x00 int a irq 19 on pci0.11.0 mii[*mii*] address 00:60:08:0d:50:7f 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 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 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 flags 0x31 on isa apm: found APM BIOS version 1.2 sb0 at 0x220-0x22f irq 5 drq 1 on isa sb0: sbxvi0 drq 5 on isa sbxvi0: sbmidi0 not found at 0x330 opl0 at 0x388-0x38b on isa opl0: joy0 at 0x201 on isa joy0: joystick changing root device to sd0a APIC_IO: routing 8254 via 8259 on pin 0 WARNING: / was not properly dismounted. SMP: All idle procs online. SMP: *** AUTO *** 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! IP packet filtering initialized, divert disabled, logging disabled =============================================================================== ----Next_Part(Mon_Aug_25_02:16:25_1997_41)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit # # SMP-GENERIC -- Smp 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: SMP-GENERIC,v 1.7 1997/07/26 01:46:02 fsmp Exp $ machine "i386" # SMP does NOT support 386/486 CPUs. #cpu "I386_CPU" #cpu "I486_CPU" #cpu "I586_CPU" cpu "I686_CPU" ident PEACE maxusers 60 # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional, these are the defaults: #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs # Lets always enable the kernel debugger for SMP. options DDB # SMP shouldn't need x87 emulation, disable by default. #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 MFS options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 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 options "CMD640" # work around CMD640 chip deficiency #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 options AHC_TAGENABLE options AHC_SCBPAGING_ENABLE options AHC_ALLOW_MEMIO controller ahc0 #controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr 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 #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # 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 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # device apm0 at isa? flags 0x31 # Advanced Power Management # 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? 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 #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000 vector ieintr #device ie1 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr #device ep0 at isa? port 0x300 net irq 10 vector epintr #device ex0 at isa? port? net irq? vector exintr #device fe0 at isa? port 0x300 net irq ? vector feintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr # Sound Blaster options "SB16MIDI_BASE=0x330" controller snd0 device sb0 at isa? port 0x220 irq 5 conflicts drq 1 vector sbintr device sbxvi0 at isa? conflicts drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 device joy0 at isa? port "IO_GAME" 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 pseudo-device vn 1 pseudo-device bpfilter 4 # Berkeley packet filter # 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 # This provides support for System V shared memory. # options SYSVSHM options SYSVSEM options SYSVMSG ----Next_Part(Mon_Aug_25_02:16:25_1997_41)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ ----Next_Part(Mon_Aug_25_02:16:25_1997_41)---- From owner-freebsd-smp Sun Aug 24 10:45:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11527 for smp-outgoing; Sun, 24 Aug 1997 10:45:55 -0700 (PDT) Received: from lion.activ-consult.de (lion.activ-consult.de [194.221.76.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11521 for ; Sun, 24 Aug 1997 10:45:49 -0700 (PDT) Received: (from dirk@localhost) by lion.activ-consult.de (8.8.7/8.8.7) id TAA29188; Sun, 24 Aug 1997 19:44:42 +0200 (MET DST) Message-ID: <19970824194441.52619@activ-consult.de> Date: Sun, 24 Aug 1997 19:44:41 +0200 From: Dirk Froemberg To: Kenneth Merry Cc: smp@FreeBSD.ORG Subject: Re: SMP on a ASUS P65UP5?! References: <19970823211552.26652@activ-consult.de> <199708232212.QAA29763@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.75 In-Reply-To: <199708232212.QAA29763@pluto.plutotech.com>; from Kenneth Merry on Sat, Aug 23, 1997 at 04:12:34PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Aug 23, 1997 at 04:12:34PM -0600, Kenneth Merry wrote: > Dirk Froemberg wrote... > > Has anybody run FreeBSD-SMP successfully on a ASUS P65UP5 with > > C-P6ND (Dual Pentium Pro Card)? > > Yes, I've been running it on that motherboard since January. It > has been very stable, IMO. > > > [...] > > > > Any ideas? > > Yes, you need to enable MP SPEC v1.4 in your BIOS. From looking at > the mptable output, it looks like version 1.1 is enabled now. So try that, > and see if it works. Hi! That's it! 8) Thanks for the hint. I noticed one strange thing while installing 3.0-970823-SNAP. sysinstall runs only with MP SPEC v1.1. Enabling MP SPEC v1.4 panics the machine while installing some distributions (page fault). Best regards Dirk -- -------------------------------------------------------------- Dirk Froemberg ACTIV-CONSULT GmbH Online Service Center Nordhauser Str. 30 10589 Berlin mailto:dirk.froemberg@activ-consult.de FON +49-30-34602-272 http://www.activ-consult.de/ FAX +49-30-34602-222 -------------------------------------------------------------- From owner-freebsd-smp Sun Aug 24 10:57:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11989 for smp-outgoing; Sun, 24 Aug 1997 10:57:14 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11981 for ; Sun, 24 Aug 1997 10:57:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id LAA12516; Sun, 24 Aug 1997 11:57:07 -0600 (MDT) Message-Id: <199708241757.LAA12516@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dave adkins cc: smp@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include param.h src/sys/i386/isa apic_ipl.s apic_vector.s icu_ipl.s ipl.s ipl_funcs.c src/sys/i386/i386 exception.s locore.s microtime.s simplelock.s In-reply-to: Your message of "Sun, 24 Aug 1997 07:37:01 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 11:57:06 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I applied the fix to the src on freefall. If you've cvsupped since: fsmp 1997/08/23 17:05:38 PDT Modified files: sys/i386/include param.h sys/i386/isa apic_ipl.s apic_vector.s icu_ipl.s ipl.s ipl_funcs.c sys/i386/i386 exception.s locore.s microtime.s simplelock.s and are experiencing lockups during boot, grab the newest ipl_funcs.c: fsmp 1997/08/24 10:26:38 PDT Modified files: sys/i386/isa ipl_funcs.c Revision Changes Path 1.4 +10 -11 src/sys/i386/isa/ipl_funcs.c -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun Aug 24 11:08:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA12627 for smp-outgoing; Sun, 24 Aug 1997 11:08:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA12621 for ; Sun, 24 Aug 1997 11:08:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id MAA12588; Sun, 24 Aug 1997 12:08:27 -0600 (MDT) Message-Id: <199708241808.MAA12588@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Hajimu UMEMOTO cc: smp@freebsd.org Subject: Re: HEADS UP: need status reports!!! In-reply-to: Your message of "Mon, 25 Aug 1997 02:16:28 +0900." <199708241716.CAA00503@peace.calm.imasy.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 12:08:26 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I have a boot time problem with a -current kernel cvsuped at August > 25. The kernel hangs at very begining of boot time with following > messages: > > boot: > Booting 0:sd(0,a)kernel @ 0x100000 > text=0xd5000 data=0x16000 bss=0x4bf3c symbols=[+0xc4+0x4+0x11b38+0x4+0x174ba] > Can't find file kernel.config > total=0x25fffa entry point=0x100000 > > A kernel cvsuped at August 23 had no problem. What's happen around the > recent 2 days? you probably need the fix I just committed. for those behind slow mirrors, here's a patch: ------------------------------- cut --------------------------- *** ipl_funcs.c 1997/08/23 23:15:19 1.6 --- ipl_funcs.c 1997/08/24 18:02:05 *************** *** 160,175 **** return (x); \ } - GENSPL(splbio, cpl |= bio_imask) - GENSPL(splclock, cpl = HWI_MASK | SWI_MASK) - GENSPL(splimp, cpl |= net_imask) - GENSPL(splnet, cpl |= SWI_NET_MASK) - GENSPL(splsoftclock, cpl = SWI_CLOCK_MASK) - GENSPL(splsofttty, cpl |= SWI_TTY_MASK) - GENSPL(splstatclock, cpl |= stat_imask) - GENSPL(splvm, cpl |= net_imask | bio_imask) - - /* * This version has to check for smp_active, * as calling simple_lock() (ie ss_lock) before then deadlocks the system. --- 160,165 ---- *************** *** 189,194 **** --- 179,193 ---- \ return (x); \ } + + GENSPL2(splbio, cpl |= bio_imask) + GENSPL2(splclock, cpl = HWI_MASK | SWI_MASK) + GENSPL2(splimp, cpl |= net_imask) + GENSPL2(splnet, cpl |= SWI_NET_MASK) + GENSPL2(splsoftclock, cpl = SWI_CLOCK_MASK) + GENSPL2(splsofttty, cpl |= SWI_TTY_MASK) + GENSPL2(splstatclock, cpl |= stat_imask) + GENSPL2(splvm, cpl |= net_imask | bio_imask) GENSPL2(splhigh, cpl = HWI_MASK | SWI_MASK) GENSPL2(spltty, cpl |= tty_imask) ------------------------------- cut --------------------------- -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun Aug 24 11:13:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA12773 for smp-outgoing; Sun, 24 Aug 1997 11:13:07 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA12767 for ; Sun, 24 Aug 1997 11:13:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id MAA12617; Sun, 24 Aug 1997 12:12:52 -0600 (MDT) Message-Id: <199708241812.MAA12617@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Dirk Froemberg cc: Kenneth Merry , smp@FreeBSD.ORG Subject: Re: SMP on a ASUS P65UP5?! In-reply-to: Your message of "Sun, 24 Aug 1997 19:44:41 +0200." <19970824194441.52619@activ-consult.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 12:12:52 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > On Sat, Aug 23, 1997 at 04:12:34PM -0600, Kenneth Merry wrote: > > Dirk Froemberg wrote... > > > Has anybody run FreeBSD-SMP successfully on a ASUS P65UP5 with > > > C-P6ND (Dual Pentium Pro Card)? > > > > Yes, I've been running it on that motherboard since January. It > > has been very stable, IMO. > > > > > [...] > > > > > > Any ideas? > > > > Yes, you need to enable MP SPEC v1.4 in your BIOS. From looking at > > the mptable output, it looks like version 1.1 is enabled now. So try that, > > and see if it works. > > Hi! > > That's it! 8) Thanks for the hint. > > I noticed one strange thing while installing 3.0-970823-SNAP. sysinstall > runs only with MP SPEC v1.1. Enabling MP SPEC v1.4 panics the machine > while installing some distributions (page fault). that would be a real bummer if true. did you repeat the experiment enough to say it wasn't just random? is there a specific distribution that exhibits this behaviour? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun Aug 24 11:30:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13789 for smp-outgoing; Sun, 24 Aug 1997 11:30:33 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13757; Sun, 24 Aug 1997 11:30:27 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id DAA06392; Mon, 25 Aug 1997 03:22:22 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id DAA08666; Mon, 25 Aug 1997 03:21:36 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id DAA00334; Mon, 25 Aug 1997 03:21:30 +0900 (JST) Message-Id: <199708241821.DAA00334@peace.calm.imasy.or.jp> To: smp@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: need status reports!!! In-Reply-To: Your message of "Mon, 25 Aug 1997 02:16:28 +0900" <199708241716.CAA00503@peace.calm.imasy.or.jp> References: <199708241716.CAA00503@peace.calm.imasy.or.jp> X-Mailer: Mew version 1.89 on XEmacs 20.3 (Bratislava) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Aug 1997 03:21:30 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970820 Lines: 37 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>>> On Mon, 25 Aug 1997 02:16:28 +0900, Hajimu UMEMOTO said: ume> I have a boot time problem with a -current kernel cvsuped at August ume> 25. The kernel hangs at very begining of boot time with following ume> messages: ume> ume> boot: ume> Booting 0:sd(0,a)kernel @ 0x100000 ume> text=0xd5000 data=0x16000 bss=0x4bf3c symbols=[+0xc4+0x4+0x11b38+0x4+0x174ba] ume> Can't find file kernel.config ume> total=0x25fffa entry point=0x100000 This problem was fixed by: >>>>> On Sun, 24 Aug 1997 10:26:38 -0700 (PDT), Steve Passe said: fsmp> fsmp 1997/08/24 10:26:38 PDT fsmp> fsmp> Modified files: fsmp> sys/i386/isa ipl_funcs.c fsmp> Log: fsmp> Fix a deadlock caused by one of the spl functions being called before fsmp> ss_lock() can run. fsmp> fsmp> Noticed by: dave adkins fsmp> fsmp> Revision Changes Path fsmp> 1.4 +10 -11 src/sys/i386/isa/ipl_funcs.c Thanks! -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ From owner-freebsd-smp Sun Aug 24 12:01:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15749 for smp-outgoing; Sun, 24 Aug 1997 12:01:59 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15733 for ; Sun, 24 Aug 1997 12:01:53 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id OAA25559 for ; Sun, 24 Aug 1997 14:01:44 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma025523; Sun, 24 Aug 97 14:01:34 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id OAA07192 for ; Sun, 24 Aug 1997 14:01:33 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Sun, 24 Aug 1997 14:01:33 -0500 (CDT) From: Kyle Mestery To: freebsd-smp@freebsd.org Subject: New code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I just freshly supped code from 1:30PM Central time, rebuilt a kernel, and rebooted, and now it boots. I will let it run for a while and see what happens. So far so good! Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Sun Aug 24 16:53:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00462 for smp-outgoing; Sun, 24 Aug 1997 16:53:14 -0700 (PDT) Received: from ic.net (qmailr@srv2b.ic.net [152.160.72.21]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00456 for ; Sun, 24 Aug 1997 16:53:12 -0700 (PDT) Received: (qmail 432 invoked from network); 24 Aug 1997 23:52:56 -0000 Received: from unknown (HELO lurch.rickl.org) (152.160.108.29) by unknown with SMTP; 24 Aug 1997 23:52:56 -0000 Received: (from rickl@localhost) by lurch.rickl.org (8.8.7/8.7.3) id TAA14922 for smp@freebsd.org; Sun, 24 Aug 1997 19:52:10 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 24 Aug 1997 19:39:16 -0400 (EDT) From: Rick Lotoczky To: smp@freebsd.org Subject: Show of Hands Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Steve, I have a P6DOF motherboard with a 2940UW Adaptec controller and a NCR '815 controller as well. Since about the 1st of August or so, the SMP kernel has been very unstable. The UP kernel seems to behave well enough to go for days without crashing. The first problems which arose were the SCB issues which were mentioned previously. I found that deleting the AHC extensions in the kernel seemed to resolve this problem. On another note, during a "make world" I started to get an error message that a vnode that was to be allocated couldn't be. I'm not sure if this is a SMP issue or not. Lastly, my MB does is not MP-1.4 capable, only -1.1. No BIOS upgrade exists (at least one that I've been able to find). I am back to the UP kernel now because the SMP kernel crashes so often that I can't get mail out. I will send the mptable -dmesg output to you once I rebuild and reboot the SMP kernel. I have been using the cvsup'd sources since early this year and have not built a SNAP since about then. I've been using the SMP kernel for the past few months or so and it has worked well in the past. Just my $0.02 worth. Rick From owner-freebsd-smp Sun Aug 24 17:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03094 for smp-outgoing; Sun, 24 Aug 1997 17:40:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03077 for ; Sun, 24 Aug 1997 17:40:31 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id SAA14157; Sun, 24 Aug 1997 18:40:27 -0600 (MDT) Message-Id: <199708250040.SAA14157@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Rick Lotoczky cc: smp@FreeBSD.ORG Subject: Re: Show of Hands In-reply-to: Your message of "Sun, 24 Aug 1997 19:39:16 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Aug 1997 18:40:27 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, --- > On another note, during a "make world" I started to get an error message that > a vnode that was to be allocated couldn't be. I'm not sure if this is a SMP > issue or not. VM, but more noticable in SMP. --- > Lastly, my MB does is not MP-1.4 capable, only -1.1. No BIOS upgrade exists > (at least one that I've been able to find). I am back to the UP kernel now > because the SMP kernel crashes so often that I can't get mail out. I will > send the mptable -dmesg output to you once I rebuild and reboot the SMP kernel. if they don't have a 1.4 option, the 1.1 is probably 1.1 + appendix D., otherwise it wouldn't even boot. but when 1.1 and 1.4 are options, the 1.1 is usually 1.1 pre appendix D. which can't deal with PCI busses properly. --- there have been a combination of problems, some SMP, some VM, the past few weeks. The VM problems seem to be more evident on the SMP side, probably timing issues. things are stabilizing, hopefully you will get back to usability soon. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun Aug 24 23:15:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22224 for smp-outgoing; Sun, 24 Aug 1997 23:15:59 -0700 (PDT) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22219 for ; Sun, 24 Aug 1997 23:15:56 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id AAA28742; Mon, 25 Aug 1997 00:15:53 -0600 (MDT) From: Kenneth Merry Message-Id: <199708250615.AAA28742@pluto.plutotech.com> Subject: Re: HEADS UP: need status reports!!! In-Reply-To: <199708231953.NAA08121@Ilsa.StevesCafe.com> from Steve Passe at "Aug 23, 97 01:53:19 pm" To: smp@csn.net (Steve Passe) Date: Mon, 25 Aug 1997 00:15:53 -0600 (MDT) Cc: smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM872489753-28527-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --ELM872489753-28527-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steve Passe wrote... > I need a show of hands: > > Who has tried SMP sources dated August 1 or newer? > > if so: > What was your result, success or failure? Success. > What basic hardware: motherboard make & model, P5/P6? ASUS P/I-P65UP5 w/ C-P6ND CPU board, P6-200's, 256K > Is this the first attempt to run SMP on this hardware? No, I've been running since January. > Did you start with a SNAP or cvsuped source tree? Originally started with a SNAP, have been cvsuping for a long time. > What date? Sometime back in January. I've attached mptable -dmesg -verbose. Ken -- Kenneth Merry ken@plutotech.com --ELM872489753-28527-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=mpt.082597 Content-Description: mptable output Content-Transfer-Encoding: 7bit =============================================================================== MPTable, version 2.0.12 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: 284 version: 1.4 checksum: 0x68 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 27 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 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 10 2 10 INT conforms conforms 2 11 2 11 INT conforms conforms 2 12 2 12 INT conforms conforms 2 15 2 15 INT active-lo level 1 4:A 2 19 INT active-lo level 1 5:A 2 16 INT active-lo level 0 10:A 2 18 INT active-lo level 0 12:A 2 16 INT active-lo level 0 11:A 2 17 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: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # 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 # Rogue hardware: # # Tyan Tomcat II: #options SMP_TIMER_NC # # # SuperMicro P6DNE: #options SMP_TIMER_NC # ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Wed Aug 13 23:16:06 MDT 1997 ken@thunderdome.plutotech.com:/usr/src/sys/compile/panzer CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 128753664 (125736K bytes) 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 DEVFS: ready for devices Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.1.0 chip2: rev 0x02 on pci0.9.0 de0: rev 0x11 int a irq 18 on pci0.10.0 de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.1 de0: address 00:00:c0:5c:d2:be de0: enabling 10baseT port bktr0: rev 0x11 int a irq 17 on pci0.11.0 Hauppauge WinCast/TV, Philips NTSC tuner, dbx stereo. de1: rev 0x12 int a irq 16 on pci0.12.0 de1: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 de1: address 00:00:c0:53:3d:e7 de1: enabling 10baseT port vga0: rev 0x01 int a irq 19 on pci0.13.0 Probing for devices on PCI bus 1: ahc0: rev 0x00 int a irq 19 on pci1.4.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4341MB (8890760 512 byte sectors) ahc0:A:5: refuses WIDE negotiation. Using 8bit transfers st0 at scbus0 target 5 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x13, drive empty ahc1: rev 0x00 int a irq 16 on pci1.5.0 ahc1: aic7880 Wide Channel B, SCSI Id=7, 16/255 SCBs ahc1: waiting for scsi devices to settle scbus1 at ahc1 bus 0 ahc1: target 6 Tagged Queuing Device sd1 at scbus1 target 6 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 8682MB (17781520 512 byte sectors) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 not found at 0x3f8 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0: disabled, not probed. lpt1: disabled, not probed. psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in sndtable_probe(4) installing card 0 installed card 0 Driver name 'Gravis Ultrasound' probe 0xf01fb808 Checking for GUS Plug-n-Play ... Board Vendor ID: GRV0001 Board Serial Number: 00000001 Hardware probed OK gus0 at 0x220 irq 11 drq 5 flags 0x106 on isa sndtable_init_card(4) entered Located card - calling attach routine ad1848_detect(32c) ad1848_detect() - step A ad1848_detect() - step B, test indirect register ad1848_detect() - step C ad1848_detect() - step D, last 4 bits of I12 readonly ad1848: detect - chip revision 0x0a ad1848_detect() - step F ad1848_detect() - step G ad1848_detect() - step H ad1848_detect() - step I ad1848_detect() - step I ad1848_detect() - step K ad1848_detect() - step L ad1848_detect() - Detected OK ad1848_detect(32c) at 0x32c dma 6,5 at 0x220 irq 11 dma 5,6 attach routine finished npx0 on motherboard npx0: INT 16 interface DEVFS: ready to run APIC_IO: routing 8254 via 8259 on pin 0 IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry SMP: All idle procs online. SMP: *** AUTO *** 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) sio1: 1 more silo overflow (total 2) sio1: 1 more silo overflow (total 3) sio1: 1 more silo overflow (total 4) sio1: 1 more silo overflow (total 5) sio1: 1 more silo overflow (total 6) sio1: 1 more silo overflow (total 7) sio1: 1 more silo overflow (total 8) sio1: 1 more silo overflow (total 9) tun0: promiscuous mode enabled sio1: 1 more silo overflow (total 10) sio1: 1 more silo overflow (total 11) sio1: 1 more silo overflow (total 12) pid 2006 (ppp), uid 0: exited on signal 10 sio1: 2 more silo overflows (total 14) sio1: 1 more silo overflow (total 15) sio1: 1 more silo overflow (total 16) sio1: 1 more silo overflow (total 17) sio1: 1 more silo overflow (total 18) sio1: 1 more silo overflow (total 19) sio1: 3 more silo overflows (total 22) pid 3853 (ppp), uid 0: exited on signal 11 sio1: 1 more silo overflow (total 23) sio1: 1 more silo overflow (total 24) sio1: 1 more silo overflow (total 25) sio1: 1 more silo overflow (total 26) sio1: 1 more silo overflow (total 27) sio1: 1 more silo overflow (total 28) sio1: 1 more silo overflow (total 29) sio1: 1 more silo overflow (total 30) sio1: 1 more silo overflow (total 31) sio1: 1 more silo overflow (total 32) sio1: 1 more silo overflow (total 33) sio1: 1 more silo overflow (total 34) sio1: 1 more silo overflow (total 35) sio1: 1 more silo overflow (total 36) sio1: 1 more silo overflow (total 37) sio1: 1 more silo overflow (total 38) sio1: 1 more silo overflow (total 39) sio1: 1 more silo overflow (total 40) sio1: 1 more silo overflow (total 41) sio1: 2 more silo overflows (total 43) sio1: 1 more silo overflow (total 44) sio1: 1 more silo overflow (total 45) sio1: 1 more silo overflow (total 46) sio1: 1 more silo overflow (total 47) sio1: 1 more silo overflow (total 48) sio1: 2 more silo overflows (total 50) sio1: 1 more silo overflow (total 51) sio1: 1 more silo overflow (total 52) sio1: 2 more silo overflows (total 54) sio1: 1 more silo overflow (total 55) sio1: 1 more silo overflow (total 56) sio1: 2 more silo overflows (total 58) sio1: 1 more silo overflow (total 59) sio1: 1 more silo overflow (total 60) sio1: 1 more silo overflow (total 61) sio1: 4 more silo overflows (total 65) sio1: 1 more silo overflow (total 66) sio1: 1 more silo overflow (total 67) sio1: 1 more silo overflow (total 68) sio1: 1 more silo overflow (total 69) sio1: 1 more silo overflow (total 70) sio1: 1 more silo overflow (total 71) sio1: 1 more silo overflow (total 72) sio1: 1 more silo overflow (total 73) sio1: 1 more silo overflow (total 74) sio1: 1 more silo overflow (total 75) sio1: 1 more silo overflow (total 76) sio1: 8 more silo overflows (total 84) sio1: 1 more silo overflow (total 85) sio1: 1 more silo overflow (total 86) sio1: 1 more silo overflow (total 87) sio1: 1 more silo overflow (total 88) sio1: 1 more silo overflow (total 89) sio1: 1 more silo overflow (total 90) sio1: 1 more silo overflow (total 91) pid 5057 (ppp), uid 0: exited on signal 11 sio1: 1 more silo overflow (total 92) sio1: 1 more silo overflow (total 93) sio1: 1 more silo overflow (total 94) sio1: 2 more silo overflows (total 96) pid 10255 (ppp), uid 0: exited on signal 10 pid 10271 (ppp), uid 0: exited on signal 10 sio1: 1 more silo overflow (total 97) sio1: 1 more silo overflow (total 98) sio1: 1 more silo overflow (total 99) pid 10451 (ppp), uid 0: exited on signal 11 pid 10592 (ppp), uid 0: exited on signal 10 pid 10593 (ppp), uid 0: exited on signal 10 sio1: 1 more silo overflow (total 100) pid 10626 (ppp), uid 0: exited on signal 11 pid 10648 (ppp), uid 0: exited on signal 11 sio1: 1 more silo overflow (total 101) pid 10649 (ppp), uid 0: exited on signal 11 sio1: 1 more silo overflow (total 102) sio1: 1 more silo overflow (total 103) sio1: 1 more silo overflow (total 104) sio1: 1 more silo overflow (total 105) sio1: 1 more silo overflow (total 106) sio1: 1 more silo overflow (total 107) sio1: 1 more silo overflow (total 108) sio1: 1 more silo overflow (total 109) sio1: 1 more silo overflow (total 110) sio1: 1 more silo overflow (total 111) sio1: 1 more silo overflow (total 112) sio1: 1 more silo overflow (total 113) sio1: 1 more silo overflow (total 114) sio1: 1 more silo overflow (total 115) sio1: 1 more silo overflow (total 116) sio1: 1 more silo overflow (total 117) sio1: 1 more silo overflow (total 118) sio1: 1 more silo overflow (total 119) sio1: 1 more silo overflow (total 120) sio1: 1 more silo overflow (total 121) sio1: 2 more silo overflows (total 123) sio1: 2 more silo overflows (total 125) sio1: 1 more silo overflow (total 126) sio1: 1 more silo overflow (total 127) sio1: 1 more silo overflow (total 128) sio1: 1 more silo overflow (total 129) sio1: 1 more silo overflow (total 130) sio1: 1 more silo overflow (total 131) sio1: 1 more silo overflow (total 132) sio1: 1 more silo overflow (total 133) sio1: 1 more silo overflow (total 134) pid 12590 (ppp), uid 0: exited on signal 10 sio1: 1 more silo overflow (total 135) sio1: 1 more silo overflow (total 136) sio1: 1 more silo overflow (total 137) sio1: 1 more silo overflow (total 138) sio1: 1 more silo overflow (total 139) sio1: 1 more silo overflow (total 140) sio1: 1 more silo overflow (total 141) sio1: 1 more silo overflow (total 142) sio1: 1 more silo overflow (total 143) sio1: 1 more silo overflow (total 144) sio1: 1 more silo overflow (total 145) sio1: 1 more silo overflow (total 146) sio1: 1 more silo overflow (total 147) sio1: 1 more silo overflow (total 148) sio1: 2 more silo overflows (total 150) sio1: 1 more silo overflow (total 151) sio1: 1 more silo overflow (total 152) sio1: 1 more silo overflow (total 153) sio1: 1 more silo overflow (total 154) sio1: 1 more silo overflow (total 155) sio1: 1 more silo overflow (total 156) sio1: 1 more silo overflow (total 157) sio1: 1 more silo overflow (total 158) pid 13856 (ppp), uid 0: exited on signal 11 sio1: 1 more silo overflow (total 159) sio1: 1 more silo overflow (total 160) sio1: 1 more silo overflow (total 161) sio1: 1 more silo overflow (total 162) sio1: 1 more silo overflow (total 163) sio1: 1 more silo overflow (total 164) sio1: 1 more silo overflow (total 165) sio1: 1 more silo overflow (total 166) sio1: 1 more silo overflow (total 167) sio1: 1 more silo overflow (total 168) sio1: 1 more silo overflow (total 169) sio1: 3 more silo overflows (total 172) sio1: 5 more silo overflows (total 177) sio1: 1 more silo overflow (total 178) sio1: 9 more silo overflows (total 187) sio1: 1 more silo overflow (total 188) sio1: 1 more silo overflow (total 189) sio1: 10 more silo overflows (total 199) sio1: 12 more silo overflows (total 211) sio1: 7 more silo overflows (total 218) sio1: 1 more silo overflow (total 219) sio1: 1 more silo overflow (total 220) sio1: 1 more silo overflow (total 221) sio1: 1 more silo overflow (total 222) sio1: 10 more silo overflows (total 232) sio1: 10 more silo overflows (total 242) sio1: 1 more silo overflow (total 243) sio1: 1 more silo overflow (total 244) sio1: 1 more silo overflow (total 245) sio1: 1 more silo overflow (total 246) sio1: 1 more silo overflow (total 247) sio1: 1 more silo overflow (total 248) sio1: 1 more silo overflow (total 249) sio1: 1 more silo overflow (total 250) sio1: 1 more silo overflow (total 251) sio1: 1 more silo overflow (total 252) sio1: 1 more silo overflow (total 253) sio1: 1 more silo overflow (total 254) sio1: 1 more silo overflow (total 255) sio1: 1 more silo overflow (total 256) sio1: 1 more silo overflow (total 257) sio1: 1 more silo overflow (total 258) sio1: 2 more silo overflows (total 260) sio1: 1 more silo overflow (total 261) sio1: 1 more silo overflow (total 262) sio1: 2 more silo overflows (total 264) sio1: 1 more silo overflow (total 265) sio1: 1 more silo overflow (total 266) sio1: 1 more silo overflow (total 267) sio1: 1 more silo overflow (total 268) sio1: 1 more silo overflow (total 269) sio1: 1 more silo overflow (total 270) sio1: 2 more silo overflows (total 272) sio1: 1 more silo overflow (total 273) sio1: 1 more silo overflow (total 274) sio1: 1 more silo overflow (total 275) sio1: 1 more silo overflow (total 276) sio1: 1 more silo overflow (total 277) sio1: 1 more silo overflow (total 278) sio1: 1 more silo overflow (total 279) sio1: 1 more silo overflow (total 280) sio1: 2 more silo overflows (total 282) sio1: 1 more silo overflow (total 283) sio1: 1 more silo overflow (total 284) sio1: 1 more silo overflow (total 285) sio1: 2 more silo overflows (total 287) sio1: 2 more silo overflows (total 289) sio1: 1 more silo overflow (total 290) sio1: 1 more silo overflow (total 291) sio1: 1 more silo overflow (total 292) sio1: 1 more silo overflow (total 293) sio1: 1 more silo overflow (total 294) sio1: 1 more silo overflow (total 295) sio1: 1 more silo overflow (total 296) sio1: 1 more silo overflow (total 297) sio1: 1 more silo overflow (total 298) sio1: 1 more silo overflow (total 299) sio1: 1 more silo overflow (total 300) sio1: 1 more silo overflow (total 301) sio1: 1 more silo overflow (total 302) sio1: 1 more silo overflow (total 303) sio1: 1 more silo overflow (total 304) sio1: 1 more silo overflow (total 305) sio1: 1 more silo overflow (total 306) sio1: 1 more silo overflow (total 307) sio1: 1 more silo overflow (total 308) sio1: 1 more silo overflow (total 309) sio1: 1 more silo overflow (total 310) sio1: 1 more silo overflow (total 311) sio1: 1 more silo overflow (total 312) sio1: 1 more silo overflow (total 313) sio1: 1 more silo overflow (total 314) sio1: 1 more silo overflow (total 315) sio1: 1 more silo overflow (total 316) sio1: 1 more silo overflow (total 317) sio1: 1 more silo overflow (total 318) sio1: 1 more silo overflow (total 319) sio1: 1 more silo overflow (total 320) sio1: 1 more silo overflow (total 321) pid 1334 (ppp), uid 0: exited on signal 11 =============================================================================== --ELM872489753-28527-0_-- From owner-freebsd-smp Mon Aug 25 10:09:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23435 for smp-outgoing; Mon, 25 Aug 1997 10:09:29 -0700 (PDT) Received: from cepheus.daily.umn.edu (cepheus.daily.umn.edu [128.101.178.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA23424 for ; Mon, 25 Aug 1997 10:09:20 -0700 (PDT) Received: from localhost (fanselow@localhost) by cepheus.daily.umn.edu (8.8.7/8.8.7) with SMTP id MAA08230; Mon, 25 Aug 1997 12:12:07 -0500 (CDT) Date: Mon, 25 Aug 1997 12:12:06 -0500 (CDT) From: "Keith D. Fanselow" To: smp@csn.net cc: smp@freebsd.org Subject: Re:HEADS UP: need status reports!!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I need a show of hands: >> Who has tried SMP sources dated August 1 or newer? >> What was your result, success or failure? Success ... >> What basic hardware: motherboard make & model, P5/P6? AMI Titan-II PCI/EISA P5-90 (2) >> Is this the first attempt to run SMP on this hardware? No. Previous releases + Debian linux, 2.0.30 kernel compiled with the SMP options >> Did you start with a SNAP or cvsuped source tree? SNAP-3.0-970807 =============================================================================== MPTable, version 2.0.13 looking for EBDA pointer @ 0x040e, NOT found searching CMOS 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000fbd90 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fbd90 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x9d mode: Virtual Wire ------------------------------------------------------------------------------- MP default config type: 6 bus: EISA+PCI, APIC: Integrated ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # 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-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970807-SNAP #0: Fri Aug 22 18:26:17 CDT 1997 root@cepheus.daily.umn.edu:/usr/src/sys/compile/KSMP CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 62861312 (61388K bytes) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x11 on pci0.0.0 chip1: rev 0x05 on pci0.2.0 wdc0: rev 0x02 int a irq 14 on pci0.3.0 vga0: rev 0x00 on pci0.8.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:84:56:77, type SMC8216T (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: CMD640B workaround enabled wdc0: unit 0 (wd0): wd0: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 610MB (1249920 sectors), 1240 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface APIC_IO: routing 8254 via 8259 on pin 0 SMP: All idle procs online. SMP: *** AUTO *** 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! =============================================================================== ----------------------------------------------- Keith D. Fanselow System Analyst -- Minnesota Daily Email - fanselow@daily.umn.edu pgp-key available by request or can be found at http://www.daily.umn.edu/~fanselow ----------------------------------------------- From owner-freebsd-smp Mon Aug 25 10:14:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA24347 for smp-outgoing; Mon, 25 Aug 1997 10:14:11 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA24341 for ; Mon, 25 Aug 1997 10:14:08 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id MAA15675; Mon, 25 Aug 1997 12:13:54 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma015527; Mon, 25 Aug 97 12:13:06 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id MAA03009; Mon, 25 Aug 1997 12:13:04 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Mon, 25 Aug 1997 12:13:04 -0500 (CDT) From: Kyle Mestery To: Ade Lovett cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: need status reports!!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > >Who has tried SMP sources dated August 1 or newer? > I am running succesfully. Tyan Tomcat II, dual 120s oc to 133, 64MB RAM, EIDE disks. FreeBSD hope.winternet.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sun Aug 24 22:24:01 CDT 1997 root@hope.winternet.com:/usr/src/sys/compile/HOPE i386 Worl built on Saturday, August 23. No problems, no hangs, everything is working just fine! Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Mon Aug 25 15:14:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15038 for smp-outgoing; Mon, 25 Aug 1997 15:14:56 -0700 (PDT) Received: from sanjuan.cs.washington.edu (sanjuan.cs.washington.edu [128.95.8.118]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15014 for ; Mon, 25 Aug 1997 15:14:42 -0700 (PDT) Received: from localhost (ulbright@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id PAA24695 for ; Mon, 25 Aug 1997 15:14:40 -0700 (PDT) Date: Mon, 25 Aug 1997 15:14:40 -0700 (PDT) From: Christopher Ulbright To: smp@FreeBSD.ORG Subject: write protection settings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, Can someone tell me where write protection bits are set for the kernel text? I'm experiencing a pagefault when setting a breakpoint in my debugger and it seems to occur when writing to the memory address where the bp is to go. -Chris Ulbright SPIN OS Group University of Wasington -------------------- From owner-freebsd-smp Mon Aug 25 15:51:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17926 for smp-outgoing; Mon, 25 Aug 1997 15:51:13 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17911 for ; Mon, 25 Aug 1997 15:51:02 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id IAA00439; Tue, 26 Aug 1997 08:50:35 +1000 Date: Tue, 26 Aug 1997 08:50:35 +1000 From: Bruce Evans Message-Id: <199708252250.IAA00439@godzilla.zeta.org.au> To: smp@FreeBSD.ORG, ulbright@cs.washington.edu Subject: Re: write protection settings Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Can someone tell me where write protection bits are set for the kernel >text? In locore.s. >I'm experiencing a pagefault when setting a breakpoint in my >debugger and it seems to occur when writing to the memory address where >the bp is to go. That bug was normal for a month or two until a few weeks ago. The bug was in 4MB page handling (which I think isn't used for SMP). The kernel text is normally entirely unprotected when 4MB pages are used (this is another bug; 4MB data section alignment is required to fix it) but ddb attempts to unprotect the text on the fly anyway, and it used to write to wong places in the page tables when the relevant text address is in a 4MB page. Bruce From owner-freebsd-smp Mon Aug 25 19:08:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28291 for smp-outgoing; Mon, 25 Aug 1997 19:08:30 -0700 (PDT) Received: from porky-pig.cs.washington.edu (porky-pig.cs.washington.edu [128.95.2.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28286 for ; Mon, 25 Aug 1997 19:08:27 -0700 (PDT) From: mef@cs.washington.edu Received: (mef@localhost) by porky-pig.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA05721; Mon, 25 Aug 1997 19:08:24 -0700 (PDT) Date: Mon, 25 Aug 1997 19:08:24 -0700 (PDT) Message-Id: <199708260208.TAA05721@porky-pig.cs.washington.edu> To: bde@zeta.org.au CC: smp@FreeBSD.ORG, ulbright@cs.washington.edu In-reply-to: <199708252250.IAA00439@godzilla.zeta.org.au> (message from Bruce Evans on Tue, 26 Aug 1997 08:50:35 +1000) Subject: Re: write protection settings Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Tue, 26 Aug 1997 08:50:35 +1000 From: Bruce Evans >Can someone tell me where write protection bits are set for the kernel >text? In locore.s. Found it and just needed to add a little ifdef to do the map_read_write stuff. Got our ttd debugger to set breakpoints. >I'm experiencing a pagefault when setting a breakpoint in my >debugger and it seems to occur when writing to the memory address where >the bp is to go. That bug was normal for a month or two until a few weeks ago. The bug was in 4MB page handling (which I think isn't used for SMP). The kernel text is normally entirely unprotected when 4MB pages are used (this is another bug; 4MB data section alignment is required to fix it) but ddb attempts to unprotect the text on the fly anyway, and it used to write to wong places in the page tables when the relevant text address is in a 4MB page. We had the 4MB page handling stuff turned off (for reasons specific to our setup). Thanks for responding so quickly. Marc From owner-freebsd-smp Tue Aug 26 13:39:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06470 for smp-outgoing; Tue, 26 Aug 1997 13:39:23 -0700 (PDT) Received: from lion.activ-consult.de (lion.activ-consult.de [194.221.76.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06463 for ; Tue, 26 Aug 1997 13:39:18 -0700 (PDT) Received: (from dirk@localhost) by lion.activ-consult.de (8.8.7/8.8.7) id WAA13197; Tue, 26 Aug 1997 22:38:11 +0200 (MET DST) Message-ID: <19970826223811.00220@activ-consult.de> Date: Tue, 26 Aug 1997 22:38:11 +0200 From: Dirk Froemberg To: Steve Passe Cc: Kenneth Merry , smp@FreeBSD.ORG Subject: Re: SMP on a ASUS P65UP5?! References: <19970824194441.52619@activ-consult.de> <199708241812.MAA12617@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.75 In-Reply-To: <199708241812.MAA12617@Ilsa.StevesCafe.com>; from Steve Passe on Sun, Aug 24, 1997 at 12:12:52PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Aug 24, 1997 at 12:12:52PM -0600, Steve Passe wrote: > > [...] > > > > I noticed one strange thing while installing 3.0-970823-SNAP. sysinstall > > runs only with MP SPEC v1.1. Enabling MP SPEC v1.4 panics the machine > > while installing some distributions (page fault). > > that would be a real bummer if true. did you repeat the experiment enough > to say it wasn't just random? is there a specific distribution that exhibits > this behaviour? Hi! Sometimes things are not the way they seem to be... <8-) I tried to install 3.0-970823-SNAP with MP SPEC v1.1 three times. I chose the following distributions: bin, des/des, manpages and src/sys. The result always was a panic after printing "Attempting to install all selected distributions..". Then I switched over to MP SPEC v1.4. To accelerate the install process I left out the manpages. This try was successful. So I thought the different MP SPEC solved the problem. But using the distributions bin, des/des, manpages and src/sys with MP SPEC v 1.4 crashes the machine a the same point. So the cause is not the MP SPEC but the combination of distributions. Sorry for giving wrong alarm... Best regards Dirk -- -------------------------------------------------------------- Dirk Froemberg ACTIV-CONSULT GmbH Online Service Center Nordhauser Str. 30 10589 Berlin mailto:dirk.froemberg@activ-consult.de FON +49-30-34602-272 http://www.activ-consult.de/ FAX +49-30-34602-222 -------------------------------------------------------------- From owner-freebsd-smp Tue Aug 26 20:58:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03784 for smp-outgoing; Tue, 26 Aug 1997 20:58:17 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03766 for ; Tue, 26 Aug 1997 20:57:41 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id LAA04217 for ; Wed, 27 Aug 1997 11:57:26 +0800 (WST) Message-Id: <199708270357.LAA04217@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: smp@freebsd.org Subject: smp changes Date: Wed, 27 Aug 1997 11:57:25 +0800 From: Peter Wemm Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I committed some changes a while ago: ==== peter 1997/08/26 11:10:38 PDT Modified files: sys/conf files sys/i386/i386 locore.s machdep.c mp_machdep.c mpboot.s mplock.s pmap.c swtch.s trap.c vm_machdep.c sys/i386/include smp.h sys/kern init_main.c Removed files: sys/kern init_smp.c Log: Clean up the SMP AP bootstrap and eliminate the wretched idle procs. - We now have enough per-cpu idle context, the real idle loop has been revived (cpu's halt now with nothing to do). - Some preliminary support for running some operations outside the global lock (eg: zeroing "free but not yet zeroed pages") is present but appears to cause problems. Off by default. - the smp_active sysctl now behaves differently. It's merely a 'true/false' option. Setting smp_active to zero causes the AP's to halt in the idle loop and stop scheduling processes. - bootstrap is a lot safer. Instead of sharing a statically compiled in stack a number of times (which has caused lots of problems) and then abandoning it, we use the idle context to boot the AP's directly. This should help >2 cpu support since the bootlock stuff was in doubt. - print physical apic id in traps.. helps identify private pages getting out of sync. (You don't want to know how much hair I tore out with this!) Modified files: sys/kern kern_shutdown.c sys/i386/i386 mp_machdep.c Log: Correct some things I forgot about until it was too late with smp_active. smp_active = 1 used to indicate that the system had frozen previously started AP's, while smp_active = 0 was "AP's not yet started". I have split this into smp_started (which is set when the AP's come online), and smp_active is left for turning on/off AP scheduling. ==== I wouldn't expect this to change the works/not-works status of the kernel at the moment. I'd like to know if it breaks the kernel that used to work just before the commits for somebody . I had a lot of nightmares trying to get this working even though the final diffs turned out to look depressingly simple. :-] I was first working on this in the beginning of June... :-/ Among the problems to watch out for is one cpu loosing sync with it's private pages. Since we use logical cpuid's stored in the private pages, this is pretty nasty - generally once cpu thinks it's the other one (I was having problems with cpu#0 suddenly "becoming" cpu#1). This breaks the locking, trashes the stacks and causes general unhappiness. This commit clears the way for cpu binding and soft affinity (which gets the best benefit from L1 caches, as well as being virtually essential for the PPro series with a per-cpu L2 cache and (generally) no shared L3 cache) and some other nice things. Cheers, -Peter From owner-freebsd-smp Wed Aug 27 05:38:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA00285 for smp-outgoing; Wed, 27 Aug 1997 05:38:18 -0700 (PDT) Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA00275 for ; Wed, 27 Aug 1997 05:38:14 -0700 (PDT) Received: from cs8p16.ipswich.gil.com.au (cs8p16.ipswich.gil.com.au [203.1.72.159]) by iccu6.ipswich.gil.com.au with SMTP id WAA17211 (8.6.12/IDA-1.6 for ); Wed, 27 Aug 1997 22:36:08 +1000 Message-ID: <199708271236.WAA17211@iccu6.ipswich.gil.com.au> Comments: Authenticated sender is From: "Peter Stubbs" To: smp@FreeBSD.ORG Date: Wed, 27 Aug 1997 22:38:19 +10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: A how does it work question. Priority: normal X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi All, I've been getting this list for ages now. It's the nearest thing to running SMP that I have :{. I've been hoping that by reading the posts I might understand more about how it all works. Without much success I might add. I've been forced to sell my soul lately by doing a couple of MS Win NT courses ( mouths to feed etc.. ). It seems that NT runs a seperate instance of the kernel on each CPU present to provide it's SMP support. Is this the way FBSD smp does it? Is this the only way to do it? Doesn't this mean that lots more memory would be used keeping data for 2 kernels? TIA Peter Peter Stubbs, +061-015-572-849. Remember, you can't spell 'problems' without 'MS'. From owner-freebsd-smp Wed Aug 27 06:22:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA02674 for smp-outgoing; Wed, 27 Aug 1997 06:22:18 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA02669 for ; Wed, 27 Aug 1997 06:22:14 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id IAA20010; Wed, 27 Aug 1997 08:22:03 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma019973; Wed, 27 Aug 97 08:21:51 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id IAA07201; Wed, 27 Aug 1997 08:21:51 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Wed, 27 Aug 1997 08:21:50 -0500 (CDT) From: Kyle Mestery Reply-To: Kyle Mestery To: Peter Stubbs cc: smp@FreeBSD.ORG Subject: Re: A how does it work question. In-Reply-To: <199708271236.WAA17211@iccu6.ipswich.gil.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 27 Aug 1997, Peter Stubbs wrote: > I've been forced to sell my soul lately by doing a couple of MS Win > NT courses ( mouths to feed etc.. ). It seems that NT runs a > seperate instance of the kernel on each CPU present to provide it's > SMP support. > > Is this the way FBSD smp does it? As far as I know, no. There is only one copy of the kernel running. At present, access to the kernel is only allowed for one CPU (except for a few areas), Steve has been working on making it reentrant. > Is this the only way to do it? No. Having the kernel be reentrant is another way. This requires the correct lock "pushdown" into the kernel. Instead of one giant lock, subsystems can each have their own lock, allowing multiple processors to be in different sections of the kernel. This allows for increased parallelism. > Doesn't this mean that lots more memory would be used keeping data > for 2 kernels? > I would assume so, but I dont know for sure. Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Wed Aug 27 07:08:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA05309 for smp-outgoing; Wed, 27 Aug 1997 07:08:24 -0700 (PDT) Received: from chaos.amber.org (root@chaos.amber.org [205.231.232.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05302 for ; Wed, 27 Aug 1997 07:08:20 -0700 (PDT) Received: from chaos.amber.org (petrilli@chaos.amber.org [205.231.232.12]) by chaos.amber.org (8.7.5/8.6.12) with SMTP id KAA20509; Wed, 27 Aug 1997 10:07:23 -0400 (EDT) Date: Wed, 27 Aug 1997 10:07:20 -0400 (EDT) From: Christopher Petrilli To: Kyle Mestery cc: Peter Stubbs , smp@FreeBSD.ORG Subject: Re: A how does it work question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Because of this, wouldn't it be appropriate to say that FreeBSD is an Assymetric MP, not Symmetric? Symmetric means that the kernel runs on each processor, and there is no "one processor" which controls exclusivity to the hardware. Chris On Wed, 27 Aug 1997, Kyle Mestery wrote: > On Wed, 27 Aug 1997, Peter Stubbs wrote: > > > I've been forced to sell my soul lately by doing a couple of MS Win > > NT courses ( mouths to feed etc.. ). It seems that NT runs a > > seperate instance of the kernel on each CPU present to provide it's > > SMP support. > > > > Is this the way FBSD smp does it? > > As far as I know, no. There is only one copy of the kernel running. At > present, access to the kernel is only allowed for one CPU (except for a > few areas), Steve has been working on making it reentrant. > > > Is this the only way to do it? > > No. Having the kernel be reentrant is another way. This requires the > correct lock "pushdown" into the kernel. Instead of one giant lock, > subsystems can each have their own lock, allowing multiple processors to > be in different sections of the kernel. This allows for increased > parallelism. > > > Doesn't this mean that lots more memory would be used keeping data > > for 2 kernels? > > > I would assume so, but I dont know for sure. > > Kyle Mestery > StorageTek's Network Systems Group > 7600 Boone Ave. N., Brooklyn Park, MN 55428 > mesteka@anubis.network.com, mestery@winternet.com > > > From owner-freebsd-smp Wed Aug 27 07:14:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA05744 for smp-outgoing; Wed, 27 Aug 1997 07:14:46 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05731 for ; Wed, 27 Aug 1997 07:14:42 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id JAA27782; Wed, 27 Aug 1997 09:14:30 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma027717; Wed, 27 Aug 97 09:14:09 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id JAA07708; Wed, 27 Aug 1997 09:14:08 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Wed, 27 Aug 1997 09:14:08 -0500 (CDT) From: Kyle Mestery To: Christopher Petrilli cc: Peter Stubbs , smp@FreeBSD.ORG Subject: Re: A how does it work question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 27 Aug 1997, Christopher Petrilli wrote: > Because of this, wouldn't it be appropriate to say that FreeBSD is an > Assymetric MP, not Symmetric? Symmetric means that the kernel runs on > each processor, and there is no "one processor" which controls exclusivity > to the hardware. > The symmetric/assymetric refers to the hardware. This is from Curt Schimmel's book on Cacheing and MP systems: "To be considered an SMP system, all of the CPUs in the system must be connected to a single bus and share a common pool of memory and share access to all I/O devices. Each CPU must also have equal access to the memory and bus, and some form of bus arbitration must be considered. The bus arbitration is usually entirely up to the hardware." In other words, an assymetric-MP system would be a system where each CPU had it's own memory, own bus, etc. Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com > Chris > > On Wed, 27 Aug 1997, Kyle Mestery wrote: > > > On Wed, 27 Aug 1997, Peter Stubbs wrote: > > > > > I've been forced to sell my soul lately by doing a couple of MS Win > > > NT courses ( mouths to feed etc.. ). It seems that NT runs a > > > seperate instance of the kernel on each CPU present to provide it's > > > SMP support. > > > > > > Is this the way FBSD smp does it? > > > > As far as I know, no. There is only one copy of the kernel running. At > > present, access to the kernel is only allowed for one CPU (except for a > > few areas), Steve has been working on making it reentrant. > > > > > Is this the only way to do it? > > > > No. Having the kernel be reentrant is another way. This requires the > > correct lock "pushdown" into the kernel. Instead of one giant lock, > > subsystems can each have their own lock, allowing multiple processors to > > be in different sections of the kernel. This allows for increased > > parallelism. > > > > > Doesn't this mean that lots more memory would be used keeping data > > > for 2 kernels? > > > > > I would assume so, but I dont know for sure. > > > > Kyle Mestery > > StorageTek's Network Systems Group > > 7600 Boone Ave. N., Brooklyn Park, MN 55428 > > mesteka@anubis.network.com, mestery@winternet.com > > > > > > > From owner-freebsd-smp Wed Aug 27 07:16:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA05853 for smp-outgoing; Wed, 27 Aug 1997 07:16:18 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05846 for ; Wed, 27 Aug 1997 07:16:15 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id HAA01067; Wed, 27 Aug 1997 07:18:30 -0700 (PDT) Message-Id: <199708271418.HAA01067@implode.root.com> To: Christopher Petrilli cc: Kyle Mestery , Peter Stubbs , smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 10:07:20 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 27 Aug 1997 07:18:30 -0700 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Because of this, wouldn't it be appropriate to say that FreeBSD is an >Assymetric MP, not Symmetric? Symmetric means that the kernel runs on >each processor, and there is no "one processor" which controls exclusivity >to the hardware. No. FreeBSD's MP is symetric - either CPU may execute kernel code. The issue has to do with concurrency and right now, only one CPU may execute the code at one time. Asymetric MP is something different entirely - in that case, only one CPU ever executes kernel code and it schedules the work for the other CPUs. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Wed Aug 27 07:17:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA05918 for smp-outgoing; Wed, 27 Aug 1997 07:17:38 -0700 (PDT) Received: from chaos.amber.org (root@chaos.amber.org [205.231.232.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05911 for ; Wed, 27 Aug 1997 07:17:32 -0700 (PDT) Received: from chaos.amber.org (petrilli@chaos.amber.org [205.231.232.12]) by chaos.amber.org (8.7.5/8.6.12) with SMTP id KAA20570; Wed, 27 Aug 1997 10:16:42 -0400 (EDT) Date: Wed, 27 Aug 1997 10:16:41 -0400 (EDT) From: Christopher Petrilli To: Kyle Mestery cc: Peter Stubbs , smp@FreeBSD.ORG Subject: Re: A how does it work question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In the end, I would think that software would be the conjstriction point (in fact seperate memory makes it an MPP system, not an AMP/SMP system). This is the concept behind ccNUMA, etc... Because of the nature of the FreeBSD kernel (and I suppose the probably applies to Linux, but don't know), all I/O is threaded thru the #0 CPU, and thereby it becomes a HUGE bottleneck. Am I correct? This was what I was taught was the definition of a AMP system, was that a single CPU controlled all I/O on the system, which is why you have to go SMP to scale to X, and MPP to keep going from there. Chris On Wed, 27 Aug 1997, Kyle Mestery wrote: > > On Wed, 27 Aug 1997, Christopher Petrilli wrote: > > > Because of this, wouldn't it be appropriate to say that FreeBSD is an > > Assymetric MP, not Symmetric? Symmetric means that the kernel runs on > > each processor, and there is no "one processor" which controls exclusivity > > to the hardware. > > > The symmetric/assymetric refers to the hardware. This is from Curt > Schimmel's book on Cacheing and MP systems: > > "To be considered an SMP system, all of the CPUs in the system must be > connected to a single bus and share a common pool of memory and share > access to all I/O devices. Each CPU must also have equal access to the > memory and bus, and some form of bus arbitration must be considered. The > bus arbitration is usually entirely up to the hardware." > > In other words, an assymetric-MP system would be a system where each CPU > had it's own memory, own bus, etc. > > Kyle Mestery > StorageTek's Network Systems Group > 7600 Boone Ave. N., Brooklyn Park, MN 55428 > mesteka@anubis.network.com, mestery@winternet.com > > > > Chris > > > > On Wed, 27 Aug 1997, Kyle Mestery wrote: > > > > > On Wed, 27 Aug 1997, Peter Stubbs wrote: > > > > > > > I've been forced to sell my soul lately by doing a couple of MS Win > > > > NT courses ( mouths to feed etc.. ). It seems that NT runs a > > > > seperate instance of the kernel on each CPU present to provide it's > > > > SMP support. > > > > > > > > Is this the way FBSD smp does it? > > > > > > As far as I know, no. There is only one copy of the kernel running. At > > > present, access to the kernel is only allowed for one CPU (except for a > > > few areas), Steve has been working on making it reentrant. > > > > > > > Is this the only way to do it? > > > > > > No. Having the kernel be reentrant is another way. This requires the > > > correct lock "pushdown" into the kernel. Instead of one giant lock, > > > subsystems can each have their own lock, allowing multiple processors to > > > be in different sections of the kernel. This allows for increased > > > parallelism. > > > > > > > Doesn't this mean that lots more memory would be used keeping data > > > > for 2 kernels? > > > > > > > I would assume so, but I dont know for sure. > > > > > > Kyle Mestery > > > StorageTek's Network Systems Group > > > 7600 Boone Ave. N., Brooklyn Park, MN 55428 > > > mesteka@anubis.network.com, mestery@winternet.com > > > > > > > > > > > > > From owner-freebsd-smp Wed Aug 27 07:25:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA06274 for smp-outgoing; Wed, 27 Aug 1997 07:25:23 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA06269 for ; Wed, 27 Aug 1997 07:25:17 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id HAA01182; Wed, 27 Aug 1997 07:27:49 -0700 (PDT) Message-Id: <199708271427.HAA01182@implode.root.com> To: Christopher Petrilli cc: Kyle Mestery , Peter Stubbs , smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 10:16:41 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 27 Aug 1997 07:27:49 -0700 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In the end, I would think that software would be the conjstriction point >(in fact seperate memory makes it an MPP system, not an AMP/SMP system). >This is the concept behind ccNUMA, etc... > >Because of the nature of the FreeBSD kernel (and I suppose the probably >applies to Linux, but don't know), all I/O is threaded thru the #0 CPU, >and thereby it becomes a HUGE bottleneck. > >Am I correct? No, you are not correct. In FreeBSD, either CPU may service I/O requests. ...they just can't do it simultaneously. This does not mean that FreeBSD is ASMP. Steve is working on some stuff right now that will allow multiple CPUs to simultaneously process interrupts which should help to scale the system better on multiple CPUs, but in any case, this has nothing to do with SMP vs. ASMP. > This was what I was taught was the definition of a AMP >system, was that a single CPU controlled all I/O on the system, which is >why you have to go SMP to scale to X, and MPP to keep going from there. Yes, but that's not what FreeBSD does. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Wed Aug 27 09:39:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA13537 for smp-outgoing; Wed, 27 Aug 1997 09:39:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA13530 for ; Wed, 27 Aug 1997 09:39:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA05609; Wed, 27 Aug 1997 09:37:28 -0700 From: Terry Lambert Message-Id: <199708271637.JAA05609@phaeton.artisoft.com> Subject: Re: A how does it work question. To: petrilli@amber.org (Christopher Petrilli) Date: Wed, 27 Aug 1997 09:37:28 -0700 (MST) Cc: mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG In-Reply-To: from "Christopher Petrilli" at Aug 27, 97 10:16:41 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In the end, I would think that software would be the conjstriction point > (in fact seperate memory makes it an MPP system, not an AMP/SMP system). > This is the concept behind ccNUMA, etc... > > Because of the nature of the FreeBSD kernel (and I suppose the probably > applies to Linux, but don't know), all I/O is threaded thru the #0 CPU, > and thereby it becomes a HUGE bottleneck. This is false. An interrupt may be handled by either CPU. The machine operates in Symmetric I/O or "virtual wire" mode (see the Intel Multiprocessing Specification, version 1.4). > Am I correct? This was what I was taught was the definition of a AMP > system, was that a single CPU controlled all I/O on the system, which is > why you have to go SMP to scale to X, and MPP to keep going from there. I agree with your definition of assymetry. However, in FreeBSD, each CPU is a worker, and all system tasks other than boot are simply "work to do". 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 Aug 27 11:16:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24769 for smp-outgoing; Wed, 27 Aug 1997 11:16:31 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA24736 for ; Wed, 27 Aug 1997 11:16:24 -0700 (PDT) Received: (qmail 1940 invoked by uid 1000); 27 Aug 1997 18:16:33 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 27 Aug 1997 11:16:33 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Kyle Mestery Subject: Re: A how does it work question. Cc: smp@FreeBSD.ORG, Peter Stubbs , Christopher Petrilli Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Kyle Mestery; On 27-Aug-97 you wrote: > > On Wed, 27 Aug 1997, Christopher Petrilli wrote: > > > Because of this, wouldn't it be appropriate to say that FreeBSD is an > > Assymetric MP, not Symmetric? Symmetric means that the kernel runs on > > each processor, and there is no "one processor" which controls > > exclusivity > > to the hardware. > > > The symmetric/assymetric refers to the hardware. This is from Curt > Schimmel's book on Cacheing and MP systems: > > "To be considered an SMP system, all of the CPUs in the system must be > connected to a single bus and share a common pool of memory and share > access to all I/O devices. Each CPU must also have equal access to the > memory and bus, and some form of bus arbitration must be considered. > The > bus arbitration is usually entirely up to the hardware." > > In other words, an assymetric-MP system would be a system where each CPU > had it's own memory, own bus, etc. Not exactly. What you describe here is loosley coupled, vs. tightly coupled. Most SMP machines, as we are used to see, are tightly coupled. Many people will associate loosely coupled with MPP (Massively parallel Processing) and tightly coupled with SMP. But I have seen hybrids before. I never heard before this bit about NT running a kernel per CPU. Sounds stupid even for M$. Their NT architect is (never mind :-) but not stupid. I know 3.51 scaled terribly but never touched 4.0. Simon From owner-freebsd-smp Wed Aug 27 11:27:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25594 for smp-outgoing; Wed, 27 Aug 1997 11:27:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25588 for ; Wed, 27 Aug 1997 11:27:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id MAA29172; Wed, 27 Aug 1997 12:26:36 -0600 (MDT) Message-Id: <199708271826.MAA29172@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: petrilli@amber.org (Christopher Petrilli), mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 09:37:28 PDT." <199708271637.JAA05609@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 12:26:35 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I suppose I should summarize the current state of SMP: - fast intrrrupts no longer use the giant lock. There is a simple lock that prevents more than 1 fast interrupt from being in the kernel at once, but this is strictly because of the way sio and cy are written, not because the kernel couldn't do it, it could (I think!). Specifically they use global variables that they implicitly expect to be non-volatile while they are inside their ISR. If say, tty0 and tty1 both were inside at the same time it would break. This points out a simple fact we will have to deal with: most if not all the drivers are not MP-safe, and each will need work to become so. Its not as simple as making the kernel proper MP-safe, but each and EVERY driver needs work. - regular (slow) interrupts are still controlled by the giant lock. I have rounded up all the accesses of cpl & ipending into 'critical regions', ie the access/modification of cpl/ipending by the spl and ISR functions are now MP-safe. The final step is the removal of the giant lock from regular interrupts. This will require the separation of the ISR mask component added by the ISRs to the cpl into a separate variable and additional code in the spl functions to prevent them from changing cpl while any ISR is inside a critical cpl region. This is what I am working on now. At first there will be a simple lock used to serialize all reg. interrupts as with the fast ints, but once this works I plan to use an array of simple locks, one per IRQ. To go beyond this will again require work on each driver. - John is working on the use of the lock manager to protect all the VM accesses. Once this is ready, he will remove the giant lock from the VM traps. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Aug 27 13:30:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04314 for smp-outgoing; Wed, 27 Aug 1997 13:30:55 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA04306 for ; Wed, 27 Aug 1997 13:30:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06259; Wed, 27 Aug 1997 13:28:07 -0700 From: Terry Lambert Message-Id: <199708272028.NAA06259@phaeton.artisoft.com> Subject: Re: A how does it work question. To: smp@csn.net (Steve Passe) Date: Wed, 27 Aug 1997 13:28:07 -0700 (MST) Cc: terry@lambert.org, petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG In-Reply-To: <199708271826.MAA29172@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 27, 97 12:26:35 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > - fast intrrrupts no longer use the giant lock. There is a simple lock that > prevents more than 1 fast interrupt from being in the kernel at once, > but this is strictly because of the way sio and cy are written, not because > the kernel couldn't do it, it could (I think!). Specifically they > use global variables that they implicitly expect to be non-volatile > while they are inside their ISR. If say, tty0 and tty1 both were inside > at the same time it would break. This points out a simple fact we > will have to deal with: most if not all the drivers are not MP-safe, > and each will need work to become so. Its not as simple as making > the kernel proper MP-safe, but each and EVERY driver needs work. Actually, you need a driver flag, and if it is not set, invoke the simple lock. This would let you set the flag (MPSAFE?) on drivers which didn't have the problem, and allow for a staged migration. At least one driver needs to be safed before the resto of them can be, using it as an example. 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 Aug 27 13:40:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04891 for smp-outgoing; Wed, 27 Aug 1997 13:40:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04872 for ; Wed, 27 Aug 1997 13:40:02 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id OAA29795; Wed, 27 Aug 1997 14:39:03 -0600 (MDT) Message-Id: <199708272039.OAA29795@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 13:28:07 PDT." <199708272028.NAA06259@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 14:39:03 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > - fast intrrrupts no longer use the giant lock. There is a simple lock that > > prevents more than 1 fast interrupt from being in the kernel at once, > > ... > > the kernel proper MP-safe, but each and EVERY driver needs work. > > Actually, you need a driver flag, and if it is not set, invoke the > simple lock. This would let you set the flag (MPSAFE?) on drivers > which didn't have the problem, and allow for a staged migration. > At least one driver needs to be safed before the resto of them can > be, using it as an example. thats already planned. sio.c and cy.c are already MP-safe from the kernel's point of view. The problem is that they are not 'concurrancy-safe', ie they never expected to be run concurrently by more than 1 CPU. This sort of problem is not so well demonstrated with an example driver, as the specific issues will vary from driver to driver. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Aug 27 15:00:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA12440 for smp-outgoing; Wed, 27 Aug 1997 15:00:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA12435 for ; Wed, 27 Aug 1997 15:00:30 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA00591; Wed, 27 Aug 1997 14:59:04 -0700 From: Terry Lambert Message-Id: <199708272159.OAA00591@phaeton.artisoft.com> Subject: Re: A how does it work question. To: smp@csn.net (Steve Passe) Date: Wed, 27 Aug 1997 14:59:04 -0700 (MST) Cc: terry@lambert.org, petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG In-Reply-To: <199708272039.OAA29795@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 27, 97 02:39:03 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > the kernel proper MP-safe, but each and EVERY driver needs work. > > > > Actually, you need a driver flag, and if it is not set, invoke the > > simple lock. This would let you set the flag (MPSAFE?) on drivers > > which didn't have the problem, and allow for a staged migration. > > At least one driver needs to be safed before the resto of them can > > be, using it as an example. > > thats already planned. sio.c and cy.c are already MP-safe from the kernel's > point of view. The problem is that they are not 'concurrancy-safe', ie > they never expected to be run concurrently by more than 1 CPU. This > sort of problem is not so well demonstrated with an example driver, as the > specific issues will vary from driver to driver. I don't think I understand the distinction. If by "the are already MP safe" you mean "because of the lock", that's not a flaggable attribute. Something which is MPSAFE flagged would have to allow itself to be reentered by the kernel. Crearly, a single interrupt is not reenterable for the same device context -- only for seperate device contexts, assuming a shared interrupt (PCI?). The flag I'm talking about is a "this driver may be reentered" flag; are you saying it's possible to reenter it on the same CPU, but not on a different CPU? That' might be one issue, but I don't think that would qualify for the MPSAFE flag... 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 Aug 27 15:45:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15261 for smp-outgoing; Wed, 27 Aug 1997 15:45:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15249 for ; Wed, 27 Aug 1997 15:45:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id QAA00398; Wed, 27 Aug 1997 16:44:38 -0600 (MDT) Message-Id: <199708272244.QAA00398@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 14:59:04 PDT." <199708272159.OAA00591@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 16:44:38 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > thats already planned. sio.c and cy.c are already MP-safe from the kernel's > > point of view. The problem is that they are not 'concurrancy-safe', ie > > they never expected to be run concurrently by more than 1 CPU. This > > sort of problem is not so well demonstrated with an example driver, as the > > specific issues will vary from driver to driver. > > I don't think I understand the distinction. If by "the are already > MP safe" you mean "because of the lock", that's not a flaggable > attribute. no, I mean they are MP-safe because I went thru them and added simple-locks around all the regions that are shared by both the ISR and the top half of the kernel. The outer lock in the FAST_INTR() macro is strictly to keep the ISR from being run concurrently, eg CPU0 for an INT on tty0 and CPU1 for an INT on tty1. There are global variables in sio.c that would fail if used concurrantly. --- > The flag I'm talking about is a "this driver may be reentered" flag; > are you saying it's possible to reenter it on the same CPU, but not > on a different CPU? That' might be one issue, but I don't think > that would qualify for the MPSAFE flag... no, there should be no distinction as to CPU, but you obviously can't reenter a fast interrupt from the same CPU, as fast ISRs run to completion, ie they can't be interrupted by themselves. But they could interrupt another CPU which would then attempt to enter the same ISR without the OUTER lock in place to prevent it. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Aug 27 15:56:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15777 for smp-outgoing; Wed, 27 Aug 1997 15:56:06 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA15686 for ; Wed, 27 Aug 1997 15:55:42 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA00730; Wed, 27 Aug 1997 15:54:21 -0700 From: Terry Lambert Message-Id: <199708272254.PAA00730@phaeton.artisoft.com> Subject: Re: A how does it work question. To: smp@csn.net (Steve Passe) Date: Wed, 27 Aug 1997 15:54:21 -0700 (MST) Cc: terry@lambert.org, petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG In-Reply-To: <199708272244.QAA00398@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 27, 97 04:44:38 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ISR from being run concurrently, eg CPU0 for an INT on tty0 and CPU1 for an > INT on tty1. There are global variables in sio.c that would fail if used > concurrantly. So the driver is not kernel reeentrant on seperate device contexts. That's what I said, 8-). For this driver, you'd set the flag. For other drivers (or the sio driver, as a template?) you wouldn't, because reentrering on different devices isn't fatal once the globals have been taken care of. But you are banging on the non-Fast ints right now, so you are going to hit that sooner or later anyway. > > The flag I'm talking about is a "this driver may be reentered" flag; > > are you saying it's possible to reenter it on the same CPU, but not > > on a different CPU? That' might be one issue, but I don't think > > that would qualify for the MPSAFE flag... > > no, there should be no distinction as to CPU, but you obviously can't > reenter a fast interrupt from the same CPU, as fast ISRs run to completion, ie > they can't be interrupted by themselves. But they could interrupt another > CPU which would then attempt to enter the same ISR without the OUTER lock > in place to prevent it. Right. All I'm saying is "make the assertion of the outer lock conditional on the existane of a driver flag". This will let you have some drivers that are kernel reentrant and some that aren't; I guess there is still the issue of reentering on a CPU, but the ISR dispatch should prevent that from happening anyway, right? I mean sevicing an interrupt must not be interrupted -- that's what the SPL stuff does. Yes, I know, the fastintr stuff is a special case, since another interrupt should not be permitted on the same CPU until it completes, but that's not the case for the SPL protected regular INTs. I guess I just assumed that the current fastintr code already protects against reentry on a per kernel basis, and that should be a per CPU basis instead. 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 Wed Aug 27 17:00:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19232 for smp-outgoing; Wed, 27 Aug 1997 17:00:30 -0700 (PDT) Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19226 for ; Wed, 27 Aug 1997 17:00:26 -0700 (PDT) Received: from cs5p16.ipswich.gil.com.au (cs5p16.ipswich.gil.com.au [203.1.72.111]) by iccu6.ipswich.gil.com.au with SMTP id JAA28338 (8.6.12/IDA-1.6 for ); Thu, 28 Aug 1997 09:58:23 +1000 Message-ID: <199708272358.JAA28338@iccu6.ipswich.gil.com.au> Comments: Authenticated sender is From: "Peter Stubbs" To: smp@freebsd.org Date: Thu, 28 Aug 1997 10:00:41 +10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: A how does it work question. Priority: normal In-reply-to: <199708271826.MAA29172@Ilsa.StevesCafe.com> References: Your message of "Wed, 27 Aug 1997 09:37:28 PDT." <199708271637.JAA05609@phaeton.artisoft.com> X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 27 Aug 97, Steve Passe wrote: > from regular interrupts. This will require the separation of the > ISR mask component added by the ISRs to the cpl into a separate > variable and additional code in the spl functions to prevent them > from changing cpl while any ISR is inside a critical cpl region. > This is what I am working on now. At first there will be a > simple lock used to serialize all reg. interrupts as with the > fast ints, but once this works I plan to use an array of simple > locks, one per IRQ. To go beyond this will again require work on > each Wow! This is about where I loose the plot... Try a sentence like this at a party ;} This list is certainly the place for such things, but I guess I'll go back to lurk mode and see if I understand more in 12 months time. Cheers, and thanks for the replies. Peter Peter Stubbs, +061-015-572-849. Remember, you can't spell 'problems' without 'MS'. From owner-freebsd-smp Wed Aug 27 21:02:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05118 for smp-outgoing; Wed, 27 Aug 1997 21:02:13 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA05109 for ; Wed, 27 Aug 1997 21:02:08 -0700 (PDT) Received: (qmail 3063 invoked by uid 1000); 28 Aug 1997 04:02:27 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 27 Aug 1997 21:02:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Christopher Petrilli Subject: Re: A how does it work question. Cc: smp@FreeBSD.ORG, Peter Stubbs , Kyle Mestery Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Christopher Petrilli; On 27-Aug-97 you wrote: > In the end, I would think that software would be the conjstriction point > (in fact seperate memory makes it an MPP system, not an AMP/SMP system). > This is the concept behind ccNUMA, etc... > > Because of the nature of the FreeBSD kernel (and I suppose the probably > applies to Linux, but don't know), all I/O is threaded thru the #0 CPU, > and thereby it becomes a HUGE bottleneck. Correct. I built a Z-80 system like that in 1980. Worked well because CPU cycles were in short supply. Disks were amazingly similar to today`s. Simon From owner-freebsd-smp Wed Aug 27 21:46:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA07155 for smp-outgoing; Wed, 27 Aug 1997 21:46:18 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA07146 for ; Wed, 27 Aug 1997 21:46:00 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id MAA19432; Thu, 28 Aug 1997 12:42:22 +0800 (WST) Message-Id: <199708280442.MAA19432@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Simon Shapiro cc: Christopher Petrilli , smp@FreeBSD.ORG, Peter Stubbs , Kyle Mestery Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 21:02:27 MST." Date: Thu, 28 Aug 1997 12:42:21 +0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > Hi Christopher Petrilli; On 27-Aug-97 you wrote: > > In the end, I would think that software would be the conjstriction point > > (in fact seperate memory makes it an MPP system, not an AMP/SMP system). > > This is the concept behind ccNUMA, etc... > > > > Because of the nature of the FreeBSD kernel (and I suppose the probably > > applies to Linux, but don't know), all I/O is threaded thru the #0 CPU, > > and thereby it becomes a HUGE bottleneck. > > Correct. I built a Z-80 system like that in 1980. Worked well because CPU > cycles were in short supply. Disks were amazingly similar to today`s. > > Simon Again, no, this is not correct. All cpu's share the IO, interrupt, scheduling etc load evenly. Once the FreeBSD kernel is running in SMP mode, there is no difference at all in behavior between the cpus except that only cpu#0 will do a final shutdown and reset of the system (an MPSPEC requirement). Interrupt handling is interleaved between cpus, but if a cpu is "in" the kernel when an interrupt happens, it will handle the interrupt. This is because (for the moment), when one cpu is executing code inside the giant lock, the other cpu cannot get into the kernel to service interrupts (except for fast interrupts for sio/cy). It's fully symmetric (all cpu's are equal), just not reentrant enough in general (yet). (However, I vaguely recall something about NMI only being handled on the BSP though) Cheers, -Peter From owner-freebsd-smp Wed Aug 27 22:38:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA09266 for smp-outgoing; Wed, 27 Aug 1997 22:38:30 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA09256 for ; Wed, 27 Aug 1997 22:38:27 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id XAA01750; Wed, 27 Aug 1997 23:37:34 -0600 (MDT) Message-Id: <199708280537.XAA01750@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Peter Wemm cc: Simon Shapiro , Christopher Petrilli , smp@FreeBSD.ORG, Peter Stubbs , Kyle Mestery Subject: Re: A how does it work question. In-reply-to: Your message of "Thu, 28 Aug 1997 12:42:21 +0800." <199708280442.MAA19432@spinner.dialix.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 23:37:34 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > It's fully symmetric (all cpu's are equal), just not reentrant enough in > general (yet). > > (However, I vaguely recall something about NMI only being handled on the > BSP though) This is true, although I'm not sure if its the correct behaviour. The reasoning behind it is that the NMI INTerrupt is not distributed via the IO APIC, but is strapped to each of the CPUs thru an LINT, typically LINT1. The info as to which is usually, BUT NOT ALWAYS, in the mptable. So you could program all CPUs to respond to the NMI line, but they cant all jump into the kernel at once, so why bother. Right now I have the BSP catch it, the others ignore it. The BSP could be setup to send a stop CPU IPI to each of the other CPUs if necessary. Or all the APs could be programmed to catch it and halt. Its one of those things thats not important enough to spend time on right now... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Aug 27 23:18:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10927 for smp-outgoing; Wed, 27 Aug 1997 23:18:26 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA10918 for ; Wed, 27 Aug 1997 23:18:20 -0700 (PDT) Received: (qmail 4081 invoked by uid 1000); 28 Aug 1997 06:18:37 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199708280442.MAA19432@spinner.dialix.com.au> Date: Wed, 27 Aug 1997 23:18:37 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Peter Wemm Subject: Re: A how does it work question. Cc: Christopher Petrilli , smp@FreeBSD.ORG, Peter Stubbs , Kyle Mestery Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Peter Wemm; On 28-Aug-97 you wrote: > Simon Shapiro wrote: > > > > Hi Christopher Petrilli; On 27-Aug-97 you wrote: > > > In the end, I would think that software would be the conjstriction > > > point > > > (in fact seperate memory makes it an MPP system, not an AMP/SMP > > > system). > > > This is the concept behind ccNUMA, etc... > > > > > > Because of the nature of the FreeBSD kernel (and I suppose the > > > probably > > > applies to Linux, but don't know), all I/O is threaded thru the #0 > > > CPU, > > > and thereby it becomes a HUGE bottleneck. > > > > Correct. I built a Z-80 system like that in 1980. Worked well because > > CPU > > cycles were in short supply. Disks were amazingly similar to today`s. > > > > Simon > > Again, no, this is not correct. All cpu's share the IO, interrupt, > scheduling etc load evenly. Once the FreeBSD kernel is running in SMP > mode, there is no difference at all in behavior between the cpus except > that only cpu#0 will do a final shutdown and reset of the system (an > MPSPEC requirement). My English is bad, my expression ability is horrible. What I did mean above is ``Yes, what you describe is an Asymmetrical MP''. No, I did not mean to imply that this is how FreeBSD works. I know it is symetrical. We called it ``coarse grained''. Now it is rapidly marching towards ``fine grained'' with some lively discussion on how to do it correctly. BTW, I feel Terry is 100% with it on this subject. > Interrupt handling is interleaved between cpus, but if a cpu is "in" the > kernel when an interrupt happens, it will handle the interrupt. This is > because (for the moment), when one cpu is executing code inside the > giant > lock, the other cpu cannot get into the kernel to service interrupts > (except for fast interrupts for sio/cy). > > It's fully symmetric (all cpu's are equal), just not reentrant enough in > general (yet). > > (However, I vaguely recall something about NMI only being handled on the > BSP though) Of course you are right. I will not mention my contribution to the concept of ``giant lock''. But trust that I understand it, although I may not be able to say so in a streight sentence :-) Now, ffs is a different story :-) Simon From owner-freebsd-smp Thu Aug 28 08:14:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA03484 for smp-outgoing; Thu, 28 Aug 1997 08:14:31 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA03479 for ; Thu, 28 Aug 1997 08:14:26 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id IAA00933; Thu, 28 Aug 1997 08:10:55 -0700 From: Terry Lambert Message-Id: <199708281510.IAA00933@phaeton.artisoft.com> Subject: Re: A how does it work question. To: Shimon@i-connect.net (Simon Shapiro) Date: Thu, 28 Aug 1997 08:10:55 -0700 (MST) Cc: peter@spinner.dialix.com.au, petrilli@amber.org, smp@FreeBSD.ORG, peters@gil.com.au, mestery@winternet.com In-Reply-To: from "Simon Shapiro" at Aug 27, 97 11:18:37 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Of course you are right. I will not mention my contribution to the concept > of ``giant lock''. But trust that I understand it, although I may not be > able to say so in a streight sentence :-) > > Now, ffs is a different story :-) FFS *can* be trivial. You just have to divorce blocking and non-blocking operations. The technology to do this is called "soft updates". 8-). For a general soloution instead, which will work with all FS's, even under stacking, a graphical soloution is required. You precompute Warshal's over the graph for everything but the next event to be added. This lets you (1) recompute it in linear time (O(n)), and (2) run dependencies between stacked layers. 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 Thu Aug 28 08:36:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04817 for smp-outgoing; Thu, 28 Aug 1997 08:36:02 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04791 for ; Thu, 28 Aug 1997 08:35:55 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id KAA02111; Thu, 28 Aug 1997 10:29:58 -0500 (EST) From: "John S. Dyson" Message-Id: <199708281529.KAA02111@dyson.iquest.net> Subject: Re: A how does it work question. In-Reply-To: <199708281510.IAA00933@phaeton.artisoft.com> from Terry Lambert at "Aug 28, 97 08:10:55 am" To: terry@lambert.org (Terry Lambert) Date: Thu, 28 Aug 1997 10:29:58 -0500 (EST) Cc: Shimon@i-connect.net, peter@spinner.dialix.com.au, petrilli@amber.org, smp@FreeBSD.ORG, peters@gil.com.au, mestery@winternet.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > Of course you are right. I will not mention my contribution to the concept > > of ``giant lock''. But trust that I understand it, although I may not be > > able to say so in a streight sentence :-) > > > > Now, ffs is a different story :-) > > FFS *can* be trivial. You just have to divorce blocking and non-blocking > operations. > > The technology to do this is called "soft updates". 8-). > > For a general soloution instead, which will work with all FS's, even > under stacking, a graphical soloution is required. You precompute > Warshal's over the graph for everything but the next event to be > added. This lets you (1) recompute it in linear time (O(n)), and > (2) run dependencies between stacked layers. > Sounds like 72lbs of code to me :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-smp Thu Aug 28 09:43:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA08634 for smp-outgoing; Thu, 28 Aug 1997 09:43:16 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA08615 for ; Thu, 28 Aug 1997 09:42:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA01045; Thu, 28 Aug 1997 09:39:30 -0700 From: Terry Lambert Message-Id: <199708281639.JAA01045@phaeton.artisoft.com> Subject: Re: A how does it work question. To: toor@dyson.iquest.net (John S. Dyson) Date: Thu, 28 Aug 1997 09:39:29 -0700 (MST) Cc: terry@lambert.org, Shimon@i-connect.net, peter@spinner.dialix.com.au, petrilli@amber.org, smp@FreeBSD.ORG, peters@gil.com.au, mestery@winternet.com In-Reply-To: <199708281529.KAA02111@dyson.iquest.net> from "John S. Dyson" at Aug 28, 97 10:29:58 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-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > For a general soloution instead, which will work with all FS's, even > > under stacking, a graphical soloution is required. You precompute > > Warshal's over the graph for everything but the next event to be > > added. This lets you (1) recompute it in linear time (O(n)), and > > (2) run dependencies between stacked layers. > > > Sounds like 72lbs of code to me :-). It's not. It's within 5% of writes to RAM, according to the Ganger/Patt paper, which is a less general soloution to the problem Soft Updates solves (it's FFS specific). The idea is that there is a dependency graph traversal that is static (not dynamic, as it probably needs to be) hard coded in dependency order. The updates which occur at intervals flush the dependency ordered operations to disk. The update code described in the paper was *also* FS specific. The correct way to do this (IMO) is to register a dependency graph at mount time, with a node/node resoloution procedure for each dependency relationship. For FFS, this is just the Ganger/Patt FFS code which runs at the update interval. Since this code was ripped out of FFS proper, this is not additional overhead. The only difference is that after you do this, it's now possible to order dependencies in FS's other than FFS, and between stacked FS layers (by inserting them into a hierarchy, very much like mounted FS's are inserted into your root hiearchy. There's a trivially more expensive registration process at mount, but on the whole it's a large net win: the I/O is still going to be much more expensive than the function pointer dereference and the O(n) traversal to the root of the dependency graph (n=the number of levels in the dependency hierarchy) to insert new "events" (any scheduled "soft" writes are effectively events). Anyway, just reread the Ganger/Patt paper with an eye towards stacking an FS and stil having the updates work, and the "meta" picture becomes pretty obvious pretty fast... 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 Thu Aug 28 12:41:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA16916 for smp-outgoing; Thu, 28 Aug 1997 12:41:14 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA16909 for ; Thu, 28 Aug 1997 12:41:07 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id OAA02677; Thu, 28 Aug 1997 14:39:26 -0500 (EST) From: "John S. Dyson" Message-Id: <199708281939.OAA02677@dyson.iquest.net> Subject: Re: A how does it work question. In-Reply-To: <199708281639.JAA01045@phaeton.artisoft.com> from Terry Lambert at "Aug 28, 97 09:39:29 am" To: terry@lambert.org (Terry Lambert) Date: Thu, 28 Aug 1997 14:39:26 -0500 (EST) Cc: toor@dyson.iquest.net, terry@lambert.org, Shimon@i-connect.net, peter@spinner.dialix.com.au, petrilli@amber.org, smp@FreeBSD.ORG, peters@gil.com.au, mestery@winternet.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > > For a general soloution instead, which will work with all FS's, even > > > under stacking, a graphical soloution is required. You precompute > > > Warshal's over the graph for everything but the next event to be > > > added. This lets you (1) recompute it in linear time (O(n)), and > > > (2) run dependencies between stacked layers. > > > > > Sounds like 72lbs of code to me :-). > > It's not. It's within 5% of writes to RAM, according to the > Ganger/Patt paper, which is a less general soloution to the > problem Soft Updates solves (it's FFS specific). > I hope you didn't take my comment seriously. I have read all of the available literature :-). Another case of my wierd humor backfiring. John From owner-freebsd-smp Thu Aug 28 13:05:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18124 for smp-outgoing; Thu, 28 Aug 1997 13:05:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA18096 for ; Thu, 28 Aug 1997 13:04:59 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01237; Thu, 28 Aug 1997 12:53:59 -0700 From: Terry Lambert Message-Id: <199708281953.MAA01237@phaeton.artisoft.com> Subject: Re: A how does it work question. To: toor@dyson.iquest.net (John S. Dyson) Date: Thu, 28 Aug 1997 12:53:59 -0700 (MST) Cc: terry@lambert.org, toor@dyson.iquest.net, Shimon@i-connect.net, peter@spinner.dialix.com.au, petrilli@amber.org, smp@freebsd.org, peters@gil.com.au, mestery@winternet.com In-Reply-To: <199708281939.OAA02677@dyson.iquest.net> from "John S. Dyson" at Aug 28, 97 02:39:26 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-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I hope you didn't take my comment seriously. I have read all of the > available literature :-). Another case of my wierd humor backfiring. Heh. No problem. Same thing happens to me all the time. 8-). 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 Aug 29 12:33:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23433 for smp-outgoing; Fri, 29 Aug 1997 12:33:32 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA23423 for ; Fri, 29 Aug 1997 12:33:26 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id NAA08591 for ; Fri, 29 Aug 1997 13:33:21 -0600 (MDT) Message-Id: <199708291933.NAA08591@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: new INTerrupt algorithms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 13:33:21 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just committed 2 new algorithmic changes affecting the handling of FAST_INTR()s: Modified files: sys/i386/include smptests.h sys/i386/i386 exception.s mplock.s simplelock.s sys/i386/isa apic_ipl.s apic_vector.s intr_machdep.c intr_machdep.h ipl.s ipl_funcs.c 1: There was a small window during the MP-safe spl function locking where an INT would be steered to a CPU NOT holding the giant lock. This caused sever silo overflow problems on systems doing heavy serial IO. The Task Priority Register value is now raised while spinning on the giant lock to a value higher than that used while spinning on simple locks, eliminating most cases of this problem. Thanx to Dave Adkins for debugging and testing this code. 2: I reworked the priority levels used for FAST_INTR()s to be above those used for all regular (ie INTR()) interrupts. I also changed the mplock code to allow acceptance of FAST_INTR()s while blocking acceptance of INTR()s durint the period that a caller of mplock is spinning on the giant lock. This means that 1 CPU can be inside the kernel for either a syscall or regular INTR() ISR while another CPU can be inside handling an FAST_INTR(). Note that change #2 makes change #1 irrelevant for FAST_INTR()s, but still affects steering of regular INTR()s. Change #1 is built-in. Change #2 is controlled by smptests.h: FAST_HI, and is on by default. You should cvsup the lasest files and use as is. If you have deadlock problens you can turn off FAST_HI to fall back to #1 for both INT types. I would like feedback as to how these changes affect the silo overflow problem and sio responsiveness. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 29 12:56:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24588 for smp-outgoing; Fri, 29 Aug 1997 12:56:15 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24581; Fri, 29 Aug 1997 12:56:07 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id MAA23852; Fri, 29 Aug 1997 12:56:06 -0700 (PDT) Date: Fri, 29 Aug 1997 12:56:05 -0700 (PDT) From: Jaye Mathisen To: current@freebsd.org, smp@freebsd.org Subject: SMP update... 1 minor problem left. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I appreciate the advice I received. I got my box working with SMP and the 1.2.4 DPT driver. Seems to purr along just fine. Consolidating all cards on the primary PCI slots seems to have corrected the problem, although it is disappointing that I'm unable to use half of my available PCI slots (it has 6 PCI and 6 EISA). The video is onboard, so I can't move it to the secondary slots. Anyway, it seems to run great. I'm going to pop in 2 more CPU's and see how it runs with 4. I am getting the occasional panic when using sysinstall to newfs the DPT drive, but if I use manual newfs it's fine. It panics with a lockmgr problem. I'm locking myself or somesuch. To Recap... A Digital ZX6000 MP/2, 2 P6-200's, 512kb cache. 256MB RAM, DPT PM3334UW RAID card, 2940UW, Jaz, 7 4GB Seagate's. fxp0 ethernet. The only weird problem is that I lose my network. ifconfig shows it up, no errors appear on the console, ifconfig down/up doesn't fix it, but a constant ping every second in the background keeps it running fine. Very weird. If you have any ideas, I'd love to hear them. From owner-freebsd-smp Fri Aug 29 15:21:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02182 for smp-outgoing; Fri, 29 Aug 1997 15:21:56 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02162; Fri, 29 Aug 1997 15:21:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id QAA09169; Fri, 29 Aug 1997 16:21:32 -0600 (MDT) Message-Id: <199708292221.QAA09169@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Hajimu UMEMOTO cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Fatal trap 12 during boot with -current In-reply-to: Your message of "Sat, 30 Aug 1997 06:10:14 +0900." <199708292110.GAA00357@peace.calm.imasy.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 16:21:32 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, --- > The very recent -current kernel causes fatal trap 12 during boot. > > . . . > Starting final network daemons: moused probably what kills it. is this an lkm? try booting without moused. --- > > Fatal trap 12: page fault while in kernel mode > cpuid = 1 > lapic.id = 16777216 ^^^^^^^^^^^^^^^^^^^ this is totally bogus > fault virtual address = 0xeffd6dac > fault code = super visor read, page not present > instruction pointer = 0x8:0xf019eb23 > stack pointer = 0x10:0xff803e0c > frame pointer = 0x10:0xff803e2c > code segment = base 0x0, limit 0xfffff, type 0x16 > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = Idle > mp_lock = 01000003 > interrupt mask = <- SMP: XXX > kernel: type 12 trap, code=0 > > CPU1 stopping CPUs: 0x00000001 > stopped > Stopped at _pmap_enter+0xb3: movl 0(%ecx),%ecx > db> is this repeatable? we need a 'trace' when it stops, and probably a 'show registers' -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 29 15:52:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04166 for smp-outgoing; Fri, 29 Aug 1997 15:52:23 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04158; Fri, 29 Aug 1997 15:52:13 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id RAA03163; Fri, 29 Aug 1997 17:51:57 -0500 (EST) From: "John S. Dyson" Message-Id: <199708292251.RAA03163@dyson.iquest.net> Subject: Re: Fatal trap 12 during boot with -current In-Reply-To: <199708292221.QAA09169@Ilsa.StevesCafe.com> from Steve Passe at "Aug 29, 97 04:21:32 pm" To: smp@csn.net (Steve Passe) Date: Fri, 29 Aug 1997 17:51:56 -0500 (EST) Cc: ume@calm.imasy.or.jp, current@FreeBSD.ORG, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe said: > Hi, > > --- > > The very recent -current kernel causes fatal trap 12 during boot. > > > > . . . > > Starting final network daemons: moused > > probably what kills it. is this an lkm? try booting without moused. > > --- > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1 > > lapic.id = 16777216 > ^^^^^^^^^^^^^^^^^^^ > > this is totally bogus > > > fault virtual address = 0xeffd6dac > > fault code = super visor read, page not present > > instruction pointer = 0x8:0xf019eb23 > > stack pointer = 0x10:0xff803e0c > > frame pointer = 0x10:0xff803e2c > > code segment = base 0x0, limit 0xfffff, type 0x16 > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = Idle > > mp_lock = 01000003 > > interrupt mask = <- SMP: XXX > > kernel: type 12 trap, code=0 > > > > CPU1 stopping CPUs: 0x00000001 > > stopped > > Stopped at _pmap_enter+0xb3: movl 0(%ecx),%ecx > > db> > > is this repeatable? > > we need a 'trace' when it stops, and probably a 'show registers' > As a wild guess, try 'options "DISABLE_PSE"'. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-smp Fri Aug 29 20:10:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA14801 for smp-outgoing; Fri, 29 Aug 1997 20:10:38 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14781; Fri, 29 Aug 1997 20:10:33 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id WAA26941; Fri, 29 Aug 1997 22:10:31 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma026891; Fri, 29 Aug 97 22:09:58 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id WAA29615; Fri, 29 Aug 1997 22:09:57 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Fri, 29 Aug 1997 22:09:57 -0500 (CDT) From: Kyle Mestery To: freebsd-smp@freebsd.org cc: freebsd-current@freebsd.org Subject: Panics with SMP kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am running a kernel from 8-26-97. Today, I decided to attempt to update my system to current from today. I tried two times, and oboth times the system froze in the middle. The first time I was not near the box, and came home to see nothing on the screen, key presses did nothing. THe second time something strange happened. The screen ahd a long prompt, but when I typed, nothing happened. THen, about 3 seconds later, it accepted my keystrkes that I had typed earlier, as if it was delaying processing them. It finally gave me the debugger screen it had dumped me to, and what I saw was the message "free vnode isnt". Any ideas on this? I am not going to attemp anoher world bill with this kernel until I know what is going on, or if someone wants more info. Here is my setup: Tyan Tomcat II Dual 120s oc to 133 64MB EDO 60ns RAM EIDE disks FreeBSD hope.winternet.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Tue Aug 26 19:53:38 CDT 1997 root@hope.winternet.com:/usr/src/sys/compile/HOPE i386 Anyone else seen this? Should I try a new kernel? THanks! Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Fri Aug 29 23:31:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22058 for smp-outgoing; Fri, 29 Aug 1997 23:31:51 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22049; Fri, 29 Aug 1997 23:31:47 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id PAA10466; Sat, 30 Aug 1997 15:26:24 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id PAA16898; Sat, 30 Aug 1997 15:13:45 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id PAA00265; Sat, 30 Aug 1997 15:13:28 +0900 (JST) Message-Id: <199708300613.PAA00265@peace.calm.imasy.or.jp> To: toor@dyson.iquest.net Cc: smp@csn.net, current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Fatal trap 12 during boot with -current In-Reply-To: Your message of "Fri, 29 Aug 1997 17:51:56 -0500 (EST)" <199708292251.RAA03163@dyson.iquest.net> References: <199708292251.RAA03163@dyson.iquest.net> X-Mailer: Mew version 1.90 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 30 Aug 1997 15:13:27 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970826 Lines: 13 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >>>>> On Fri, 29 Aug 1997 17:51:56 -0500 (EST), "John S. Dyson" said: toor> As a wild guess, try 'options "DISABLE_PSE"'. I tried it. But, I has same result. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ From owner-freebsd-smp Fri Aug 29 23:31:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22044 for smp-outgoing; Fri, 29 Aug 1997 23:31:41 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22037; Fri, 29 Aug 1997 23:31:37 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id PAA10465; Sat, 30 Aug 1997 15:26:23 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id PAA16893; Sat, 30 Aug 1997 15:10:49 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id PAA00256; Sat, 30 Aug 1997 15:10:31 +0900 (JST) Message-Id: <199708300610.PAA00256@peace.calm.imasy.or.jp> To: smp@csn.net Cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Fatal trap 12 during boot with -current In-Reply-To: Your message of "Fri, 29 Aug 1997 16:21:32 -0600" <199708292221.QAA09169@Ilsa.StevesCafe.com> References: <199708292221.QAA09169@Ilsa.StevesCafe.com> X-Mailer: Mew version 1.90 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 30 Aug 1997 15:10:31 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970826 Lines: 61 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >>>>> On Fri, 29 Aug 1997 16:21:32 -0600, Steve Passe said: smp> > Starting final network daemons: moused It's my mistake. This is mountd, not moused. Sorry. smp> probably what kills it. is this an lkm? try booting without moused. I'm using LKM version of NFS. I'm sure all LKM modules was rebuild by make world. I changed rc.conf to nfs_client_enable="NO" nfs_server_enable="NO" due to disable NFS code, and reboot. But, I had same result. smp> is this repeatable? Yes, the kernel isn't boot at all. But, the kernel build at Aug 25 is still bootable. smp> we need a 'trace' when it stops, and probably a 'show registers' db> show registers cs 0x8 ds 0xf0180010 _kmem_malloc+0x200 es 0xff800010 _runtime ss 0x10 eax 0xeffd6d1c ecx 0xeffd6d1c edx 0xefc00000 _PTmap ebx 0x927000 esp 0xff803d00 _idlestack+0xd00 ebp 0xff803d20 _idlestack+0xd20 esi 0xf5b47000 edi 0xf01eeddc _kernel_pmap_store eip 0xf019eb23 _pmap_enter+0xb3 efl 0x10282 _pmap_enter+0xb3 movl 0(%ecx),%ecx db> trace _pmap_enter(f01eeddc,f5b47000,927000,7,1) at _pmap_enter+0xb3 _vm_fault(f01f7720,f5b47000,1,0,0) at _vm_fault+0x1226 _trap_pfault(ff803e54,0,f0542b60,f0540d00,ff803f0c) at _trap_pfault+0xf0 _trap(10,10,ff803f0c,f0540d00,ff803ee4) at _trap+0x31b calltrap() at calltrap+0x35 --- trap 0xc, eip = 0xf5b47920, esp = 0xff803e90, ebp = 0xff803ee4 --- _end(f0542b00,f0542f80,f01ec920,0,ff803f0c) at 0xf5b47920 _igmp_sendpkt(f053f940,16,0,f01da684,f01da754) at _igmp_sendpkt+0x15b _igmp_fasttimo(0,f012c970,ff803fb4,f010dfd9,0) at _igmp_fasttimo+0x51 _pffasttimo(0,c0000000,f08ff000,f08fe600,0) at _pffasttimo+0x21 _softclock(80000000,f0190010,10,0,f08fe600) at _softclock+0x39 doreti_swi() at doreti_swi+0x2a db> -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ From owner-freebsd-smp Fri Aug 29 23:35:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22324 for smp-outgoing; Fri, 29 Aug 1997 23:35:55 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22318; Fri, 29 Aug 1997 23:35:52 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id BAA00332; Sat, 30 Aug 1997 01:35:43 -0500 (EST) From: "John S. Dyson" Message-Id: <199708300635.BAA00332@dyson.iquest.net> Subject: Re: Fatal trap 12 during boot with -current In-Reply-To: <199708300613.PAA00265@peace.calm.imasy.or.jp> from Hajimu UMEMOTO at "Aug 30, 97 03:13:27 pm" To: ume@calm.imasy.or.jp (Hajimu UMEMOTO) Date: Sat, 30 Aug 1997 01:35:43 -0500 (EST) Cc: smp@csn.net, current@FreeBSD.ORG, smp@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hajimu UMEMOTO said: > Hi, > > >>>>> On Fri, 29 Aug 1997 17:51:56 -0500 (EST), > "John S. Dyson" said: > > toor> As a wild guess, try 'options "DISABLE_PSE"'. > > I tried it. But, I has same result. > The reason why I asked is that our 4MB page support is still new, and might have caused your problem. A stack traceback would be useful at this point. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-smp Sat Aug 30 01:52:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA11505 for smp-outgoing; Sat, 30 Aug 1997 01:52:57 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA11492 for ; Sat, 30 Aug 1997 01:52:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id CAA11436 for ; Sat, 30 Aug 1997 02:52:53 -0600 (MDT) Message-Id: <199708300852.CAA11436@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: HEADS UP: another set of changes. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 02:52:52 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Bruce Evans pointed out that the UP kernel uses disable_intr()/enable_intr() to do the equivalant of "critical regions". Now that several CPUs can be in the SMP kernel simultaniously these functions no longer have the desired effect. This last round of changes adds a simplelock to the disable_intr()/enable_intr() functions. Unfortunately the kernel sometimes calls disable_intr()/enable_intr() recursively, so the possibility of deadlock exists. I have already cleaned up clock.c, creating a simplelock to protect its critical regions, and thus eliminating one large area of deadlock. We're at the point where deadlocks are going to become common. Bear with me and help as you can. When you hit one please record all the facts you can, and report them to smp@freebsd.org. Hopefully we will get thru this period before too long... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 07:08:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA18931 for smp-outgoing; Sat, 30 Aug 1997 07:08:35 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA18925 for ; Sat, 30 Aug 1997 07:08:32 -0700 (PDT) Received: from uucp2.iij.ad.jp (uucp2.iij.ad.jp [202.232.2.202]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id XAA24766 for ; Sat, 30 Aug 1997 23:08:26 +0900 (JST) Received: (from uucp@localhost) by uucp2.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id XAA15930 for smp@freebsd.org; Sat, 30 Aug 1997 23:08:26 +0900 Received: from tyd1.tydfam.iijnet.or.jp (tyd1.tydfam.iijnet.or.jp [192.168.1.2]) by tydfam.iijnet.or.jp (8.8.7/3.4W2-uucp) with ESMTP id XAA04402 for ; Sat, 30 Aug 1997 23:07:15 +0900 (JST) Received: from localhost.tydfam.iijnet.or.jp (localhost.tydfam.iijnet.or.jp [127.0.0.1]) by tyd1.tydfam.iijnet.or.jp (8.8.6/3.4Wnomx) with SMTP id XAA00357 for ; Sat, 30 Aug 1997 23:07:14 +0900 (JST) Message-Id: <199708301407.XAA00357@tyd1.tydfam.iijnet.or.jp> X-Authentication-Warning: tyd1.tydfam.iijnet.or.jp: localhost.tydfam.iijnet.or.jp [127.0.0.1] didn't use HELO protocol To: smp@freebsd.org Subject: Q) LKM support Reply-To: ken@tydfam.iijnet.or.jp X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 30 Aug 1997 23:07:12 +0900 From: Takeshi Yamada Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does SMP kernel support LKM already? My 'make world' script still have -DNOLKM. From owner-freebsd-smp Sat Aug 30 07:14:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA19287 for smp-outgoing; Sat, 30 Aug 1997 07:14:05 -0700 (PDT) Received: from schizo.dk.tfs.com (schizo.dk.tfs.com [195.8.133.123] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19282 for ; Sat, 30 Aug 1997 07:14:02 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.19]) by schizo.dk.tfs.com (8.8.5/8.7.3) with ESMTP id QAA15002; Sat, 30 Aug 1997 16:13:28 +0200 (MET DST) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id QAA06666; Sat, 30 Aug 1997 16:13:01 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 02:52:52 MDT." <199708300852.CAA11436@Ilsa.StevesCafe.com> Date: Sat, 30 Aug 1997 16:13:00 +0200 Message-ID: <6664.872950380@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199708300852.CAA11436@Ilsa.StevesCafe.com>, Steve Passe writes: >We're at the point where deadlocks are going to become common. Bear with me >and help as you can. When you hit one please record all the facts you can, >and report them to smp@freebsd.org. Hopefully we will get thru this period >before too long... I pressume that we want to instrument simplelock carefully in the #ifdef DIAGNOSTIC case ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-smp Sat Aug 30 08:13:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21327 for smp-outgoing; Sat, 30 Aug 1997 08:13:00 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21322 for ; Sat, 30 Aug 1997 08:12:54 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id XAA06998; Sat, 30 Aug 1997 23:12:31 +0800 (WST) Message-Id: <199708301512.XAA06998@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: ken@tydfam.iijnet.or.jp cc: smp@FreeBSD.ORG Subject: Re: Q) LKM support In-reply-to: Your message of "Sat, 30 Aug 1997 23:07:12 +0900." <199708301407.XAA00357@tyd1.tydfam.iijnet.or.jp> Date: Sat, 30 Aug 1997 23:12:31 +0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Takeshi Yamada wrote: > Does SMP kernel support LKM already? > My 'make world' script still have -DNOLKM. Yes, and has done so for some time. However, I don't reccomend giving up -DNOLKM just yet if you don't need it. :-) In theory SMP and UP lkm's are compatable, but I wouldn't like to take the risk. Cheers, -Peter From owner-freebsd-smp Sat Aug 30 08:31:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22011 for smp-outgoing; Sat, 30 Aug 1997 08:31:04 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22006; Sat, 30 Aug 1997 08:30:57 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id XAA07166; Sat, 30 Aug 1997 23:30:14 +0800 (WST) Message-Id: <199708301530.XAA07166@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Hajimu UMEMOTO cc: smp@csn.net, current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Fatal trap 12 during boot with -current In-reply-to: Your message of "Sat, 30 Aug 1997 15:10:31 +0900." <199708300610.PAA00256@peace.calm.imasy.or.jp> Date: Sat, 30 Aug 1997 23:30:14 +0800 From: Peter Wemm Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Fri, 29 Aug 1997 16:21:32 -0600, > Steve Passe said: > > smp> > Starting final network daemons: moused > > It's my mistake. This is mountd, not moused. Sorry. > > smp> probably what kills it. is this an lkm? try booting without moused. > > I'm using LKM version of NFS. I'm sure all LKM modules was rebuild > by make world. I changed rc.conf to > > nfs_client_enable="NO" > nfs_server_enable="NO" > > due to disable NFS code, and reboot. But, I had same result. > > smp> is this repeatable? > > Yes, the kernel isn't boot at all. But, the kernel build at Aug 25 is > still bootable. > > smp> we need a 'trace' when it stops, and probably a 'show registers' > > db> show registers > cs 0x8 > ds 0xf0180010 _kmem_malloc+0x200 > es 0xff800010 _runtime > ss 0x10 > eax 0xeffd6d1c > ecx 0xeffd6d1c > edx 0xefc00000 _PTmap > ebx 0x927000 > esp 0xff803d00 _idlestack+0xd00 > ebp 0xff803d20 _idlestack+0xd20 > esi 0xf5b47000 > edi 0xf01eeddc _kernel_pmap_store > eip 0xf019eb23 _pmap_enter+0xb3 > efl 0x10282 > _pmap_enter+0xb3 movl 0(%ecx),%ecx > db> trace > _pmap_enter(f01eeddc,f5b47000,927000,7,1) at _pmap_enter+0xb3 > _vm_fault(f01f7720,f5b47000,1,0,0) at _vm_fault+0x1226 > _trap_pfault(ff803e54,0,f0542b60,f0540d00,ff803f0c) at _trap_pfault+0xf 0 > _trap(10,10,ff803f0c,f0540d00,ff803ee4) at _trap+0x31b > calltrap() at calltrap+0x35 > --- trap 0xc, eip = 0xf5b47920, esp = 0xff803e90, ebp = 0xff803ee4 --- > _end(f0542b00,f0542f80,f01ec920,0,ff803f0c) at 0xf5b47920 > _igmp_sendpkt(f053f940,16,0,f01da684,f01da754) at _igmp_sendpkt+0x15b > _igmp_fasttimo(0,f012c970,ff803fb4,f010dfd9,0) at _igmp_fasttimo+0x51 > _pffasttimo(0,c0000000,f08ff000,f08fe600,0) at _pffasttimo+0x21 > _softclock(80000000,f0190010,10,0,f08fe600) at _softclock+0x39 > doreti_swi() at doreti_swi+0x2a > db> Hmm.. Executing code after _end looks suspicously like another LKM. Do you have any other LKM's? I stronly suggect rm -f /lkm/* and see how you go. Just as a note, I see that your stack is: esp 0xff803d00 _idlestack+0xd00 ebp 0xff803d20 _idlestack+0xd20 It looks like you are getting killed from the software network interrupt handler on a cpu that was running the idle `process' when it was serviced. However, if you are not using an LKM, then the problem may be somewhere else and has caused an access to an invalid kernel address and caused the panic that way. Is the igmp reference an accident, or are you participating in multicast on the machine? (perhaps just routed/gated?) > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@imasy.or.jp ume@iabs.hitachi.co.jp > http://www.imasy.or.jp/~ume/ > Cheers, -Peter From owner-freebsd-smp Sat Aug 30 11:40:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26916 for smp-outgoing; Sat, 30 Aug 1997 11:06:41 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26911 for ; Sat, 30 Aug 1997 11:06:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id MAA16417; Sat, 30 Aug 1997 12:03:17 -0600 (MDT) Message-Id: <199708301803.MAA16417@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 16:13:00 +0200." <6664.872950380@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 12:03:16 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >We're at the point where deadlocks are going to become common. Bear with me > >and help as you can. When you hit one please record all the facts you can, > >and report them to smp@freebsd.org. Hopefully we will get thru this period > >before too long... > > I pressume that we want to instrument simplelock carefully in the > #ifdef DIAGNOSTIC case ? It would be really nice, any one with ideas along that line please speak up (or go for it!). One idea I had was to use the local timer as a watchdog. set it for 10 seconds going into a simplelock. if your not out by then if fires a high priority interrupt that causes a panic. the SMP disable_intr() would have to be reworked a little, and there are probably other areas like ISRs that would ignore it, but it should help some of the time. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 12:01:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28533 for smp-outgoing; Sat, 30 Aug 1997 12:01:31 -0700 (PDT) Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28527; Sat, 30 Aug 1997 12:01:27 -0700 (PDT) Received: (from ume@localhost) by tasogare.imasy.or.jp (8.8.7+2.7Wbeta7/3.4W4-96030215) with UUCP id DAA13020; Sun, 31 Aug 1997 03:45:09 +0900 (JST) Received: from peace.calm.imasy.or.jp (root@peace.calm.imasy.or.jp [158.214.107.233]) by chaos.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CHAOS1.5) with ESMTP id DAA10777; Sun, 31 Aug 1997 03:44:19 +0900 (JST) Received: from localhost (ume@localhost [127.0.0.1]) by peace.calm.imasy.or.jp (8.8.7/3.6Wbeta6-CALM1.0) with ESMTP id DAA00416; Sun, 31 Aug 1997 03:44:00 +0900 (JST) Message-Id: <199708301844.DAA00416@peace.calm.imasy.or.jp> To: peter@spinner.dialix.com.au Cc: smp@csn.net, current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Fatal trap 12 during boot with -current In-Reply-To: Your message of "Sat, 30 Aug 1997 23:30:14 +0800" <199708301530.XAA07166@spinner.dialix.com.au> References: <199708301530.XAA07166@spinner.dialix.com.au> X-Mailer: Mew version 1.90 on XEmacs 20.3 (Bratislava) X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.or.jp/~ume/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 31 Aug 1997 03:43:59 +0900 From: Hajimu UMEMOTO X-Dispatcher: imput version 970826 Lines: 23 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >>>>> On Sat, 30 Aug 1997 23:30:14 +0800, Peter Wemm said: peter> Hmm.. Executing code after _end looks suspicously like another LKM. Do you peter> have any other LKM's? I stronly suggect rm -f /lkm/* and see how you go. Yes, ipfw_mod and linux_mod were loaded. According to your suggestion, I disabled loading ipfw_mod and reboot. Then, the kernel was boot without any problem. :-) peter> Is the igmp reference an accident, or are you participating in multicast on peter> the machine? (perhaps just routed/gated?) Multicast is enabled, and routed is running. Without ipfw_mod loading, this causes no problem. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@imasy.or.jp ume@iabs.hitachi.co.jp http://www.imasy.or.jp/~ume/ > From owner-freebsd-smp Sat Aug 30 12:27:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29469 for smp-outgoing; Sat, 30 Aug 1997 12:27:17 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29460 for ; Sat, 30 Aug 1997 12:27:04 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA07372; Sat, 30 Aug 1997 21:25:35 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 12:03:16 MDT." <199708301803.MAA16417@Ilsa.StevesCafe.com> Date: Sat, 30 Aug 1997 21:25:34 +0200 Message-ID: <7370.872969134@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199708301803.MAA16417@Ilsa.StevesCafe.com>, Steve Passe writes: >Hi, > >> >We're at the point where deadlocks are going to become common. Bear with m >e >> >and help as you can. When you hit one please record all the facts you can, >> >and report them to smp@freebsd.org. Hopefully we will get thru this period >> >before too long... >> >> I pressume that we want to instrument simplelock carefully in the >> #ifdef DIAGNOSTIC case ? > >It would be really nice, any one with ideas along that line please speak >up (or go for it!). > >One idea I had was to use the local timer as a watchdog. set it for 10 second >s >going into a simplelock. if your not out by then if fires a high priority >interrupt that causes a panic. the SMP disable_intr() would have to be >reworked a little, and there are probably other areas like ISRs that would >ignore it, but it should help some of the time. Well, I was thinking more about making it a counting semaphore in that case and printf a warning if the count was unexpected. I know for almost for sure that it will trigger in the vfs/vnode stuff because of nested calls. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-smp Sat Aug 30 12:35:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29648 for smp-outgoing; Sat, 30 Aug 1997 12:35:35 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29642 for ; Sat, 30 Aug 1997 12:35:31 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id NAA16780; Sat, 30 Aug 1997 13:32:08 -0600 (MDT) Message-Id: <199708301932.NAA16780@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 21:25:34 +0200." <7370.872969134@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 13:32:07 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >One idea I had was to use the local timer as a watchdog. set it for 10 second > >s > >going into a simplelock. if your not out by then if fires a high priority > >interrupt that causes a panic. the SMP disable_intr() would have to be > >reworked a little, and there are probably other areas like ISRs that would > >ignore it, but it should help some of the time. > > Well, I was thinking more about making it a counting semaphore in that > case and printf a warning if the count was unexpected. > > I know for almost for sure that it will trigger in the vfs/vnode stuff ^^^^ > because of nested calls. could you elaborate? Do you mean you expect my current disable_intr() stuff to recursively lock? I have run it for about 13 hours now, including a complete buildworld without problem. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 12:45:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29991 for smp-outgoing; Sat, 30 Aug 1997 12:45:58 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29986 for ; Sat, 30 Aug 1997 12:45:51 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA07458; Sat, 30 Aug 1997 21:45:06 +0200 (CEST) To: Steve Passe cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 13:32:07 MDT." <199708301932.NAA16780@Ilsa.StevesCafe.com> Date: Sat, 30 Aug 1997 21:44:49 +0200 Message-ID: <7453.872970289@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199708301932.NAA16780@Ilsa.StevesCafe.com>, Steve Passe writes: >> Well, I was thinking more about making it a counting semaphore in that >> case and printf a warning if the count was unexpected. >> >> I know for almost for sure that it will trigger in the vfs/vnode stuff > ^^^^ >> because of nested calls. > >could you elaborate? Do you mean you expect my current disable_intr() >stuff to recursively lock? I have run it for about 13 hours now, including >a complete buildworld without problem. No, but I am pretty sure there are nested simple_lock() calls in the vnode code. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-smp Sat Aug 30 13:05:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00553 for smp-outgoing; Sat, 30 Aug 1997 13:05:36 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA00548 for ; Sat, 30 Aug 1997 13:05:34 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id OAA16897; Sat, 30 Aug 1997 14:00:29 -0600 (MDT) Message-Id: <199708302000.OAA16897@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 21:44:49 +0200." <7453.872970289@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 14:00:29 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >could you elaborate? Do you mean you expect my current disable_intr() > >stuff to recursively lock? I have run it for about 13 hours now, including > >a complete buildworld without problem. > > No, but I am pretty sure there are nested simple_lock() calls in the > vnode code. I am completely ignorant of the vnode code. Is this belief based on observed lockups? I tried using your(?) recursive MPgetlock stuff in place of simple locks for the disable_intr() code, but it locked b4 the first message came out of the boot sequence. I suspect its called well before cpuid is valid, which is necessary for that flavor to work. I'm pondering another variation of simplelock that looks something like: top: attempt to get the binary lock if successful set holder_id and return if fail compare holder_id to cpuid if same panic, we shouldn't be holding and asking for a binary lock else if legal (0 < holder_id < mp_ncpus) goto top else if smp_active panic, this shouldn't be else ignore, we're just early -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 13:06:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00572 for smp-outgoing; Sat, 30 Aug 1997 13:06:22 -0700 (PDT) Received: from ns.NL.net (ns.NL.net [193.78.240.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA00564 for ; Sat, 30 Aug 1997 13:06:19 -0700 (PDT) Received: from stuyts by ns.NL.net (5.65b/NLnet1.3) id AA27910; Sat, 30 Aug 1997 21:57:16 +0200 Received: from daneel.stuyts.nl (daneel.stuyts.nl [193.78.231.7]) by terminus.stuyts.nl (8.8.7/8.8.5) with ESMTP id VAA23852 for ; Sat, 30 Aug 1997 21:50:14 +0200 (MET DST) Received: (from benst@localhost) by daneel.stuyts.nl (8.8.5/8.8.5) id VAA03287 for smp@FreeBSD.ORG; Sat, 30 Aug 1997 21:49:50 +0200 (MET DST) Message-Id: <199708301949.VAA03287@daneel.stuyts.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Ben Stuyts Date: Sat, 30 Aug 97 21:49:48 +0200 To: smp@FreeBSD.ORG Subject: Can I combine P166 with a P166MMX? Reply-To: ben@stuyts.nl X-Unexpected: The Spanish Inquisition Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I'd like to add a second cpu to my current motherboard (a GA-586DX) and start playing with SMP. It now has a Pentium 166 MHz on it, and these are a bit hard to find now. 166 MMX's are no problem though. Is it possible to mix a standard Pentium with an MMX one? FreeBSD won't be using the MMX features anyway, I guess. (Or will it in the future? Maybe in the X server, or some kind of multimedia app? I guess having one std and one MMX cpu might be confusing then.) For that matter, can I put in a 200 MHz MMX, in the assumption that I will replace the old std 166 also with a 200 MHz MMX somewhere in the future? Need the two cpu's be of the same mask revision? Thanks, Ben From owner-freebsd-smp Sat Aug 30 20:45:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16247 for smp-outgoing; Sat, 30 Aug 1997 20:45:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16241 for ; Sat, 30 Aug 1997 20:45:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id VAA18553; Sat, 30 Aug 1997 21:41:45 -0600 (MDT) Message-Id: <199708310341.VAA18553@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@FreeBSD.ORG Subject: Re: HEADS UP: another set of changes. In-reply-to: Your message of "Sat, 30 Aug 1997 16:13:00 +0200." <6664.872950380@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 21:41:45 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >We're at the point where deadlocks are going to become common. Bear with me > >and help as you can. When you hit one please record all the facts you can, > >and report them to smp@freebsd.org. Hopefully we will get thru this period > >before too long... > > I pressume that we want to instrument simplelock carefully in the > #ifdef DIAGNOSTIC case ? I just committed a debug version of simple_lock that will notice an attempt to recursively get a lock and panic. It will print the cpu id, the lock address and contents. This should put us in pretty good shape to deal with any simple_lock deadlocks that I have introduced in the last week or so. It is ON by default in the new smptests.h file. If you hit this panic do a "trace" and "show registers" command and post the data. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 20:47:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16288 for smp-outgoing; Sat, 30 Aug 1997 20:47:27 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16282 for ; Sat, 30 Aug 1997 20:47:22 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id VAA18598; Sat, 30 Aug 1997 21:47:11 -0600 (MDT) Message-Id: <199708310347.VAA18598@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: ben@stuyts.nl cc: smp@FreeBSD.ORG Subject: Re: Can I combine P166 with a P166MMX? In-reply-to: Your message of "Sat, 30 Aug 1997 21:49:48 +0200." <199708301949.VAA03287@daneel.stuyts.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 21:47:11 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, --- > I'd like to add a second cpu to my current motherboard (a GA-586DX) and start > playing with SMP. It now has a Pentium 166 MHz on it, and these are a bit > hard to find now. 166 MMX's are no problem though. Is it possible to mix a > standard Pentium with an MMX one? FreeBSD won't be using the MMX features > anyway, I guess. (Or will it in the future? Maybe in the X server, or some > kind of multimedia app? I guess having one std and one MMX cpu might be > confusing then.) no idea if this will work, good chance it wont... --- > For that matter, can I put in a 200 MHz MMX, in the assumption that I will > replace the old std 166 also with a 200 MHz MMX somewhere in the future? > > Need the two cpu's be of the same mask revision? there is no simple answer to this, it is best if they are. anything else would be open to possible problems. Its one of those things you have to try to determine. And with SMP constantly undergoing change, if you have problems you don't know what to point at... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sat Aug 30 21:02:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16962 for smp-outgoing; Sat, 30 Aug 1997 21:02:48 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16952 for ; Sat, 30 Aug 1997 21:02:43 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id WAA18700 for ; Sat, 30 Aug 1997 22:02:41 -0600 (MDT) Message-Id: <199708310402.WAA18700@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: smp@freebsd.org Subject: serial console Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 22:02:41 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Sometime last week someone asked about setting up a serial port console for debugging SMP. I lost that mail so hopefully they will read this reply. see: /usr/src/sys/i386/boot/biosboot/README.serial -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD