From owner-freebsd-smp Sun Nov 17 14:06:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17546 for smp-outgoing; Sun, 17 Nov 1996 14:06:05 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17533 for freebsd-smp; Sun, 17 Nov 1996 14:05:46 -0800 (PST) Date: Sun, 17 Nov 1996 14:05:46 -0800 (PST) From: Steve Passe Message-Id: <199611172205.OAA17533@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c mpapic.c sys/i386/include smp.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/17 14:05:39 Modified: i386/i386 mp_machdep.c mpapic.c Log: cleaned up initialization of EISA APIC IO parameters. Submitted by: Peter Wemm tightened up search parameters for MP floating pointer structure. Submitted by: Erich Boleyn Revision Changes Path 1.15 +35 -8 sys/i386/i386/mp_machdep.c 1.18 +51 -28 sys/i386/i386/mpapic.c Modified: i386/include smp.h Log: cleaned up initialization of EISA APIC IO parameters. Submitted by: Peter Wemm Revision Changes Path 1.19 +2 -1 sys/i386/include/smp.h From owner-freebsd-smp Sun Nov 17 14:40:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA19082 for smp-outgoing; Sun, 17 Nov 1996 14:40:21 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA19026 for ; Sun, 17 Nov 1996 14:39:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA06234; Sun, 17 Nov 1996 15:39:19 -0700 Message-Id: <199611172239.PAA06234@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: smp@FreeBSD.org cc: Erich Boleyn Subject: Re: Can test again... In-reply-to: Your message of "Sat, 16 Nov 1996 17:33:44 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Nov 1996 15:39:19 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I grabbed the SMP tree, and have been hacking on it a bit. > > What I've noticed so far are: > > -- mptable-2.0.2.c AND the kernel : Both do the MPS floating pointer > probe wrong. They are searching on 4-byte boundaries (it should > be 16-byte boundaries), and search too many areas. This caused > my test machine to not be recognized correctly. > > The proper probe sequence is to search (again, on 16-byte > boundaries): > > (1) If the EBDA is defined: > -- The first kilobyte of the EBDA > else: > -- The last kilobyte of system base memory. > (2) ROM space between 0xF0000 and 0xFFFFF. > > If you find it anywhere else, it might be a false report (as > mentioned, it did on my test box). I cleaned up the kernel to adhear to the letter of the MP spec., but left mptable.c more liberal. The newest mptable.c is now on the SMP page. general usage of mptable is now: mptable -verbose -dmesg If it doesn't find the MP table, add option -grop I would really appreciate it if everyone would re-grab mptable.c and return the results to me (don't forget args "-verbose -dmesg"). (Russell Vincent, please ignore this request, I already have yours) Note that I have started a page for collecting these results: http://www.freebsd.org/~fsmp/SMP/mptable/mptable.html -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 17 15:12:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20310 for smp-outgoing; Sun, 17 Nov 1996 15:12:09 -0800 (PST) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA20286 for ; Sun, 17 Nov 1996 15:11:49 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vPGRt-0006oV-00; Sun, 17 Nov 1996 15:16:25 -0800 To: Steve Passe cc: smp@freebsd.org Subject: Re: Can test again... In-reply-to: Your message of "Sun, 17 Nov 1996 15:39:19 MST." <199611172239.PAA06234@clem.systemsix.com> Date: Sun, 17 Nov 1996 15:16:25 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Steve! Thanks for responding so quickly on this topic. Steve Passe writes: > > I grabbed the SMP tree, and have been hacking on it a bit. > > > > What I've noticed so far are: > > > > -- mptable-2.0.2.c AND the kernel : Both do the MPS floating pointer > > probe wrong. They are searching on 4-byte boundaries (it should > > be 16-byte boundaries), and search too many areas. This caused > > my test machine to not be recognized correctly. > > > > The proper probe sequence is to search (again, on 16-byte > > boundaries): > > > > (1) If the EBDA is defined: > > -- The first kilobyte of the EBDA > > else: > > -- The last kilobyte of system base memory. > > (2) ROM space between 0xF0000 and 0xFFFFF. > > > > If you find it anywhere else, it might be a false report (as > > mentioned, it did on my test box). > > I cleaned up the kernel to adhear to the letter of the MP spec., but left > mptable.c more liberal. The newest mptable.c is now on the SMP page. I checked out the new "mptable.c", and it should work for most boxes. There is one problem left though. The "last kilobyte of system base memory" should really be stated as PHYSICAL base memory, not BIOS reported memory. In other words, getting this value from the BIOS or from the BIOS data area (at 0x413 in physical RAM) is invalid. The only place to get this value predictably is from the CMOS RTC values. For example on my machine it tried to check from 637K-638K, when it should have tried the 639K-640K area. I am fairly certain of this because version 1.4 of the MP Spec (top of page 4-2) is ambiguous about what is reported at location (40:13h) of the BIOS data area, it actually says to look at 639K-640K or 511K-512K, and the RTC values are known to be the physical RAM amounts. The probe sequence mentioned above (which is also in the sample Intel MPS probe code I have) has been tried on a pretty big list of machines and has always worked so far. > general usage of mptable is now: > > mptable -verbose -dmesg ... Here is the output of the new mptable on my test box (an Intel Alder w/4 150MHz Pentium Pros): -----------------------(start mptable_output)------------------------------ =============================================================================== MPTable, version 2.0.4 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009f800 searching CMOS 'top of mem' @ 0x0009f400 (637K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f77e0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f77e0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x2a mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f77f0 signature: 'PCMP' base table length: 300 version: 1.4 checksum: 0x14 OEM ID: 'INTEL ' Product ID: 'ALDER ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 26 local APIC address: 0xfec08000 extended table length: 180 extended table checksum: 76 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 1 2 0xfbff 4 0x11 AP, usable 6 1 2 0xfbff 1 0x11 AP, usable 6 1 2 0xfbff 2 0x11 AP, usable 6 1 2 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 18 EISA -- I/O APICs: APIC ID Version State Address 14 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 18 0 14 0 INT active-hi edge 18 1 14 1 INT active-hi edge 18 0 14 2 INT active-hi edge 18 3 14 3 INT active-hi edge 18 4 14 4 INT active-hi edge 18 5 14 5 INT active-hi edge 18 6 14 6 INT active-hi edge 18 7 14 7 INT active-hi edge 18 8 14 8 INT conforms level 18 9 14 9 INT active-hi edge 18 10 14 10 INT active-hi edge 18 11 14 11 INT active-hi edge 18 12 14 12 INT active-hi edge 18 13 14 13 INT active-hi edge 18 14 14 14 INT conforms level 18 15 14 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 18 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- bus ID: 1 address type: prefetch address address base: 0xfe900000 address range: 0x100000 -- bus ID: 1 address type: memory address address base: 0xfea00000 address range: 0x100000 -- bus ID: 1 address type: I/O address address base: 0xf000 address range: 0x1000 -- bus ID: 0 address type: memory address address base: 0x8000000 address range: 0xf6900000 -- bus ID: 0 address type: memory address address base: 0xfeb00000 address range: 0x1500000 -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0xf000 -- bus ID: 18 bus info: 0x01 parent bus ID: 0-- bus ID: 0 address modifier: add predefined range: 0x00000000-- bus ID: 0 address modifier: add predefined range: 0x00000001-- bus ID: 1 address modifier: subtract predefined range: 0x00000000-- bus ID: 1 address modifier: subtract predefined range: 0x00000001 ------------------------------------------------------------------------------- dmesg output: 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2-ALPHA #0: Wed Nov 13 15:29:19 1996 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC Calibrating clock(s) relative to mc146818A clock ... i586 clock: 150001401 Hz, i8254 clock: 1193195 Hz CPU: Pentium Pro (147.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x612 Stepping=2 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 67108864 (65536K bytes) avail memory = 62664704 (61196K bytes) eisa0: Probing for devices on the EISA bus ep0: <3Com 3C579-TP EISA Network Adapter> at 0x3000-0x300f, 0x3c80-0x3c89 irq 5 ep0: on eisa0 slot 3 ep0: aui/utp[*AUI*] address 00:20:af:0b:7e:e0 Probing for devices on PCI bus 0: vga0 rev 3 on pci0:12 chip0 rev 5 on pci0:14:0 pci0:15:0: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:1: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:2: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:3: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:4: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:5: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:6: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:7: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] chip1 rev 3 on pci0:25 chip2 rev 3 on pci0:26 Probing for devices on PCI bus 1: ahc0 rev 3 int a irq 15 on pci1:11 ahc0: Using left over BIOS settings ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "iomega jaz 1GB H.71" type 0 removable SCSI 2 sd0(ahc0:0:0): Direct-Access sd0(ahc0:0:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd0 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) (ahc0:1:0): "SEAGATE ST11950N 0009" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 1611MB (3301239 512 byte sectors) (ahc0:2:0): "TOSHIBA CD-ROM XM-3501TA 2694" type 5 removable SCSI 2 cd0(ahc0:2:0): CD-ROM cd0(ahc0:2:0): NOT READY asc:3a,0 Medium not present can't get the size ahc1 rev 3 int a irq 9 on pci1:12 ahc1: aic7870 Wide Channel, SCSI Id=7, 16 SCBs ahc1: Host Adapter Bios disabled. Using default SCSI device parameters ahc1 waiting for scsi devices to settle Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 ed1 not found at 0x300 fe0 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 at 0x378-0x37f on isa lpt1 not probed due to I/O address conflict with lpt0 at 0x378 mse0 not found at 0x23c psm0: disabled, not probed. 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: unit 0 (wd0): wd0: 814MB (1667232 sectors), 1654 cyls, 16 heads, 63 S/T, 512 B/S wdc1 not found at 0x170 bt0 not found at 0x330 uha0 not found at 0x330 aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0 not found at 0x360 ep0 not found at 0x300 ix0 not found at 0x300 le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. changing root device to sd0a ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=4 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=16 # number of INTs =============================================================================== -----------------------(end mptable_output)-------------------------------- -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Sun Nov 17 17:11:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA27097 for smp-outgoing; Sun, 17 Nov 1996 17:11:33 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA27087 for freebsd-smp; Sun, 17 Nov 1996 17:11:24 -0800 (PST) Date: Sun, 17 Nov 1996 17:11:24 -0800 (PST) From: Steve Passe Message-Id: <199611180111.RAA27087@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/17 17:11:20 Modified: i386/i386 mp_machdep.c Log: attempt to fix "> 2 CPUs" failure to run problem you still need to set NCPU to actual CPU count, but kernel will only attempt to use 2. Note: I have no way to test this. It is a TEMPORARY hack till > 2 CPUs are supported. Suggested by: Erich Boleyn Revision Changes Path 1.16 +9 -0 sys/i386/i386/mp_machdep.c From owner-freebsd-smp Mon Nov 18 11:31:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06708 for smp-outgoing; Mon, 18 Nov 1996 11:31:57 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA06702 for ; Mon, 18 Nov 1996 11:31:54 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.3/8.7.3) with ESMTP id LAA18172; Mon, 18 Nov 1996 11:31:34 -0800 (PST) Received: from pdxlx008.intel.com by ichips.intel.com (8.7.4/jIII) id LAA12535; Mon, 18 Nov 1996 11:30:36 -0800 (PST) Received: from pdxlx008 (localhost [127.0.0.1]) by pdxlx008.intel.com (8.7.5/8.7.3) with ESMTP id LAA29817; Mon, 18 Nov 1996 11:31:33 -0800 (PST) Message-Id: <199611181931.LAA29817@pdxlx008.intel.com> To: Steve Passe cc: smp@FreeBSD.org, Erich Boleyn Subject: Re: Can test again... In-reply-to: Your message of "Sun, 17 Nov 1996 15:39:19 MST." <199611172239.PAA06234@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Nov 1996 11:31:32 -0800 From: Wayne Scott Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I would really appreciate it if everyone would re-grab mptable.c and return > the results to me (don't forget args "-verbose -dmesg"). > (Russell Vincent, please ignore this request, I already have yours) > Note that I have started a page for collecting these results: > > http://www.freebsd.org/~fsmp/SMP/mptable/mptable.html Here is the output from my box: HP Vectra XU (2 - P6-200/512K) This is a pre-release version (note the error at the top of the report...) type read: Bad file descriptor =============================================================================== MPTable, version 2.0.2 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009f800 searching CMOS 'top of mem' @ 0x0009f400 (637K) searching default 'top of mem' @ 0x0009fc00 (638K) searching BIOS @ 0x000f0000 MP Table found in BIOS @ physical addr: 0x000f9550 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f9550 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x9f mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f9560 signature: 'PCMP' base table length: 236 version: 1.1 checksum: 0xf0 OEM ID: 'HP ' Product ID: 'XX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 21 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 0 0xfbff 0 0x11 AP, usable 6 1 0 0xfbff -- Bus: Bus ID Type 0 ISA 1 PCI -- I/O APICs: APIC ID Version State Address 16 0x11 usable 0xfec00000 -------------------- That is the end... Here is the dmesg output manually inserted. FreeBSD 2.2-961004-SNAP #0: Fri Nov 15 19:43:07 PST 1996 root@pdxlx009.intel.com:/usr/smp_sys/compile/PDXLX009 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011 cpu1 (AP): apic id: 0, version: 0x00040011 APIC I/O turned OFF by default, see: http://www.freebsd.org/~fsmp/SMP/apicio.html hit to continue...Calibrating clock(s) relative to mc146818A clock... i8254 clock: 1193183 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 67108864 (65536K bytes) avail memory = 62914560 (61440K bytes) Probing for devices on PCI bus 0: chip0 rev 136 on pci0:0 pci0:1: CMD, device=0x0646, class=storage (ide) int a irq 14 [no driver assigned] ahc0 rev 0 int a irq 11 on pci0:2 ahc0: Using left over BIOS settings ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "SEAGATE ST32550N 8302" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2033MB (4165272 512 byte sectors) (ahc0:5:0): "SONY CD-ROM CDU-76S 1.1a" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM cd0(ahc0:5:0): UNIT ATTENTION asc:28,0 cd0(ahc0:5:0): Not ready to ready transition, medium may have changed cd present [400000 x 2048 byte records] vga0 rev 1 int a irq 11 on pci0:11 fxp0 rev 1 int a irq 11 on pci0:14 fxp0: Ethernet address 00:a0:c9:22:7d:cc chip1 rev 2 on pci0:25 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. sio3: disabled, not probed. lpt0 not found at 0xffffffff lpt1 not found at 0xffffffff mse0 not found at 0x23c psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. changing root device to sd0a WARNING: / was not properly dismounted. =========> SECOND CPU LAUNCHED!! <========= cpunumber=1 mp_lock=1 From owner-freebsd-smp Mon Nov 18 13:24:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12520 for smp-outgoing; Mon, 18 Nov 1996 13:24:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA12512 for ; Mon, 18 Nov 1996 13:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA13211; Mon, 18 Nov 1996 14:22:43 -0700 Message-Id: <199611182122.OAA13211@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Wayne Scott Cc: smp@FreeBSD.org Subject: Re: Can test again... In-reply-to: Your message of "Mon, 18 Nov 1996 12:46:34 PST." <199611182046.MAA29956@pdxlx008.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Nov 1996 14:22:43 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > The error in mptable happens every time. > > In /tmp as root running the SMP kernel, with second processor > enables. > > Shell is tcsh. (happens with any shell) > > Output saved like this: > > mptable -dmesg -verbose >& file > > Error message is sent to stderr. I would try compiling and running mptable under the standard, ie NON SMP kernel to see if you get better results. The current SMP kernel is sorely out of sync with -current! Also try it with no redirection. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Nov 18 13:34:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13307 for smp-outgoing; Mon, 18 Nov 1996 13:34:06 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA13279 for ; Mon, 18 Nov 1996 13:33:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA13273; Mon, 18 Nov 1996 14:32:33 -0700 Message-Id: <199611182132.OAA13273@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Wayne Scott cc: smp@FreeBSD.org Subject: Re: Can test again... In-reply-to: Your message of "Mon, 18 Nov 1996 11:31:32 PST." <199611181931.LAA29817@pdxlx008.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Nov 1996 14:32:32 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, >type read: Bad file descriptor I must still be asleep, this ERROR is coming from my code, I was thinking it was a kernel level complaint... I'll look at it after lunch and see whats what. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Nov 18 17:42:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA04326 for smp-outgoing; Mon, 18 Nov 1996 17:42:16 -0800 (PST) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA04318 for ; Mon, 18 Nov 1996 17:42:04 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id RAA15177 for ; Mon, 18 Nov 1996 17:42:46 -0800 Date: Mon, 18 Nov 1996 17:42:45 -0800 (PST) From: Veggy Vinny To: smp@freebsd.org Subject: Hi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Steve, This is what I got from a dmesg, could this be a Intel Neptune based Dual P5 motherboard that has PCI/EISA/ISA slots made by Tyan? FreeBSD 3.0-CURRENT #0: Tue Nov 5 03:09:31 PST 1996 vince@earth.GAIANET.NET:/usr/src/sys-UP/compile/EARTH Calibrating clock(s) relative to mc146818A clock ... i586 clock: 99871231 Hz, i8254 clock: 1193207 Hz CPU: Pentium (99.87-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x3bf real memory = 134217728 (131072K bytes) avail memory = 127295488 (124312K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0 rev 17 on pci0:0 chip1 rev 3 on pci0:2:0 Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-smp Mon Nov 18 18:04:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05631 for smp-outgoing; Mon, 18 Nov 1996 18:04:50 -0800 (PST) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA05621 for ; Mon, 18 Nov 1996 18:04:32 -0800 (PST) Received: from professor.eng.umd.edu (professor.eng.umd.edu [129.2.103.23]) by po1.glue.umd.edu (8.8.2/8.7.3) with ESMTP id VAA03812; Mon, 18 Nov 1996 21:04:26 -0500 (EST) Received: from localhost (chuckr@localhost) by professor.eng.umd.edu (8.8.3/8.7.3) with SMTP id VAA13330; Mon, 18 Nov 1996 21:04:25 -0500 (EST) X-Authentication-Warning: professor.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 18 Nov 1996 21:04:25 -0500 (EST) From: Chuck Robey X-Sender: chuckr@professor.eng.umd.edu To: Veggy Vinny cc: smp@freebsd.org Subject: Re: Hi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 18 Nov 1996, Veggy Vinny wrote: > Hi Steve, > > This is what I got from a dmesg, could this be a Intel Neptune > based Dual P5 motherboard that has PCI/EISA/ISA slots made by Tyan? They don't make a 430NX based dual p5 MB. Maybe they used to. Their current is 430HX, not nx. > > FreeBSD 3.0-CURRENT #0: Tue Nov 5 03:09:31 PST 1996 > vince@earth.GAIANET.NET:/usr/src/sys-UP/compile/EARTH > Calibrating clock(s) relative to mc146818A clock ... i586 clock: 99871231 Hz, i8254 clock: 1193207 Hz > CPU: Pentium (99.87-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > Features=0x3bf > real memory = 134217728 (131072K bytes) > avail memory = 127295488 (124312K bytes) > eisa0: > Probing for devices on the EISA bus > Probing for devices on PCI bus 0: > chip0 rev 17 on > pci0:0 > chip1 rev 3 on pci0:2:0 > > Vince > GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin > > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Mon Nov 18 19:13:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA09537 for smp-outgoing; Mon, 18 Nov 1996 19:13:31 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA09521 for ; Mon, 18 Nov 1996 19:13:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id UAA14964; Mon, 18 Nov 1996 20:12:42 -0700 Message-Id: <199611190312.UAA14964@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Chuck Robey cc: Veggy Vinny , smp@freebsd.org Subject: Re: Hi In-reply-to: Your message of "Mon, 18 Nov 1996 21:04:25 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Nov 1996 20:12:42 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > This is what I got from a dmesg, could this be a Intel Neptune > > based Dual P5 motherboard that has PCI/EISA/ISA slots made by Tyan? > > They don't make a 430NX based dual p5 MB. Maybe they used to. Their > current is 430HX, not nx. > > > > > FreeBSD 3.0-CURRENT #0: Tue Nov 5 03:09:31 PST 1996 > > vince@earth.GAIANET.NET:/usr/src/sys-UP/compile/EARTH > > Calibrating clock(s) relative to mc146818A clock ... i586 clock: 99871231 Hz, i8254 clock: 1193207 Hz > > CPU: Pentium (99.87-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > > Features=0x3bf > > real memory = 134217728 (131072K bytes) > > avail memory = 127295488 (124312K bytes) > > eisa0: > > Probing for devices on the EISA bus > > Probing for devices on PCI bus 0: > > chip0 rev 17 on > > pci0:0 > > chip1 rev 3 on pci0:2:0 > > The eisa0 line does make it look like a Tyan board, but who knows. Perhaps when you swap it out the mystery will be solved! For now I'll just mark it as EISA/Neptune based. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Nov 18 19:17:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA09652 for smp-outgoing; Mon, 18 Nov 1996 19:17:50 -0800 (PST) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA09643 for ; Mon, 18 Nov 1996 19:17:37 -0800 (PST) Received: from professor.eng.umd.edu (professor.eng.umd.edu [129.2.103.23]) by po1.glue.umd.edu (8.8.2/8.7.3) with ESMTP id WAA06653; Mon, 18 Nov 1996 22:17:33 -0500 (EST) Received: from localhost (chuckr@localhost) by professor.eng.umd.edu (8.8.3/8.7.3) with SMTP id WAA12716; Mon, 18 Nov 1996 22:17:33 -0500 (EST) X-Authentication-Warning: professor.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 18 Nov 1996 22:17:32 -0500 (EST) From: Chuck Robey X-Sender: chuckr@professor.eng.umd.edu To: Steve Passe cc: Veggy Vinny , smp@freebsd.org Subject: Re: Hi In-Reply-To: <199611190312.UAA14964@clem.systemsix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 18 Nov 1996, Steve Passe wrote: > Hi, > > > > This is what I got from a dmesg, could this be a Intel Neptune > > > based Dual P5 motherboard that has PCI/EISA/ISA slots made by Tyan? > > > > They don't make a 430NX based dual p5 MB. Maybe they used to. Their > > current is 430HX, not nx. > > > > > > > > FreeBSD 3.0-CURRENT #0: Tue Nov 5 03:09:31 PST 1996 > > > vince@earth.GAIANET.NET:/usr/src/sys-UP/compile/EARTH > > > Calibrating clock(s) relative to mc146818A clock ... i586 clock: 99871231 Hz, i8254 clock: 1193207 Hz > > > CPU: Pentium (99.87-MHz 586-class CPU) > > > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > > > Features=0x3bf > > > real memory = 134217728 (131072K bytes) > > > avail memory = 127295488 (124312K bytes) > > > eisa0: > > > Probing for devices on the EISA bus > > > Probing for devices on PCI bus 0: > > > chip0 rev 17 on > > > pci0:0 > > > chip1 rev 3 on pci0:2:0 > > > > > The eisa0 line does make it look like a Tyan board, but who knows. Perhaps > when you swap it out the mystery will be solved! For now I'll just mark > it as EISA/Neptune based. Steve, I haven't fired up my new machine yet (maybe this weekend) but I am running a Tyan Tomcat 1 here now, one processor on a non smp kernel, would my running your program do me any harm, and you any good? If it would work under current, in a non-smp system, I'd run it, and forward the results. I know with complete confidence what hardware I have here. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Mon Nov 18 20:28:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13085 for smp-outgoing; Mon, 18 Nov 1996 20:28:04 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA13062 for ; Mon, 18 Nov 1996 20:27:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA15354; Mon, 18 Nov 1996 21:27:36 -0700 Message-Id: <199611190427.VAA15354@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Tor Egge Cc: smp@freebsd.org Subject: Re: Can test again... In-reply-to: Your message of "Tue, 19 Nov 1996 05:03:57 +0100." <199611190403.FAA08714@pat.idt.unit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Nov 1996 21:27:36 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Tor wrote: >After a cursory glance at kern/kern_clock.c and i386/isa/clock.c, >I believe that > > - hardclock updates virtual timers only on the process running at the > cpu receiving the clock interrupt. my belief is that without APIC_IO that the hard tick is being sent round-robin between the 2 CPUs, but I have never proved it as this is only a temporary situation. APIC_IO will superceed this and allow all CPUs to service INTs. It is currently the default for APIC_IO to be off till we get the more drastic bugs out. --- > - statclock updates tick counter only on the process running at the cpu > receiving the rtc interrupt. this currently will only be received by the 1st CPU (or a pseudo-random CPU if APIC_IO is enabled). --- >Some of the work should be done for/by all CPUs, and some of the work >should only be done for one of the CPUs (e.g. to avoid the system >clock going at double speed). Perhaps some intercpu communication is needed >to handle these types of things ? it definately is. I have already written the APIC IPI (Inter-Processor Interrupt) routines. These use a mechanism provided by the APICs for sending software INT messages between themselves. Look at the functions: int apicIPI(); int selectedProcsIPI(); int allProcsIPI(); int allButSelfIPI(); int selfIPI(); in i386/include/mpapic.h and i386/i386/mpapic.c. apicIPI does the generic work, the others are wrappers with different targets. You seem to have a good handle on the issues here, care to chew off this task? --- >I'm looking forward to the next -current merge. I know Peter is busy with the 2.2R stuff, but perhaps if enough of us ask politely... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Nov 18 21:07:03 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA14699 for smp-outgoing; Mon, 18 Nov 1996 21:07:03 -0800 (PST) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA14690 for ; Mon, 18 Nov 1996 21:06:58 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id VAA16017; Mon, 18 Nov 1996 21:08:11 -0800 Date: Mon, 18 Nov 1996 21:08:09 -0800 (PST) From: Veggy Vinny To: Chuck Robey cc: smp@freebsd.org Subject: Re: Hi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 18 Nov 1996, Chuck Robey wrote: > On Mon, 18 Nov 1996, Veggy Vinny wrote: > > > This is what I got from a dmesg, could this be a Intel Neptune > > based Dual P5 motherboard that has PCI/EISA/ISA slots made by Tyan? > > They don't make a 430NX based dual p5 MB. Maybe they used to. Their > current is 430HX, not nx. Dunno since I don't have physical access to the machine as I am too far away and the guy that has the machine in the closet is too hard for him to look, this machine is atleast a year old so it has to be something before the 430FX. Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-smp Mon Nov 18 21:31:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA16735 for smp-outgoing; Mon, 18 Nov 1996 21:31:22 -0800 (PST) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA16728 for ; Mon, 18 Nov 1996 21:31:16 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id VAA19508; Mon, 18 Nov 1996 21:32:23 -0800 Date: Mon, 18 Nov 1996 21:32:22 -0800 (PST) From: Veggy Vinny To: Steve Passe cc: Chuck Robey , smp@freebsd.org Subject: Re: Hi In-Reply-To: <199611190312.UAA14964@clem.systemsix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 18 Nov 1996, Steve Passe wrote: > The eisa0 line does make it look like a Tyan board, but who knows. Perhaps > when you swap it out the mystery will be solved! For now I'll just mark > it as EISA/Neptune based. Yep, whatever the board is, it should go on the not recommended list since we have two identical systems and it's nothing but trouble.... I'll let you know what it is when we finally swap the motherboard probably for a ASUS from Rod. Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-smp Tue Nov 19 10:25:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22246 for smp-outgoing; Tue, 19 Nov 1996 10:25:32 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22227 for freebsd-smp; Tue, 19 Nov 1996 10:25:27 -0800 (PST) Date: Tue, 19 Nov 1996 10:25:27 -0800 (PST) From: Steve Passe Message-Id: <199611191825.KAA22227@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/19 10:25:24 Modified: i386/i386 mp_machdep.c Log: derive KERNBASE from #include files instead of hardcoded value. Found by: Tor Egge Revision Changes Path 1.17 +8 -7 sys/i386/i386/mp_machdep.c From owner-freebsd-smp Tue Nov 19 12:56:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05532 for smp-outgoing; Tue, 19 Nov 1996 12:56:16 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA05517 for ; Tue, 19 Nov 1996 12:56:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA19886; Tue, 19 Nov 1996 13:55:50 -0700 Message-Id: <199611192055.NAA19886@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Tor Egge cc: smp@freebsd.org Subject: Re: Can test again... In-reply-to: Your message of "Tue, 19 Nov 1996 20:32:22 +0100." <199611191932.UAA16615@pat.idt.unit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 13:55:50 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Tor Egge wrote: >I performed more tests with the lastest SMP-kernel but without APIC_IO >enabled. > >- CPU usage accounting is broken. The numbers are way too low. They known problem, just not high on the list of things to fix. --- >- syscons & psm conflict is the worst I've ever seen. Makes X > unusable. I cannot remember any normal -current kernel showing > this conflict to that degree. I'm guessing you are probably first SMP tester to use a psm mouse. --- >- Interrupts are lost. e.g. rtc stopped generating interrupts due > to a lost interrupt. I wouldn't expect this on a NON APIC_IO kernel, but who knows??? --- >I just tried a kernel compiled with APIC_IO enabled. I got the message >about reset NOW or press return to continue. I pressed return, and >nothing happened. I'll probably look into this more closely next >week. > >The values of imen and apiciomask were both 0xff2925. this is the INT mask for INTs 0-23, so INTs 1,3,4,6,7,9,10,12,14,15 are unmasked. INTs 2 & 8 (hardclock & RTC) are unmasked later in the boot process. This looks right for the hardware you show in the dmesg you sent. I think you hit the problem I said to expect, Asus has chosen an "odd" way to label the PCI INTs in the mptable: your dmesg: ahc0 rev 0 int a irq 9 on pci0:11 ^ ^ ^^ your mptable: Bus: Bus ID Type 0 PCI 1 ISA I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# INT active-lo level 1 9 2 17 ^ ^ ^^ should(?) be: 0 11:A 17 This entry effectivly says that ISA bus INT9 is connected to APIC INT17. My belief is that it should say PCI bus device11:INTA goes to APIC INT17. The problem is that the current PCI code (sys/pci/pci.c) asks the MP sub-system (get_pci_apic_irq (bus_no, device, pciint)) for the APIC INT to which the device (ahc0) is connected. Since the above entry doesn't parse to a PCI bus entry, it returns "not found". This causes the code to assume case #1 (see below). So it believes the PCI redirection register contents (which will contain INT9) and programs everything to occur on INT9, while the line is evidently attached to APIC INT17. --- Every other PCI bus machine I have encountered either: - 1: doesn't route the PCI INTs to upper (ie above ISA INT15) APIC INT pins, instead depending on the PCI-ISA IRQ redirection hardware to make it work. - 2: routes the PCI INTs to individual upper APIC pins, declaring them like: Bus: Bus ID Type 0 ISA 1 PCI I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# INT active-lo level 1 12:A 2 19 ^ ^^ ^ ^^ - Is there anything in the BIOS that looks like it might affect this behavior? --- My guess is that if you wait for a minute or 2 after hitting return, you will get a timeout from the adaptec controller, ie you're locked because you are missing disk INTs. So, its debate time, is this MP declaration that Asus is using on its P/I-P65UP5/C-P6ND motherboard correct? I checked the database and they DO NOT do this on either the P54NP4 or P55P2T4D (both EISA/PCI). I'm going back to re-read the spec to see if I can find this variation. If its legal I'll redo the code to make it work. If it's bogus I'll have to add some sort of "rogue hardware" patch that is enabled with a kernel config option. Opinions??? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Tue Nov 19 13:05:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05871 for smp-outgoing; Tue, 19 Nov 1996 13:05:17 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA05861 for ; Tue, 19 Nov 1996 13:05:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA19927; Tue, 19 Nov 1996 14:04:52 -0700 Message-Id: <199611192104.OAA19927@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "J.M. Chuang" Cc: smp@freebsd.org Subject: Re: Tyan Tomcat III (S1563D) In-reply-to: Your message of "Mon, 18 Nov 1996 09:37:31 -0400." <199611181337.JAA15924@bluenose.na.tuns.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 14:04:52 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I think we have a new class of "not connected" INTs for the IO APIC. Jim Chuang was testing the APIC_IO option to the SMP kernel (thanx Jim), and found the following problem: --- > Jim wrote: >>> >wd0: interrupt timeout: >>> >wd0: status 58 erro 0 >>> ... --- > I (smp) replied: >I guess I need to look at the chipsets to see how the IDE INTs are routed. >Since these are on a motherboard chipset, they might now get "off the chip" >and thus are not available to route to the APIC chip. This is a common >problem with EISA chipsets and the system timer, as both timer and 8259 ICUs >are on the same chip, and they didn't think there would ever be a need >to bring the line off the chip. > >-- >thanx for replying, I will get back to you when I have thought it over >a bit... --- so I looked at the chipset, specifically the 82371SB (aka PIIX3) and am currently of the opinion that the chip directly routes interrupts from the IDE controller core to INTs 14/15 on the 8259 core. The datasheet lists INTs 14/15 as INPUTS ONLY, and I cannot find any other pin on the chip that would bring IDE INTs off-chip. If I am correct this means that the IO APIC (which is on a separate piece of silicon) cannot service IDE INTs with this hardware. This chip is used in both the Natoma and Triton-II (Triton-I?) chip sets. Whether this affects other sets like Neptune is unknown to me at this point, but I would guess it does. The implication of this is that we will probably never support IDE drives in the SMP kernel with APIC_IO mode enabled on these chipsets. "mixed-mode" programming might be possible, but IMHO, would BLOW CHUNKS! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Tue Nov 19 14:47:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12253 for smp-outgoing; Tue, 19 Nov 1996 14:47:20 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA12245 for ; Tue, 19 Nov 1996 14:47:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA20421 for ; Tue, 19 Nov 1996 15:47:09 -0700 Message-Id: <199611192247.PAA20421@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: smp@freebsd.org Subject: Re: Can test again... In-reply-to: Your message of "Tue, 19 Nov 1996 13:55:50 MST." <199611192055.NAA19886@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 15:47:09 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > INT active-lo level 1 9 2 17 > ^ ^ ^^ > ... >Is there anything in the BIOS that looks like it might affect this behavior? > ... >So, its debate time, is this MP declaration that Asus is using on >its P/I-P65UP5/C-P6ND motherboard correct? I checked the database >and they DO NOT do this on either the P54NP4 or P55P2T4D (both EISA/PCI). >I'm going back to re-read the spec to see if I can find this variation. >If its legal I'll redo the code to make it work. If it's bogus I'll >have to add some sort of "rogue hardware" patch that is enabled with >a kernel config option. Tor Egge just reported: >I found an MPS 1.4 support switch in bios, it was disabled. Changing >it to enabled caused some changes. New version of mptable -dmesg -verbose >is appended. SMP kernel with option APIC_IO now boots fine. Perhaps >this version should replace the previous version in the mptable output >database. > ... > INT active-lo level 0 11:A 2 17 > INT active-lo level 0 12:A 2 16 --- So I guess its a moot point for now. I did check out the MP spec, ver1.1, and it does have section D.3 (I/O Interrupt Assignment Entries for PCI Devices) It appears identical to the D.3 section of ver1.4, so this doesn't explain why Asus did it this way. Perhaps ver1.1 was originally published without appendix D? Oh well, on to other problems.... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Nov 19 14:54:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12689 for smp-outgoing; Tue, 19 Nov 1996 14:54:23 -0800 (PST) Received: from pat.idt.unit.no (pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA12672 for ; Tue, 19 Nov 1996 14:54:16 -0800 (PST) Received: from idt.unit.no (ikke.idt.unit.no [129.241.111.65]) by pat.idt.unit.no (8.7.5/8.7.3) with ESMTP id XAA24080; Tue, 19 Nov 1996 23:53:58 +0100 (MET) Message-Id: <199611192253.XAA24080@pat.idt.unit.no> To: smp@csn.net Cc: smp@freebsd.org Subject: Re: Can test again... In-Reply-To: Your message of "Tue, 19 Nov 1996 13:55:50 -0700" References: <199611192055.NAA19886@clem.systemsix.com> X-Mailer: Mew version 1.06 on Emacs 19.33.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 19 Nov 1996 23:53:58 +0100 From: Tor Egge Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >- Interrupts are lost. e.g. rtc stopped generating interrupts due > > to a lost interrupt. > > I wouldn't expect this on a NON APIC_IO kernel, but who knows??? It also happens under some circumstances in the normal -current branch :-( [ discussion about problems wrt. SMP-kernel with option APIC_IO not booting deleted ] > Is there anything in the BIOS that looks like it might affect this behavior? Yes. The MPS 1.4 enable switch in the BIOS was disabled. Enabling it helped, and I'm currently running the SMP kernel with option APIC_IO as I write this. As expected, not having APIC_LAZY defined immediately caused lost interrupts when a new interrupt arrives before the interrupt is reenabled. - Tor Egge From owner-freebsd-smp Tue Nov 19 15:11:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA14017 for smp-outgoing; Tue, 19 Nov 1996 15:11:31 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA14005 for ; Tue, 19 Nov 1996 15:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA20593; Tue, 19 Nov 1996 16:11:03 -0700 Message-Id: <199611192311.QAA20593@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Tor Egge cc: smp@freebsd.org Subject: Re: Can test again... In-reply-to: Your message of "Tue, 19 Nov 1996 23:53:58 +0100." <199611192253.XAA24080@pat.idt.unit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 16:11:02 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >As expected, not having APIC_LAZY defined immediately caused lost interrupts >when a new interrupt arrives before the interrupt is reenabled. for those new to this problem, the cause is "brain damage" in the design of the IO APIC. The 8259 remembers INTs that occur while masked, but the IO APIC looses them. APIC_LAZY avoids masking INTs when possible, limiting (but NOT eliminating) the problem. Scanning the mail archive will pull up past discussion of this issue. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Tue Nov 19 15:16:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA14317 for smp-outgoing; Tue, 19 Nov 1996 15:16:14 -0800 (PST) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA14307 for ; Tue, 19 Nov 1996 15:16:07 -0800 (PST) From: Barney Wolff To: freebsd-smp@freebsd.org Date: Tue, 19 Nov 1996 17:43 EST Subject: reinventing vs copying Content-Type: text/plain Message-ID: <32923fad0.15a6@databus.databus.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to understand better than I do (which is hardly at all) why it seems (to me) as though all the SMP work is being done without reference to what other SMP-capable OS's do. I do understand that code cannot be copied, certainly from the commercial systems and not even from Linux without complying with the GPL, but what prevents the borrowing of ideas or even the discussion of how common problems are handled by other, seemingly working, implementations? Is it that the information is not available, or has it been the experience that the other systems don't really solve the problems that are showing up? Or is it that a more-or-less clean-room implementation is being attempted to avoid even the suspicion of theft? Barney Wolff From owner-freebsd-smp Tue Nov 19 17:35:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA22805 for smp-outgoing; Tue, 19 Nov 1996 17:35:33 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA22773 for ; Tue, 19 Nov 1996 17:35:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id SAA21266; Tue, 19 Nov 1996 18:35:06 -0700 Message-Id: <199611200135.SAA21266@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Barney Wolff cc: freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Tue, 19 Nov 1996 17:43:00 EST." <32923fad0.15a6@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 18:35:06 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I'd like to understand better than I do (which is hardly at all) why it > seems (to me) as though all the SMP work is being done without reference > to what other SMP-capable OS's do. good question. --- > I do understand that code cannot be copied, certainly from the > commercial systems and not even from Linux without complying with the > GPL, but what prevents the borrowing of ideas or even the discussion > of how common problems are handled by other, seemingly working, > implementations? nothing, we sometimes do. In some cases the internals of the systems differ so greatly that what works for one won't for the other. For example, Terry posted a rather detailed discussion of another OS's method for handling INTs, and how it would resolve the "missing INT" problem of the IO APIC. But the methods used are so far from the FreeBSD kernel as to be unusable for us. More than anything it is just that we don't run in those circles. --- > Is it that the information is not available, or has it > been the experience that the other systems don't really solve the > problems that are showing up? I don't have access to info about systems like NT or Solaris. I've done a little looking at Linux code in the past. I suppose I should grab a complete Linux SMP kernel, anyone know what the definative version would be? --- > Or is it that a more-or-less clean-room > implementation is being attempted to avoid even the suspicion of theft? that certainly ain't it! --- I personally am doing this work for both fun and to increase my knowledge in areas that are important to my career. I find that "inventing" solutions fills both those needs. When someone starts paying me to do this I might worry about being more "efficient". I'm not suggesting that people shouldn't bring in ideas from other OS's when appropriate, its just not my first approach to solving problems in this context. Another important thing to realize is that this project is more or less run by anarchy! If you see a better way of getting things done SPEAK UP. We need testers. We need coders. We need researchers. We need to get more people involved if this project is going to go anywhere!!! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Nov 19 18:08:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA24178 for smp-outgoing; Tue, 19 Nov 1996 18:08:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA24173 for ; Tue, 19 Nov 1996 18:08:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA10139; Tue, 19 Nov 1996 18:55:46 -0700 From: Terry Lambert Message-Id: <199611200155.SAA10139@phaeton.artisoft.com> Subject: Re: reinventing vs copying To: smp@csn.net (Steve Passe) Date: Tue, 19 Nov 1996 18:55:45 -0700 (MST) Cc: barney@databus.com, freebsd-smp@freebsd.org In-Reply-To: <199611200135.SAA21266@clem.systemsix.com> from "Steve Passe" at Nov 19, 96 06:35:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'd like to understand better than I do (which is hardly at all) why it > > seems (to me) as though all the SMP work is being done without reference > > to what other SMP-capable OS's do. > > good question. > > --- > > I do understand that code cannot be copied, certainly from the > > commercial systems and not even from Linux without complying with the > > GPL, but what prevents the borrowing of ideas or even the discussion > > of how common problems are handled by other, seemingly working, > > implementations? > > nothing, we sometimes do. In some cases the internals of the systems > differ so greatly that what works for one won't for the other. For example, > Terry posted a rather detailed discussion of another OS's method for handling > INTs, and how it would resolve the "missing INT" problem of the IO APIC. > But the methods used are so far from the FreeBSD kernel as to be unusable > for us. More than anything it is just that we don't run in those circles. My take on this is that no one is working at the level of detail where the answer to the question matters. Mostly, the work so far falls into mapping abstractions onto the hardware for the highest possible concurrency at the lowest possible level. So far, I don't believe anyone is building scheduler changes, for instance... there are a number of research papers in scheduling ATM packets onto "leaky bucket" transports that are applicable... for instance, there is at least one nice fuzzy logic system for scheduling that would probably translate well. Good Masters thesis or PhD dissertation material. 8-). Other than me (and I'm a fanatic), I don't think anoyone else is looking at methods of increasing concurrency, at least not in any detail, in the kernel itself. Mostly, the soloutions to those problems are in the "UNIX For Modern Architectures" and the "UNIX Internals: The New Frontiers" books. Topologically, the problem is the same for RT scheduling (kernel preemption), kernel threading (kernel preemption), and processor scheduling (Processor affinity). Many people find that uninteresting... When it comes time to worry about those things, they will be worried about... pour a level foundation, and *after* that, you can build a level house. 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 Tue Nov 19 20:09:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01265 for smp-outgoing; Tue, 19 Nov 1996 20:09:13 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01253 for freebsd-smp; Tue, 19 Nov 1996 20:09:10 -0800 (PST) Date: Tue, 19 Nov 1996 20:09:10 -0800 (PST) From: Steve Passe Message-Id: <199611200409.UAA01253@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/19 20:09:09 Modified: i386/isa vector.s Log: fixed bug in APIC_IO+APIC_LAZY where system hangs. caused by missing REL_MPLOCK Submitted by: Tor Egge Revision Changes Path 1.21 +2 -1 sys/i386/isa/vector.s From owner-freebsd-smp Tue Nov 19 20:21:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01951 for smp-outgoing; Tue, 19 Nov 1996 20:21:45 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA01939 for ; Tue, 19 Nov 1996 20:21:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA22173; Tue, 19 Nov 1996 21:21:30 -0700 Message-Id: <199611200421.VAA22173@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: smp@FreeBSD.org cc: Tor Egge Subject: Re: Can test again... In-reply-to: Your message of "Tue, 19 Nov 1996 16:11:02 MST." <199611192311.QAA20593@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 21:21:30 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Tor Egge has just submitted a patch to vector.s that appears to fix the system lock-ups introduced by APIC_LAZY. I have commited it to freefall and it is ready for download via cvsup. If you have had trouble with APIC_IO + APIC_LAZY I suggest you try this to see if it helps. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Nov 19 20:21:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01960 for smp-outgoing; Tue, 19 Nov 1996 20:21:49 -0800 (PST) Received: from trapdoor.aracnet.com (trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA01942 for ; Tue, 19 Nov 1996 20:21:41 -0800 (PST) Received: from cbrowni2-home (pool-001-010.i-Connect.Net [206.139.73.41]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id UAA31645; Tue, 19 Nov 1996 20:21:09 -0800 Message-ID: <32928613.59D1@aracnet.com> Date: Tue, 19 Nov 1996 20:16:19 -0800 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.01 (WinNT; U) MIME-Version: 1.0 To: Steve Passe CC: Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying References: <199611200135.SAA21266@clem.systemsix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > nothing, we sometimes do. In some cases the internals of the systems > differ so greatly that what works for one won't for the other. For example, > Terry posted a rather detailed discussion of another OS's method for handling > INTs, and how it would resolve the "missing INT" problem of the IO APIC. > But the methods used are so far from the FreeBSD kernel as to be unusable > for us. More than anything it is just that we don't run in those circles. Are you guys still working on the "missing INT" problem? Anyone have a quick 2 line summary of the problem? > > Is it that the information is not available, or has it > > been the experience that the other systems don't really solve the > > problems that are showing up? > > I don't have access to info about systems like NT or Solaris. > I've done a little looking at Linux code in the past. I suppose I > should grab a complete Linux SMP kernel, anyone know what the definative > version would be? Yes. SMP support for Linux is now in the standard distribution and source tree. Any of the 2.0 versions of Linux will have the SMP source. I am running the SMP version of Linux on some of my systems. If you would like me to try some things or send you some info, let me know. > Another important thing to realize is that this project is more or less run by > anarchy! If you see a better way of getting things done SPEAK UP. > We need testers. We need coders. We need researchers. We need to get > more people involved if this project is going to go anywhere!!! Steve, one recommendation. Could you or someone provide some basic level details of how to get SMP running on FreeBSD. In addition could you explain how to use the CVT to get source update and such. This might help people like me that are new to this kinda stuff but might like to help out. I think you gave me an URL one time, so if all the information is explain well there, please ignore this. Chris From owner-freebsd-smp Tue Nov 19 20:59:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03521 for smp-outgoing; Tue, 19 Nov 1996 20:59:57 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA03479 for ; Tue, 19 Nov 1996 20:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA22372; Tue, 19 Nov 1996 21:59:05 -0700 Message-Id: <199611200459.VAA22372@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: cbrown@aracnet.com cc: Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Tue, 19 Nov 1996 20:16:19 PST." <32928613.59D1@aracnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 21:59:04 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >Are you guys still working on the "missing INT" problem? Anyone have a >quick >2 line summary of the problem? perfect timing. I just commited a fix for the fix. Tor Egge discovered a missing REL_MPLOCK in the patch that I merged from code submitted by Bruce Evans to deal with the original problem (missing REL_MPLOCK, this was entirely my fault). Summary: The 8259 ICU latches an INT that occurs while that INT is masked. The IO APIC looses any INT occuring while that INT is masked. Intel calls this a "design consideration", I call it "brain damage". The current kernel ISR code masks the INT it is servicing, calls the hardware specific code, then unmasks it upon return and cleans up. If an INT occurs between the time the hardware specific code clears its INT latch (or last checks its register, this is a hardware specific detail), and the point in the generic code where the INT is unmasked, the INT will be lost by the IO APIC. Bruce Evan's code avoids masking INTs unless the kernel is already servicing the same INT. This greatly diminishes the occurance of lost INTs. The patch just sent by Tor Egge appears to make using Bruce's patch reasonable now. Before this it used to hang fairly frequently. Note that it has had VERY little testing so I may be putting my foot in my mouth, but it feels good (the patch, NOT the 'foot in my mouth' thing)! --- >Steve, one recommendation. Could you or someone provide some basic >level details of how >to get SMP running on FreeBSD. In addition could you explain how to use >the CVT >to get source update and such. This might help people like me that are >new to this >kinda stuff but might like to help out. start with: http://www.freebsd.org/~fsmp/SMP/SMP.html the "getting started" section is a little cryptic, so take notes and let me know what isn't clear. In particular there are many different ways to manage the SMP "/usr/src/sys" tree in parallel to the -current "/usr/src/sys" My example only shows one. I don't even use that method any more. Now I keep the SMP tree on /d1usr/src/sys, and link '/sys' to /d1usr/src/sys. remember to restore this link whenever making anything outside of the SMP kernel! info on cvsup can be found by searching the announce mail archive for "cvsup", as well as a little info at the top of "getting started". Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Tue Nov 19 21:27:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04831 for smp-outgoing; Tue, 19 Nov 1996 21:27:16 -0800 (PST) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA04818 for ; Tue, 19 Nov 1996 21:27:08 -0800 (PST) From: Barney Wolff To: freebsd-smp@freebsd.org Date: Wed, 20 Nov 1996 00:17 EST Subject: Re: 8259 vs APIC Content-Type: text/plain Message-ID: <329296a60.1bae@databus.databus.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Steve Passe > Date: Tue, 19 Nov 1996 21:59:04 -0700 > > The 8259 ICU latches an INT that occurs while that INT is masked. > The IO APIC looses any INT occuring while that INT is masked. > Intel calls this a "design consideration", I call it "brain damage". If you'll pardon the naive opinion, it sounds to me as tho the 8259 is expecting to handle edge-triggered interrupts (as we know to be true, right?) but the APIC is really expecting level-triggered ints, where the int will still be there when it's finally unmasked. If that's true, I would be looking at a solution that kept the edge- triggered ints on the 8259, as nothing will save you otherwise. So what if you cut the rate of lost ints to one a week - that's utterly unacceptable for a production machine. I seem to recall that the APIC can be set for either edge or level, or am I just fantasizing again? Anyway, thanks for helping me understand the project better! Barney Wolff From owner-freebsd-smp Tue Nov 19 21:43:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA05733 for smp-outgoing; Tue, 19 Nov 1996 21:43:36 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA05726; Tue, 19 Nov 1996 21:43:25 -0800 (PST) Message-Id: <199611200543.VAA05726@freefall.freebsd.org> To: Steve Passe cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Tue, 19 Nov 1996 21:59:04 MST." <199611200459.VAA22372@clem.systemsix.com> Date: Tue, 19 Nov 1996 21:43:24 -0800 From: "Justin T. Gibbs" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Bruce Evan's code avoids masking INTs unless the >kernel is already servicing the same INT. This greatly diminishes the >occurance of lost INTs. Can't you completely eliminate lost INTs with the following algorithm? while in ISR { if interrupt happens { mask interrupt set flag to call ISR again } } unmask interrupt if masked. call ISR if flag is set. >Steve Passe | powered by >smp@csn.net | FreeBSD -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Tue Nov 19 22:16:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA07358 for smp-outgoing; Tue, 19 Nov 1996 22:16:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA07343 for ; Tue, 19 Nov 1996 22:16:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA22765; Tue, 19 Nov 1996 23:15:57 -0700 Message-Id: <199611200615.XAA22765@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Barney Wolff cc: freebsd-smp@freebsd.org Subject: Re: 8259 vs APIC In-reply-to: Your message of "Wed, 20 Nov 1996 00:17:00 EST." <329296a60.1bae@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 23:15:56 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > If you'll pardon the naive opinion, it sounds to me as tho the 8259 > is expecting to handle edge-triggered interrupts (as we know to be > true, right?) but the APIC is really expecting level-triggered ints, > where the int will still be there when it's finally unmasked. it can be programmed on a pin by pin basis for either edge or level. --- > If that's true, I would be looking at a solution that kept the edge- > triggered ints on the 8259, as nothing will save you otherwise. So > what if you cut the rate of lost ints to one a week - that's utterly > unacceptable for a production machine. the "window of opportunity" can be closed with clever programming. I believe Bruce once commented that he thinks we could get away without masking edge trigger INTs entirely. Explaining why keeping the 8259s in the picture would take a small book to do properly, but the short version is that it would mean incredibly complex, inefficient code. Again, its an issue of priority vs. resources. Hopefully someone with more expertise than I in this area will step in and do "the good thing" with it. Or, sooner or later, I'll find time to tackle it. The SMP kernel runs for days without problems in its current state, so this is a low priority. The "giant locking" paradigm is the squeeky wheel right now. --- > I seem to recall that the APIC can be set for either edge or level, or > am I just fantasizing again? it can be set to either, BUT that 'either' has to be whatever the driving card is providing. In the case of ISA, thats active high/edge triggered. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Nov 19 22:26:39 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA07857 for smp-outgoing; Tue, 19 Nov 1996 22:26:39 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA07850 for ; Tue, 19 Nov 1996 22:26:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA22816; Tue, 19 Nov 1996 23:26:09 -0700 Message-Id: <199611200626.XAA22816@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "Justin T. Gibbs" cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Tue, 19 Nov 1996 21:43:24 PST." <199611200543.VAA05726@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 23:26:09 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >Bruce Evan's code avoids masking INTs unless the > >kernel is already servicing the same INT. This greatly diminishes the > >occurance of lost INTs. > > Can't you completely eliminate lost INTs with the following algorithm? > > while in ISR { > if interrupt happens { > mask interrupt > set flag to call ISR again > } > } > unmask interrupt if masked. > call ISR if flag is set. possibly, the devil is in the details. I think this is sortof what Bruce's patch does, and perhaps it even eliminates lost INTs as oppossed to "greatly diminishing" them as I earlier said. I've been going 6 different directions lately and just haven't had time to look at this issue properly... I encourage any INTerrupt experts out there to analyize vector.s/icu.s for robustness. The sections in question are those bracketed by APIC_IO and APIC_LAZY. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 20 11:29:29 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA28735 for smp-outgoing; Wed, 20 Nov 1996 11:29:29 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA28730 for ; Wed, 20 Nov 1996 11:29:27 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id NAA02836 for ; Wed, 20 Nov 1996 13:29:23 -0600 (CST) Message-Id: <199611201929.NAA02836@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-smp@freebsd.org Subject: vm_page_alloc(ZERO): missing pages... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 13:29:23 -0600 From: Chris Csanady Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm not sure exactly what this means, but I get the following messages with the current SMP kernel. This is with APIC_IO and APIC_LAZY defined.. vm_page_alloc(ZERO): missing pages on cache queue: 4 vm_page_alloc(ZERO): missing pages on cache queue: 3 vm_page_alloc(ZERO): missing pages on cache queue: 1 vm_page_alloc(NORMAL): missing pages on cache queue: 1 vm_page_alloc(ZERO): missing pages on cache queue: 4 vm_page_alloc(ZERO): missing pages on cache queue: 1 vm_page_alloc(ZERO): missing pages on cache queue: 1 --Chris Csanady From owner-freebsd-smp Wed Nov 20 12:18:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01584 for smp-outgoing; Wed, 20 Nov 1996 12:18:08 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA01579 for ; Wed, 20 Nov 1996 12:18:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA26482; Wed, 20 Nov 1996 13:17:49 -0700 Message-Id: <199611202017.NAA26482@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Chris Csanady cc: freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 13:29:23 CST." <199611201929.NAA02836@friley216.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 13:17:49 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I'm not sure exactly what this means, but I get the following messages with > the current SMP kernel. This is with APIC_IO and APIC_LAZY defined.. > > vm_page_alloc(ZERO): missing pages on cache queue: 4 > vm_page_alloc(ZERO): missing pages on cache queue: 3 > vm_page_alloc(ZERO): missing pages on cache queue: 1 > vm_page_alloc(NORMAL): missing pages on cache queue: 1 > vm_page_alloc(ZERO): missing pages on cache queue: 4 > vm_page_alloc(ZERO): missing pages on cache queue: 1 > vm_page_alloc(ZERO): missing pages on cache queue: 1 I've never seen this, but have only been running APIC_LAZY since the bug fix of last nite (approx 16 hours). We are both running the same MB and disk controller: GA586DX/7880 (true?) Have you ever seen this b4, ie without APIC_LAZY defined? When does it happen, at boot, or continually? Any vm experts out there who can give a generic description of this error, or what might cause it? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 20 12:40:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA03089 for smp-outgoing; Wed, 20 Nov 1996 12:40:58 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA03057 for ; Wed, 20 Nov 1996 12:40:51 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id EAA12623; Thu, 21 Nov 1996 04:40:27 +0800 (WST) Message-Id: <199611202040.EAA12623@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: Chris Csanady , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 13:17:49 MST." <199611202017.NAA26482@clem.systemsix.com> Date: Thu, 21 Nov 1996 04:40:24 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > > I'm not sure exactly what this means, but I get the following messages with > > the current SMP kernel. This is with APIC_IO and APIC_LAZY defined.. > > > > vm_page_alloc(ZERO): missing pages on cache queue: 4 > > vm_page_alloc(ZERO): missing pages on cache queue: 3 > > vm_page_alloc(ZERO): missing pages on cache queue: 1 > > vm_page_alloc(NORMAL): missing pages on cache queue: 1 [..] > Any vm experts out there who can give a generic description of this error, > or what might cause it? Also, how much paging is taking place? We are not propagating TLB flushes to all cpu's yet (needs APIC IPI's to work). Cheers, -Peter From owner-freebsd-smp Wed Nov 20 12:49:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04737 for smp-outgoing; Wed, 20 Nov 1996 12:49:22 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04731 for smp; Wed, 20 Nov 1996 12:49:19 -0800 (PST) Date: Wed, 20 Nov 1996 12:49:19 -0800 (PST) From: Peter Wemm Message-Id: <199611202049.MAA04731@freefall.freebsd.org> To: smp Subject: Beware, -current resync in progress Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi all, beware, I'm currently in the middle of merging in the latest -current into the smp code. This is turning out to be really difficult this time due to the much larger impact that Steve's work has had on the code base. Do not expect it to compile until you hear otherwise.. It'll take a few hours at least. -Peter From owner-freebsd-smp Wed Nov 20 12:49:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04747 for smp-outgoing; Wed, 20 Nov 1996 12:49:30 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA04741 for ; Wed, 20 Nov 1996 12:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA26662; Wed, 20 Nov 1996 13:49:05 -0700 Message-Id: <199611202049.NAA26662@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: Chris Csanady , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Thu, 21 Nov 1996 04:40:24 +0800." <199611202040.EAA12623@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 13:49:05 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Steve Passe wrote: > > Hi, > > > > > I'm not sure exactly what this means, but I get the following messages with > > > the current SMP kernel. This is with APIC_IO and APIC_LAZY defined.. > > > > > > vm_page_alloc(ZERO): missing pages on cache queue: 4 > > > vm_page_alloc(ZERO): missing pages on cache queue: 3 > > > vm_page_alloc(ZERO): missing pages on cache queue: 1 > > > vm_page_alloc(NORMAL): missing pages on cache queue: 1 > [..] > > Any vm experts out there who can give a generic description of this error, > > or what might cause it? > > Also, how much paging is taking place? Chris's dmesg show 32MB of memory, in the range we know causes trouble. --- > We are not propagating TLB flushes > to all cpu's yet (needs APIC IPI's to work). I thought that I had them working, i386/include/mpapic.h, i386/i386/mpapic.c: int apicIPI(); int selectedProcsIPI(); int allProcsIPI(); int allButSelfIPI(); int selfIPI(); If these aren't adequate and/or usable let me know and I'll get you what you need ASAP! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 20 12:50:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05166 for smp-outgoing; Wed, 20 Nov 1996 12:50:27 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA05114 for ; Wed, 20 Nov 1996 12:50:21 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id OAA02373; Wed, 20 Nov 1996 14:50:05 -0600 (CST) Message-Id: <199611202050.OAA02373@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Peter Wemm cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of Thu, 21 Nov 1996 04:40:24 +0800. <199611202040.EAA12623@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 14:50:04 -0600 From: Chris Csanady Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Steve Passe wrote: >> Hi, >> >> > I'm not sure exactly what this means, but I get the following messages wit h >> > the current SMP kernel. This is with APIC_IO and APIC_LAZY defined.. >> > >> > vm_page_alloc(ZERO): missing pages on cache queue: 4 >> > vm_page_alloc(ZERO): missing pages on cache queue: 3 >> > vm_page_alloc(ZERO): missing pages on cache queue: 1 >> > vm_page_alloc(NORMAL): missing pages on cache queue: 1 >[..] >> Any vm experts out there who can give a generic description of this error, >> or what might cause it? > >Also, how much paging is taking place? We are not propagating TLB flushes >to all cpu's yet (needs APIC IPI's to work). A great deal of paging. I was running a benchmark (hint) which beats on the memory quite hard. VM as well. Besides being a wonderful benchmark, I also use it every now and then to try to break things. :) Are the lacking TLB flushes very harmful? How hard would this be to implement? Chris > >Cheers, >-Peter > > From owner-freebsd-smp Wed Nov 20 12:58:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09273 for smp-outgoing; Wed, 20 Nov 1996 12:58:52 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA09234 for ; Wed, 20 Nov 1996 12:58:48 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id EAA12835; Thu, 21 Nov 1996 04:58:25 +0800 (WST) Message-Id: <199611202058.EAA12835@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Chris Csanady cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 14:50:04 CST." <199611202050.OAA02373@friley216.res.iastate.edu> Date: Thu, 21 Nov 1996 04:58:24 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > >Also, how much paging is taking place? We are not propagating TLB flushes > >to all cpu's yet (needs APIC IPI's to work). > > A great deal of paging. I was running a benchmark (hint) which beats on the > memory quite hard. VM as well. Besides being a wonderful benchmark, I also > use it every now and then to try to break things. :) Err, well, in this case, I'd suggest the following saying is appropriate: Patient: "Doctor! Doctor! It hurts when I do this.." Doctor: "Well, don't do it then.." > Are the lacking TLB flushes very harmful? How hard would this be to > implement? Yes, and potentially rather nasty. :-( Here's why: CPU 1: Running in user mode CPU 2: enters kernel, frees up pages that belong to the process that CPU 1 is running, reassigns them elsewhere, flushes it's TLB and uses the new mappings. CPU 1: blissfully unaware while the TLB cache holds.. Continues to use the page that it thinks it owns, but might now be being used to write an inode or something... There is a race between the page mappings being changed and the next TLB flush on the other cpus. This window opens up much wider when there is paging, or page stealing going on. > Chris Cheers, -Peter From owner-freebsd-smp Wed Nov 20 12:59:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09598 for smp-outgoing; Wed, 20 Nov 1996 12:59:32 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09585 for freebsd-smp; Wed, 20 Nov 1996 12:59:30 -0800 (PST) Date: Wed, 20 Nov 1996 12:59:30 -0800 (PST) From: Peter Wemm Message-Id: <199611202059.MAA09585@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys - Imported sources Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 12:59:29 sys - Imported sources Update of /home/smp/sys In directory freefall.freebsd.org:/f/peter/work/sys Revision/Branch: 1.1.1 Log Message: Import -current 961120 Status: Vendor Tag: CURRENT Release Tags: v961120 I sys/CVS U sys/Makefile I sys/compile/CVS U sys/compile/.keep_me I sys/netkey/CVS U sys/netkey/key.c U sys/netkey/key.h U sys/netkey/key_debug.c U sys/netkey/key_debug.h I sys/conf/CVS U sys/conf/defines U sys/conf/files U sys/conf/files.newconf U sys/conf/newvers.sh U sys/conf/nfsswapkernel.c U sys/conf/options U sys/conf/param.c U sys/conf/systags.sh I sys/ddb/CVS U sys/ddb/db_access.c U sys/ddb/db_access.h U sys/ddb/db_aout.c U sys/ddb/db_break.c U sys/ddb/db_break.h U sys/ddb/db_command.c U sys/ddb/db_command.h U sys/ddb/db_examine.c U sys/ddb/db_expr.c U sys/ddb/db_input.c U sys/ddb/db_lex.c U sys/ddb/db_lex.h U sys/ddb/db_output.c U sys/ddb/db_output.h U sys/ddb/db_print.c U sys/ddb/db_ps.c U sys/ddb/db_run.c U sys/ddb/db_sym.c U sys/ddb/db_sym.h U sys/ddb/db_trap.c U sys/ddb/db_variables.c U sys/ddb/db_variables.h U sys/ddb/db_watch.c U sys/ddb/db_watch.h U sys/ddb/db_write_cmd.c U sys/ddb/ddb.h I sys/dev/CVS I sys/dev/aic7xxx/CVS U sys/dev/aic7xxx/aic7xxx.seq U sys/dev/aic7xxx/aic7xxx_asm.1 U sys/dev/aic7xxx/aic7xxx_asm.c U sys/dev/aic7xxx/aic7xxx_reg.h I sys/dev/vn/CVS U sys/dev/vn/vn.c I sys/dev/ccd/CVS U sys/dev/ccd/ccd.c I sys/dev/advansys/CVS N sys/dev/advansys/advlib.c N sys/dev/advansys/advlib.h N sys/dev/advansys/advmcode.c N sys/dev/advansys/advmcode.h I sys/dev/vx/CVS N sys/dev/vx/if_vx.c N sys/dev/vx/if_vxreg.h I sys/gnu/CVS I sys/gnu/ext2fs/CVS U sys/gnu/ext2fs/COPYRIGHT.INFO U sys/gnu/ext2fs/ext2_alloc.c U sys/gnu/ext2fs/ext2_balloc.c U sys/gnu/ext2fs/ext2_extern.h U sys/gnu/ext2fs/ext2_fs.h U sys/gnu/ext2fs/ext2_fs_i.h U sys/gnu/ext2fs/ext2_fs_sb.h U sys/gnu/ext2fs/ext2_inode.c U sys/gnu/ext2fs/ext2_inode_cnv.c U sys/gnu/ext2fs/ext2_linux_balloc.c U sys/gnu/ext2fs/ext2_linux_ialloc.c U sys/gnu/ext2fs/ext2_lookup.c U sys/gnu/ext2fs/ext2_readwrite.c U sys/gnu/ext2fs/ext2_subr.c U sys/gnu/ext2fs/ext2_vfsops.c U sys/gnu/ext2fs/ext2_vnops.c U sys/gnu/ext2fs/fs.h U sys/gnu/ext2fs/i386-bitops.h I sys/gnu/i386/CVS I sys/gnu/i386/fpemul/CVS U sys/gnu/i386/fpemul/Changelog U sys/gnu/i386/fpemul/README U sys/gnu/i386/fpemul/control_w.h U sys/gnu/i386/fpemul/div_small.s U sys/gnu/i386/fpemul/errors.c U sys/gnu/i386/fpemul/exception.h U sys/gnu/i386/fpemul/fpu_arith.c U sys/gnu/i386/fpemul/fpu_asm.h U sys/gnu/i386/fpemul/fpu_aux.c U sys/gnu/i386/fpemul/fpu_emu.h U sys/gnu/i386/fpemul/fpu_entry.c U sys/gnu/i386/fpemul/fpu_etc.c U sys/gnu/i386/fpemul/fpu_proto.h U sys/gnu/i386/fpemul/fpu_system.h U sys/gnu/i386/fpemul/fpu_trig.c U sys/gnu/i386/fpemul/get_address.c U sys/gnu/i386/fpemul/load_store.c U sys/gnu/i386/fpemul/math_emu.h U sys/gnu/i386/fpemul/poly_2xm1.c U sys/gnu/i386/fpemul/poly_atan.c U sys/gnu/i386/fpemul/poly_div.s U sys/gnu/i386/fpemul/poly_l2.c U sys/gnu/i386/fpemul/poly_mul64.s U sys/gnu/i386/fpemul/poly_sin.c U sys/gnu/i386/fpemul/poly_tan.c U sys/gnu/i386/fpemul/polynomial.s U sys/gnu/i386/fpemul/reg_add_sub.c U sys/gnu/i386/fpemul/reg_compare.c U sys/gnu/i386/fpemul/reg_constant.c U sys/gnu/i386/fpemul/reg_constant.h U sys/gnu/i386/fpemul/reg_div.s U sys/gnu/i386/fpemul/reg_ld_str.c U sys/gnu/i386/fpemul/reg_mul.c U sys/gnu/i386/fpemul/reg_norm.s U sys/gnu/i386/fpemul/reg_round.s U sys/gnu/i386/fpemul/reg_u_add.s U sys/gnu/i386/fpemul/reg_u_div.s U sys/gnu/i386/fpemul/reg_u_mul.s U sys/gnu/i386/fpemul/reg_u_sub.s U sys/gnu/i386/fpemul/status_w.h U sys/gnu/i386/fpemul/version.h U sys/gnu/i386/fpemul/wm_shrx.s U sys/gnu/i386/fpemul/wm_sqrt.s I sys/gnu/i386/isa/CVS U sys/gnu/i386/isa/dgb.c U sys/gnu/i386/isa/dgbios.h U sys/gnu/i386/isa/dgfep.h U sys/gnu/i386/isa/dgreg.h I sys/i386/CVS U sys/i386/Makefile I sys/i386/apm/CVS U sys/i386/apm/apm.c U sys/i386/apm/apm_setup.h U sys/i386/apm/apm_setup.s I sys/i386/apm/apm_init/CVS U sys/i386/apm/apm_init/Makefile U sys/i386/apm/apm_init/apm_init.S U sys/i386/apm/apm_init/apm_init.inc U sys/i386/apm/apm_init/bin2asm.c U sys/i386/apm/apm_init/real_prot.S U sys/i386/apm/apm_init/real_prot.h U sys/i386/apm/apm_init/rmaouthdr U sys/i386/apm/apm_init/table.c I sys/i386/boot/CVS U sys/i386/boot/Makefile I sys/i386/boot/biosboot/CVS U sys/i386/boot/biosboot/Makefile U sys/i386/boot/biosboot/README.386BSD U sys/i386/boot/biosboot/README.MACH U sys/i386/boot/biosboot/README.serial U sys/i386/boot/biosboot/asm.S U sys/i386/boot/biosboot/asm.h U sys/i386/boot/biosboot/bios.S U sys/i386/boot/biosboot/boot.c U sys/i386/boot/biosboot/boot.h U sys/i386/boot/biosboot/boot2.S U sys/i386/boot/biosboot/disk.c U sys/i386/boot/biosboot/io.c U sys/i386/boot/biosboot/probe_keyboard.c U sys/i386/boot/biosboot/serial.S U sys/i386/boot/biosboot/start.S U sys/i386/boot/biosboot/sys.c U sys/i386/boot/biosboot/table.c I sys/i386/boot/rawboot/CVS U sys/i386/boot/rawboot/Makefile U sys/i386/boot/rawboot/README I sys/i386/boot/dosboot/CVS U sys/i386/boot/dosboot/Makefile U sys/i386/boot/dosboot/ansi.h U sys/i386/boot/dosboot/boot.c U sys/i386/boot/dosboot/boot.h U sys/i386/boot/dosboot/bootinfo.h U sys/i386/boot/dosboot/cdefs.h U sys/i386/boot/dosboot/dinode.h U sys/i386/boot/dosboot/dir.h U sys/i386/boot/dosboot/dirent.h U sys/i386/boot/dosboot/disk.c U sys/i386/boot/dosboot/disklabe.h U sys/i386/boot/dosboot/dkbad.h U sys/i386/boot/dosboot/dosboot.c U sys/i386/boot/dosboot/dosboot.h U sys/i386/boot/dosboot/endian.h U sys/i386/boot/dosboot/exec.h U sys/i386/boot/dosboot/fbsdboot.c U sys/i386/boot/dosboot/fbsdboot.exe.uu U sys/i386/boot/dosboot/fbsdboot.mak U sys/i386/boot/dosboot/fs.h U sys/i386/boot/dosboot/imgact.h U sys/i386/boot/dosboot/inode.h U sys/i386/boot/dosboot/mexec.h U sys/i386/boot/dosboot/param.h U sys/i386/boot/dosboot/quota.h U sys/i386/boot/dosboot/protmod.c U sys/i386/boot/dosboot/protmod.h U sys/i386/boot/dosboot/readme U sys/i386/boot/dosboot/reboot.h U sys/i386/boot/dosboot/sys.c U sys/i386/boot/dosboot/syslimit.h U sys/i386/boot/dosboot/sysparam.h U sys/i386/boot/dosboot/types.h I sys/i386/boot/kzipboot/CVS U sys/i386/boot/kzipboot/Makefile U sys/i386/boot/kzipboot/README U sys/i386/boot/kzipboot/boot.c U sys/i386/boot/kzipboot/gzip.h U sys/i386/boot/kzipboot/head.S U sys/i386/boot/kzipboot/malloc.c U sys/i386/boot/kzipboot/misc.c U sys/i386/boot/kzipboot/tail.S U sys/i386/boot/kzipboot/unzip.c I sys/i386/boot/netboot/CVS U sys/i386/boot/netboot/3c509.c U sys/i386/boot/netboot/3c509.h U sys/i386/boot/netboot/Makefile U sys/i386/boot/netboot/bootmenu.c U sys/i386/boot/netboot/main.c U sys/i386/boot/netboot/makerom.c U sys/i386/boot/netboot/misc.c U sys/i386/boot/netboot/netboot.h U sys/i386/boot/netboot/ns8390.c U sys/i386/boot/netboot/ns8390.h U sys/i386/boot/netboot/rpc.c U sys/i386/boot/netboot/start2.S I sys/i386/conf/CVS U sys/i386/conf/GENERIC U sys/i386/conf/LINT U sys/i386/conf/Makefile.i386 U sys/i386/conf/devices.i386 C sys/i386/conf/files.i386 U sys/i386/conf/majors.i386 C sys/i386/conf/options.i386 I sys/i386/eisa/CVS U sys/i386/eisa/3c5x9.c U sys/i386/eisa/aha1742.c U sys/i386/eisa/aic7770.c U sys/i386/eisa/bt74x.c U sys/i386/eisa/eisaconf.c U sys/i386/eisa/eisaconf.h N sys/i386/eisa/if_vx_eisa.c I sys/i386/i386/CVS U sys/i386/i386/autoconf.c U sys/i386/i386/cons.c U sys/i386/i386/cons.h U sys/i386/i386/db_disasm.c U sys/i386/i386/db_interface.c U sys/i386/i386/db_trace.c U sys/i386/i386/exception.s C sys/i386/i386/genassym.c U sys/i386/i386/in_cksum.c C sys/i386/i386/locore.s C sys/i386/i386/machdep.c U sys/i386/i386/math_emu.h U sys/i386/i386/math_emulate.c U sys/i386/i386/mem.c C sys/i386/i386/microtime.s U sys/i386/i386/perfmon.c C sys/i386/i386/pmap.c U sys/i386/i386/procfs_machdep.c C sys/i386/i386/support.s U sys/i386/i386/swapgeneric.c C sys/i386/i386/swtch.s U sys/i386/i386/symbols.raw U sys/i386/i386/trap.c U sys/i386/i386/sys_machdep.c U sys/i386/i386/userconfig.c U sys/i386/i386/vm_machdep.c C sys/i386/i386/identcpu.c U sys/i386/i386/i386-gdbstub.c I sys/i386/ibcs2/CVS U sys/i386/ibcs2/coff.h U sys/i386/ibcs2/ibcs2_dirent.h U sys/i386/ibcs2/ibcs2_errno.c U sys/i386/ibcs2/ibcs2_errno.h U sys/i386/ibcs2/ibcs2_fcntl.c U sys/i386/ibcs2/ibcs2_fcntl.h U sys/i386/ibcs2/ibcs2_ioctl.c U sys/i386/ibcs2/ibcs2_ioctl.h U sys/i386/ibcs2/ibcs2_ipc.c U sys/i386/ibcs2/ibcs2_ipc.h U sys/i386/ibcs2/ibcs2_isc.c U sys/i386/ibcs2/ibcs2_isc_syscall.h U sys/i386/ibcs2/ibcs2_isc_sysent.c U sys/i386/ibcs2/ibcs2_misc.c U sys/i386/ibcs2/ibcs2_mount.h U sys/i386/ibcs2/ibcs2_msg.c U sys/i386/ibcs2/ibcs2_other.c U sys/i386/ibcs2/ibcs2_poll.h U sys/i386/ibcs2/ibcs2_proto.h U sys/i386/ibcs2/ibcs2_signal.c U sys/i386/ibcs2/ibcs2_signal.h U sys/i386/ibcs2/ibcs2_socksys.c U sys/i386/ibcs2/ibcs2_socksys.h U sys/i386/ibcs2/ibcs2_stat.c U sys/i386/ibcs2/ibcs2_stat.h U sys/i386/ibcs2/ibcs2_statfs.h U sys/i386/ibcs2/ibcs2_stropts.h U sys/i386/ibcs2/ibcs2_syscall.h U sys/i386/ibcs2/ibcs2_sysent.c U sys/i386/ibcs2/ibcs2_sysi86.c U sys/i386/ibcs2/ibcs2_sysvec.c U sys/i386/ibcs2/ibcs2_termios.h U sys/i386/ibcs2/ibcs2_time.h U sys/i386/ibcs2/ibcs2_types.h U sys/i386/ibcs2/ibcs2_unistd.h U sys/i386/ibcs2/ibcs2_ustat.h U sys/i386/ibcs2/ibcs2_util.c U sys/i386/ibcs2/ibcs2_util.h U sys/i386/ibcs2/ibcs2_utime.h U sys/i386/ibcs2/ibcs2_utsname.h U sys/i386/ibcs2/ibcs2_xenix.c U sys/i386/ibcs2/ibcs2_xenix.h U sys/i386/ibcs2/ibcs2_xenix_syscall.h U sys/i386/ibcs2/ibcs2_xenix_sysent.c U sys/i386/ibcs2/imgact_coff.c U sys/i386/ibcs2/syscalls.conf U sys/i386/ibcs2/syscalls.isc U sys/i386/ibcs2/syscalls.isc.conf U sys/i386/ibcs2/syscalls.master U sys/i386/ibcs2/syscalls.xenix U sys/i386/ibcs2/syscalls.xenix.conf I sys/i386/include/CVS U sys/i386/include/apm_bios.h U sys/i386/include/apm_segments.h U sys/i386/include/asc_ioctl.h U sys/i386/include/asmacros.h U sys/i386/include/bootinfo.h C sys/i386/include/clock.h U sys/i386/include/conf.h U sys/i386/include/cons.h U sys/i386/include/console.h U sys/i386/include/cpu.h U sys/i386/include/cpufunc.h U sys/i386/include/cputypes.h U sys/i386/include/cronyx.h U sys/i386/include/db_machdep.h U sys/i386/include/gsc.h U sys/i386/include/endian.h U sys/i386/include/exec.h U sys/i386/include/float.h U sys/i386/include/floatingpoint.h U sys/i386/include/frame.h U sys/i386/include/lpt.h U sys/i386/include/ieeefp.h U sys/i386/include/ioctl_ctx.h U sys/i386/include/ioctl_fd.h U sys/i386/include/ioctl_meteor.h U sys/i386/include/ipl.h U sys/i386/include/joystick.h U sys/i386/include/pcaudioio.h U sys/i386/include/limits.h U sys/i386/include/pmap.h U sys/i386/include/md_var.h U sys/i386/include/mouse.h U sys/i386/include/mtpr.h U sys/i386/include/npx.h U sys/i386/include/param.h U sys/i386/include/perfmon.h U sys/i386/include/pcb.h U sys/i386/include/pcvt_ioctl.h U sys/i386/include/random.h U sys/i386/include/types.h U sys/i386/include/proc.h U sys/i386/include/profile.h U sys/i386/include/psl.h U sys/i386/include/qcam.h U sys/i386/include/ptrace.h U sys/i386/include/spl.h U sys/i386/include/segments.h U sys/i386/include/reg.h U sys/i386/include/reloc.h U sys/i386/include/soundcard.h U sys/i386/include/si.h U sys/i386/include/signal.h U sys/i386/include/speaker.h U sys/i386/include/spigot.h U sys/i386/include/specialreg.h U sys/i386/include/trap.h U sys/i386/include/stdarg.h U sys/i386/include/sysarch.h U sys/i386/include/tss.h U sys/i386/include/ultrasound.h U sys/i386/include/varargs.h U sys/i386/include/vmparam.h U sys/i386/include/wtio.h U sys/i386/include/ansi.h U sys/i386/include/in_cksum.h U sys/i386/include/cdk.h U sys/i386/include/comstats.h I sys/i386/include/pc/CVS U sys/i386/include/pc/display.h U sys/i386/include/pc/msdos.h I sys/i386/isa/CVS U sys/i386/isa/README.le U sys/i386/isa/aic6360.c U sys/i386/isa/asc.c U sys/i386/isa/ascreg.h U sys/i386/isa/atapi.c U sys/i386/isa/atapi.h U sys/i386/isa/b004.c U sys/i386/isa/b004.h U sys/i386/isa/bt5xx-445.c C sys/i386/isa/clock.c U sys/i386/isa/cronyx.c U sys/i386/isa/ctx.c U sys/i386/isa/ctxreg.h U sys/i386/isa/cx.c U sys/i386/isa/cxreg.h U sys/i386/isa/cy.c U sys/i386/isa/cyreg.h U sys/i386/isa/diskslice_machdep.c U sys/i386/isa/elink.c U sys/i386/isa/elink.h U sys/i386/isa/fd.c U sys/i386/isa/fdc.h U sys/i386/isa/fdreg.h U sys/i386/isa/ft.c U sys/i386/isa/ftreg.h U sys/i386/isa/gpib.c U sys/i386/isa/gpib.h U sys/i386/isa/gpibreg.h U sys/i386/isa/gsc.c U sys/i386/isa/gscreg.h U sys/i386/isa/icu.h C sys/i386/isa/icu.s U sys/i386/isa/if_ar.c U sys/i386/isa/if_arregs.h U sys/i386/isa/if_cx.c C sys/i386/isa/if_ed.c U sys/i386/isa/if_edreg.h U sys/i386/isa/if_eg.c U sys/i386/isa/if_egreg.h U sys/i386/isa/if_el.c U sys/i386/isa/if_elreg.h U sys/i386/isa/if_ep.c U sys/i386/isa/if_epreg.h U sys/i386/isa/if_fe.c U sys/i386/isa/if_fereg.h U sys/i386/isa/if_ie.c U sys/i386/isa/if_ie507.h U sys/i386/isa/if_iereg.h U sys/i386/isa/if_ix.c U sys/i386/isa/if_ixreg.h U sys/i386/isa/if_le.c U sys/i386/isa/if_lnc.c U sys/i386/isa/if_lnc.h U sys/i386/isa/if_ze.c U sys/i386/isa/if_zp.c U sys/i386/isa/if_zpreg.h C sys/i386/isa/isa.c U sys/i386/isa/isa.h U sys/i386/isa/isa_device.h U sys/i386/isa/joy.c N sys/i386/isa/kbdio.c U sys/i386/isa/kbdtables.h U sys/i386/isa/labpc.c U sys/i386/isa/lpt.c U sys/i386/isa/lptreg.h U sys/i386/isa/mcd.c U sys/i386/isa/mcdreg.h U sys/i386/isa/mse.c U sys/i386/isa/ncr5380.c C sys/i386/isa/npx.c U sys/i386/isa/pcaudio.c C sys/i386/isa/pcibus.c U sys/i386/isa/pcic.h U sys/i386/isa/pcicx.c U sys/i386/isa/prof_machdep.c U sys/i386/isa/psm.c U sys/i386/isa/qcam.c U sys/i386/isa/qcamdefs.h U sys/i386/isa/qcamio.c U sys/i386/isa/qcamreg.h U sys/i386/isa/rc.c C sys/i386/isa/random_machdep.c U sys/i386/isa/rcreg.h U sys/i386/isa/rtc.h U sys/i386/isa/scd.c U sys/i386/isa/scdreg.h U sys/i386/isa/seagate.c U sys/i386/isa/si.c U sys/i386/isa/si_code.c C sys/i386/isa/sio.c U sys/i386/isa/sioreg.h U sys/i386/isa/sireg.h U sys/i386/isa/spigot.c U sys/i386/isa/spkr.c U sys/i386/isa/syscons.c U sys/i386/isa/syscons.h U sys/i386/isa/timerreg.h U sys/i386/isa/tw.c U sys/i386/isa/ultra14f.c C sys/i386/isa/vector.s U sys/i386/isa/wcd.c U sys/i386/isa/wd.c U sys/i386/isa/wd7000.c U sys/i386/isa/wdreg.h U sys/i386/isa/wt.c U sys/i386/isa/wtreg.h U sys/i386/isa/aha1542.c U sys/i386/isa/README.stl U sys/i386/isa/istallion.c U sys/i386/isa/stallion.c U sys/i386/isa/if_sr.c U sys/i386/isa/if_srregs.h N sys/i386/isa/adv_isa.c N sys/i386/isa/aic_98.h N sys/i386/isa/kbdio.h I sys/i386/isa/ic/CVS U sys/i386/isa/ic/Am7990.h U sys/i386/isa/ic/am7990.h U sys/i386/isa/ic/cd1400.h U sys/i386/isa/ic/cd180.h U sys/i386/isa/ic/esp.h U sys/i386/isa/ic/hd64570.h U sys/i386/isa/ic/i8042.h U sys/i386/isa/ic/i82365.h U sys/i386/isa/ic/i8237.h U sys/i386/isa/ic/i82586.h U sys/i386/isa/ic/lemac.h U sys/i386/isa/ic/mb86960.h U sys/i386/isa/ic/ncr53400.h U sys/i386/isa/ic/ncr5380.h U sys/i386/isa/ic/nec765.h U sys/i386/isa/ic/ns16450.h U sys/i386/isa/ic/ns16550.h U sys/i386/isa/ic/scd1400.h U sys/i386/isa/ic/i8251.h U sys/i386/isa/ic/wd33c93.h I sys/i386/isa/matcd/CVS U sys/i386/isa/matcd/TODO U sys/i386/isa/matcd/audio.c U sys/i386/isa/matcd/creative.h U sys/i386/isa/matcd/matcd.c U sys/i386/isa/matcd/matcddrv.h U sys/i386/isa/matcd/options.h I sys/i386/isa/pcvt/CVS U sys/i386/isa/pcvt/pcvt_conf.h U sys/i386/isa/pcvt/pcvt_drv.c U sys/i386/isa/pcvt/pcvt_ext.c U sys/i386/isa/pcvt/pcvt_hdr.h U sys/i386/isa/pcvt/pcvt_kbd.c U sys/i386/isa/pcvt/pcvt_kbd.h U sys/i386/isa/pcvt/pcvt_out.c U sys/i386/isa/pcvt/pcvt_sup.c U sys/i386/isa/pcvt/pcvt_tbl.h U sys/i386/isa/pcvt/pcvt_vtf.c I sys/i386/isa/sound/CVS U sys/i386/isa/sound/CHANGELOG U sys/i386/isa/sound/COPYING U sys/i386/isa/sound/README U sys/i386/isa/sound/Readme.aedsp16 U sys/i386/isa/sound/Readme.modules U sys/i386/isa/sound/Readme.v30 U sys/i386/isa/sound/ad1848.c U sys/i386/isa/sound/ad1848_mixer.h U sys/i386/isa/sound/adlib_card.c U sys/i386/isa/sound/aedsp16.c U sys/i386/isa/sound/audio.c U sys/i386/isa/sound/coproc.h U sys/i386/isa/sound/dev_table.c U sys/i386/isa/sound/dev_table.h U sys/i386/isa/sound/dmabuf.c U sys/i386/isa/sound/finetune.h U sys/i386/isa/sound/gus_card.c U sys/i386/isa/sound/gus_hw.h U sys/i386/isa/sound/gus_linearvol.h U sys/i386/isa/sound/gus_midi.c U sys/i386/isa/sound/gus_vol.c U sys/i386/isa/sound/gus_wave.c U sys/i386/isa/sound/hex2hex.h U sys/i386/isa/sound/ics2101.c U sys/i386/isa/sound/local.h U sys/i386/isa/sound/mad16.h U sys/i386/isa/sound/midi_ctrl.h U sys/i386/isa/sound/midi_synth.c U sys/i386/isa/sound/midi_synth.h U sys/i386/isa/sound/midibuf.c U sys/i386/isa/sound/mpu401.c U sys/i386/isa/sound/opl3.c U sys/i386/isa/sound/opl3.h U sys/i386/isa/sound/os.h U sys/i386/isa/sound/pas2_card.c U sys/i386/isa/sound/pas2_midi.c U sys/i386/isa/sound/pas2_mixer.c U sys/i386/isa/sound/pas2_pcm.c U sys/i386/isa/sound/patmgr.c U sys/i386/isa/sound/sb16_dsp.c U sys/i386/isa/sound/sb16_midi.c U sys/i386/isa/sound/sb_card.c U sys/i386/isa/sound/sb_dsp.c U sys/i386/isa/sound/sb_midi.c U sys/i386/isa/sound/sb_mixer.c U sys/i386/isa/sound/sb_mixer.h U sys/i386/isa/sound/sequencer.c U sys/i386/isa/sound/sound.doc U sys/i386/isa/sound/sound_calls.h U sys/i386/isa/sound/sound_config.h U sys/i386/isa/sound/sound_switch.c U sys/i386/isa/sound/sound_timer.c U sys/i386/isa/sound/soundcard.c U sys/i386/isa/sound/soundvers.h U sys/i386/isa/sound/sscape.c U sys/i386/isa/sound/sys_timer.c U sys/i386/isa/sound/trix.c U sys/i386/isa/sound/tuning.h U sys/i386/isa/sound/uart6850.c U sys/i386/isa/sound/ulaw.h N sys/i386/isa/sound/pcm86.c N sys/i386/isa/sound/awe_hw.h N sys/i386/isa/sound/awe_voice.h N sys/i386/isa/sound/awe_wave.c N sys/i386/isa/sound/pas_defs.h N sys/i386/isa/sound/sb_defs.h I sys/i386/linux/CVS U sys/i386/linux/imgact_linux.c U sys/i386/linux/linux.h U sys/i386/linux/linux_dummy.c U sys/i386/linux/linux_file.c U sys/i386/linux/linux_genassym.c U sys/i386/linux/linux_ioctl.c U sys/i386/linux/linux_ipc.c U sys/i386/linux/linux_locore.s U sys/i386/linux/linux_misc.c U sys/i386/linux/linux_proto.h U sys/i386/linux/linux_signal.c U sys/i386/linux/linux_socket.c U sys/i386/linux/linux_stats.c U sys/i386/linux/linux_syscall.h U sys/i386/linux/linux_sysent.c U sys/i386/linux/linux_sysvec.c U sys/i386/linux/linux_util.c U sys/i386/linux/linux_util.h U sys/i386/linux/syscalls.conf U sys/i386/linux/syscalls.master I sys/i386/scsi/CVS U sys/i386/scsi/93cx6.c U sys/i386/scsi/93cx6.h U sys/i386/scsi/aic7xxx.c U sys/i386/scsi/aic7xxx.h U sys/i386/scsi/bt.c U sys/i386/scsi/btreg.h N sys/i386/scsi/advansys.c N sys/i386/scsi/advansys.h I sys/isofs/CVS I sys/isofs/cd9660/CVS U sys/isofs/cd9660/TODO U sys/isofs/cd9660/TODO.hibler U sys/isofs/cd9660/cd9660_bmap.c U sys/isofs/cd9660/cd9660_lookup.c U sys/isofs/cd9660/cd9660_mount.h U sys/isofs/cd9660/cd9660_node.c U sys/isofs/cd9660/cd9660_node.h U sys/isofs/cd9660/cd9660_rrip.c U sys/isofs/cd9660/cd9660_rrip.h U sys/isofs/cd9660/cd9660_util.c U sys/isofs/cd9660/cd9660_vfsops.c U sys/isofs/cd9660/cd9660_vnops.c U sys/isofs/cd9660/iso.h U sys/isofs/cd9660/iso_rrip.h I sys/kern/CVS U sys/kern/Make.tags.inc U sys/kern/Makefile U sys/kern/imgact_aout.c U sys/kern/imgact_elf.c U sys/kern/imgact_gzip.c U sys/kern/imgact_shell.c U sys/kern/inflate.c C sys/kern/init_main.c U sys/kern/init_sysent.c U sys/kern/init_sysvec.c U sys/kern/kern_acct.c C sys/kern/kern_clock.c U sys/kern/kern_conf.c U sys/kern/kern_descrip.c C sys/kern/kern_exit.c U sys/kern/kern_exec.c U sys/kern/kern_mib.c C sys/kern/kern_fork.c U sys/kern/kern_ktrace.c U sys/kern/kern_lkm.c U sys/kern/kern_lockf.c U sys/kern/kern_malloc.c U sys/kern/kern_ntptime.c U sys/kern/kern_physio.c U sys/kern/kern_proc.c U sys/kern/kern_prot.c U sys/kern/kern_resource.c C sys/kern/kern_sig.c U sys/kern/kern_subr.c C sys/kern/kern_synch.c U sys/kern/kern_sysctl.c U sys/kern/kern_time.c U sys/kern/kern_xxx.c U sys/kern/makesyscalls.sh U sys/kern/subr_autoconf.c U sys/kern/subr_diskslice.c U sys/kern/subr_dkbad.c U sys/kern/subr_log.c U sys/kern/subr_prf.c U sys/kern/subr_prof.c U sys/kern/subr_rlist.c U sys/kern/subr_xxx.c U sys/kern/sys_pipe.c U sys/kern/sys_generic.c U sys/kern/sys_process.c U sys/kern/sys_socket.c U sys/kern/syscalls.c U sys/kern/syscalls.master U sys/kern/sysv_ipc.c U sys/kern/sysv_msg.c U sys/kern/sysv_sem.c U sys/kern/sysv_shm.c U sys/kern/tty.c U sys/kern/tty_compat.c U sys/kern/tty_conf.c U sys/kern/tty_pty.c U sys/kern/tty_snoop.c U sys/kern/tty_subr.c U sys/kern/tty_tb.c U sys/kern/tty_tty.c U sys/kern/uipc_domain.c U sys/kern/uipc_mbuf.c U sys/kern/uipc_proto.c U sys/kern/uipc_socket.c U sys/kern/uipc_socket2.c U sys/kern/uipc_syscalls.c U sys/kern/uipc_usrreq.c C sys/kern/vfs_bio.c U sys/kern/vfs_cache.c U sys/kern/vfs_cluster.c U sys/kern/vfs_conf.c U sys/kern/vfs_init.c U sys/kern/vfs_lookup.c U sys/kern/vfs_subr.c U sys/kern/vfs_syscalls.c U sys/kern/vfs_vnops.c U sys/kern/vnode_if.sh U sys/kern/vnode_if.src C sys/kern/kern_shutdown.c I sys/libkern/CVS U sys/libkern/adddi3.c U sys/libkern/anddi3.c U sys/libkern/ashldi3.c U sys/libkern/ashrdi3.c U sys/libkern/bcd.c U sys/libkern/bcmp.c U sys/libkern/cmpdi2.c U sys/libkern/divdi3.c U sys/libkern/ffs.c U sys/libkern/inet_ntoa.c U sys/libkern/iordi3.c U sys/libkern/locc.c U sys/libkern/lshldi3.c U sys/libkern/lshrdi3.c U sys/libkern/mcount.c U sys/libkern/moddi3.c U sys/libkern/muldi3.c U sys/libkern/negdi2.c U sys/libkern/notdi2.c U sys/libkern/qdivrem.c U sys/libkern/qsort.c U sys/libkern/quad.h U sys/libkern/random.c U sys/libkern/rindex.c U sys/libkern/scanc.c U sys/libkern/skpc.c U sys/libkern/strcat.c U sys/libkern/strcmp.c U sys/libkern/strcpy.c U sys/libkern/strlen.c U sys/libkern/strncmp.c U sys/libkern/strncpy.c U sys/libkern/subdi3.c U sys/libkern/ucmpdi2.c U sys/libkern/udivdi3.c U sys/libkern/umoddi3.c U sys/libkern/xordi3.c U sys/libkern/index.c I sys/miscfs/CVS I sys/miscfs/deadfs/CVS U sys/miscfs/deadfs/dead_vnops.c I sys/miscfs/devfs/CVS U sys/miscfs/devfs/README U sys/miscfs/devfs/devfs_proto.h U sys/miscfs/devfs/devfs_tree.c U sys/miscfs/devfs/devfs_vfsops.c U sys/miscfs/devfs/devfs_vnops.c U sys/miscfs/devfs/devfsdefs.h U sys/miscfs/devfs/reproto.sh I sys/miscfs/fdesc/CVS U sys/miscfs/fdesc/fdesc.h U sys/miscfs/fdesc/fdesc_vfsops.c U sys/miscfs/fdesc/fdesc_vnops.c I sys/miscfs/fifofs/CVS U sys/miscfs/fifofs/fifo.h U sys/miscfs/fifofs/fifo_vnops.c I sys/miscfs/kernfs/CVS U sys/miscfs/kernfs/kernfs.h U sys/miscfs/kernfs/kernfs_vfsops.c U sys/miscfs/kernfs/kernfs_vnops.c I sys/miscfs/nullfs/CVS U sys/miscfs/nullfs/null.h U sys/miscfs/nullfs/null_subr.c U sys/miscfs/nullfs/null_vfsops.c U sys/miscfs/nullfs/null_vnops.c I sys/miscfs/portal/CVS U sys/miscfs/portal/portal.h U sys/miscfs/portal/portal_vfsops.c U sys/miscfs/portal/portal_vnops.c I sys/miscfs/procfs/CVS U sys/miscfs/procfs/README U sys/miscfs/procfs/procfs.h U sys/miscfs/procfs/procfs_ctl.c U sys/miscfs/procfs/procfs_fpregs.c U sys/miscfs/procfs/procfs_mem.c U sys/miscfs/procfs/procfs_note.c U sys/miscfs/procfs/procfs_regs.c U sys/miscfs/procfs/procfs_status.c U sys/miscfs/procfs/procfs_subr.c U sys/miscfs/procfs/procfs_vfsops.c U sys/miscfs/procfs/procfs_vnops.c U sys/miscfs/procfs/procfs_map.c U sys/miscfs/procfs/procfs_type.c I sys/miscfs/specfs/CVS U sys/miscfs/specfs/spec_vnops.c U sys/miscfs/specfs/specdev.h I sys/miscfs/umapfs/CVS U sys/miscfs/umapfs/umap.h U sys/miscfs/umapfs/umap_subr.c U sys/miscfs/umapfs/umap_vfsops.c U sys/miscfs/umapfs/umap_vnops.c I sys/miscfs/union/CVS U sys/miscfs/union/README U sys/miscfs/union/libc.fts.c U sys/miscfs/union/libc.opendir.c U sys/miscfs/union/libc.readdir.c U sys/miscfs/union/union.h U sys/miscfs/union/union_subr.c U sys/miscfs/union/union_vfsops.c U sys/miscfs/union/union_vnops.c I sys/msdosfs/CVS U sys/msdosfs/bootsect.h U sys/msdosfs/bpb.h U sys/msdosfs/denode.h U sys/msdosfs/direntry.h U sys/msdosfs/fat.h U sys/msdosfs/msdosfs_conv.c U sys/msdosfs/msdosfs_denode.c U sys/msdosfs/msdosfs_fat.c U sys/msdosfs/msdosfs_lookup.c U sys/msdosfs/msdosfs_vfsops.c U sys/msdosfs/msdosfs_vnops.c U sys/msdosfs/msdosfsmount.h I sys/net/CVS U sys/net/bpf.c U sys/net/bpf.h U sys/net/bpf_compat.h U sys/net/bpf_filter.c U sys/net/bpfdesc.h U sys/net/bsd_comp.c U sys/net/if.c U sys/net/if.h U sys/net/if_arp.h U sys/net/if_disc.c U sys/net/if_dl.h U sys/net/if_ethersubr.c U sys/net/if_fddisubr.c U sys/net/if_llc.h U sys/net/if_loop.c U sys/net/if_ppp.c U sys/net/if_ppp.h U sys/net/if_pppvar.h U sys/net/if_sl.c U sys/net/if_slvar.h U sys/net/if_sppp.h U sys/net/if_spppsubr.c U sys/net/if_tun.c U sys/net/if_tun.h U sys/net/if_types.h U sys/net/netisr.h U sys/net/ppp_comp.h U sys/net/ppp_defs.h U sys/net/ppp_tty.c U sys/net/radix.c U sys/net/radix.h U sys/net/raw_cb.c U sys/net/raw_cb.h U sys/net/raw_usrreq.c U sys/net/route.c U sys/net/route.h U sys/net/rtsock.c U sys/net/slcompress.c U sys/net/slcompress.h U sys/net/slip.h U sys/net/ethernet.h U sys/net/if_mib.c U sys/net/if_mib.h I sys/netinet/CVS U sys/netinet/icmp_var.h U sys/netinet/if_ether.c U sys/netinet/if_ether.h U sys/netinet/if_fddi.h U sys/netinet/igmp.c U sys/netinet/igmp.h U sys/netinet/igmp_var.h U sys/netinet/in.c U sys/netinet/in.h U sys/netinet/in_cksum.c U sys/netinet/in_pcb.c U sys/netinet/in_pcb.h U sys/netinet/in_proto.c U sys/netinet/in_rmx.c U sys/netinet/in_systm.h U sys/netinet/in_var.h U sys/netinet/ip.h U sys/netinet/ip_fw.c U sys/netinet/ip_fw.h U sys/netinet/ip_icmp.c U sys/netinet/ip_icmp.h U sys/netinet/ip_input.c U sys/netinet/ip_mroute.c U sys/netinet/ip_mroute.h U sys/netinet/ip_output.c U sys/netinet/ip_var.h U sys/netinet/raw_ip.c U sys/netinet/tcp.h U sys/netinet/tcp_debug.c U sys/netinet/tcp_debug.h U sys/netinet/tcp_fsm.h U sys/netinet/tcp_input.c U sys/netinet/tcp_output.c U sys/netinet/tcp_seq.h U sys/netinet/tcp_subr.c U sys/netinet/tcp_timer.c U sys/netinet/tcp_timer.h U sys/netinet/tcp_usrreq.c U sys/netinet/tcp_var.h U sys/netinet/tcpip.h U sys/netinet/udp.h U sys/netinet/udp_usrreq.c U sys/netinet/udp_var.h U sys/netinet/ip_divert.c I sys/netipx/CVS U sys/netipx/README U sys/netipx/ipx.c U sys/netipx/ipx.h U sys/netipx/ipx_cksum.c U sys/netipx/ipx_error.c U sys/netipx/ipx_error.h U sys/netipx/ipx_if.h U sys/netipx/ipx_input.c U sys/netipx/ipx_ip.c U sys/netipx/ipx_ip.h U sys/netipx/ipx_outputfl.c U sys/netipx/ipx_pcb.c U sys/netipx/ipx_pcb.h U sys/netipx/ipx_proto.c U sys/netipx/ipx_tun.c U sys/netipx/ipx_usrreq.c U sys/netipx/ipx_var.h U sys/netipx/spx.h U sys/netipx/spx_debug.c U sys/netipx/spx_debug.h U sys/netipx/spx_timer.h U sys/netipx/spx_usrreq.c U sys/netipx/spx_var.h I sys/nfs/CVS U sys/nfs/nfs.h U sys/nfs/nfs_bio.c U sys/nfs/nfs_node.c U sys/nfs/nfs_nqlease.c U sys/nfs/nfs_serv.c U sys/nfs/nfs_socket.c U sys/nfs/nfs_srvcache.c U sys/nfs/nfs_subs.c U sys/nfs/nfs_syscalls.c U sys/nfs/nfs_vfsops.c U sys/nfs/nfs_vnops.c U sys/nfs/nfsdiskless.h U sys/nfs/nfsm_subs.h U sys/nfs/nfsmount.h U sys/nfs/nfsnode.h U sys/nfs/nfsproto.h U sys/nfs/nfsrtt.h U sys/nfs/nfsrvcache.h U sys/nfs/nfsv2.h U sys/nfs/nqnfs.h U sys/nfs/rpcv2.h U sys/nfs/xdr_subs.h I sys/pccard/CVS U sys/pccard/card.h U sys/pccard/cis.h U sys/pccard/driver.h U sys/pccard/i82365.h U sys/pccard/pccard.c U sys/pccard/pcic.c U sys/pccard/skel.c U sys/pccard/slot.h U sys/pccard/pcic98reg.h I sys/pci/CVS U sys/pci/README.de U sys/pci/README.de-le U sys/pci/aic7870.c U sys/pci/bt9xx.c U sys/pci/dc21040.h U sys/pci/if_de.c U sys/pci/if_fxp.c U sys/pci/if_fxpreg.h U sys/pci/if_pdq.c U sys/pci/meteor.c U sys/pci/ncr.c U sys/pci/locate.pl U sys/pci/ncrreg.h U sys/pci/meteor_reg.h C sys/pci/pci.c N sys/pci/pci_ioctl.h U sys/pci/pcibus.h C sys/pci/pcireg.h U sys/pci/pcisupport.c U sys/pci/pcivar.h U sys/pci/pdq.c U sys/pci/pdq_os.h U sys/pci/pdqreg.h U sys/pci/wd82371.c U sys/pci/wd82371reg.h U sys/pci/if_ed_p.c U sys/pci/if_lnc_p.c N sys/pci/cy_pci.c N sys/pci/cy_pcireg.h N sys/pci/if_sr_p.c N sys/pci/if_vx_pci.c I sys/scsi/CVS U sys/scsi/README U sys/scsi/cd.c U sys/scsi/ch.c U sys/scsi/od.c U sys/scsi/pt.c U sys/scsi/scsi_all.h U sys/scsi/scsi_base.c U sys/scsi/scsi_cd.h U sys/scsi/scsi_changer.h U sys/scsi/scsi_debug.h U sys/scsi/scsi_disk.h U sys/scsi/scsi_driver.c U sys/scsi/scsi_driver.h U sys/scsi/scsi_generic.h U sys/scsi/scsi_ioctl.c U sys/scsi/scsi_sense.c U sys/scsi/scsi_tape.h U sys/scsi/scsi_worm.h U sys/scsi/scsiconf.c U sys/scsi/scsiconf.h U sys/scsi/sctarg.c U sys/scsi/sd.c U sys/scsi/ssc.c U sys/scsi/st.c U sys/scsi/su.c U sys/scsi/uk.c U sys/scsi/worm.c U sys/scsi/scsi_message.h I sys/sys/CVS U sys/sys/acct.h U sys/sys/buf.h U sys/sys/callout.h U sys/sys/cdefs.h U sys/sys/cdio.h U sys/sys/chio.h U sys/sys/clist.h U sys/sys/conf.h U sys/sys/dataacq.h U sys/sys/disklabel.h U sys/sys/devfsext.h U sys/sys/device.h U sys/sys/dir.h U sys/sys/dirent.h U sys/sys/disk.h U sys/sys/diskslice.h U sys/sys/dkbad.h U sys/sys/ftape.h U sys/sys/dkstat.h U sys/sys/dmap.h U sys/sys/domain.h U sys/sys/errno.h U sys/sys/exec.h U sys/sys/fbio.h U sys/sys/fcntl.h U sys/sys/file.h U sys/sys/filedesc.h U sys/sys/filio.h U sys/sys/ioctl.h U sys/sys/gmon.h U sys/sys/imgact.h U sys/sys/imgact_aout.h U sys/sys/imgact_elf.h U sys/sys/inflate.h U sys/sys/ioccom.h U sys/sys/mount.h U sys/sys/ioctl_compat.h U sys/sys/ipc.h U sys/sys/kernel.h U sys/sys/ktrace.h U sys/sys/libkern.h U sys/sys/lkm.h U sys/sys/lockf.h U sys/sys/malloc.h U sys/sys/mbuf.h U sys/sys/mman.h U sys/sys/mtio.h U sys/sys/msg.h U sys/sys/msgbuf.h C sys/sys/proc.h U sys/sys/namei.h U sys/sys/param.h U sys/sys/pipe.h U sys/sys/scsiio.h U sys/sys/protosw.h U sys/sys/ptrace.h U sys/sys/queue.h U sys/sys/reboot.h U sys/sys/resource.h U sys/sys/resourcevar.h U sys/sys/rlist.h U sys/sys/rtprio.h U sys/sys/sockio.h U sys/sys/select.h U sys/sys/sem.h U sys/sys/shm.h U sys/sys/signal.h U sys/sys/signalvar.h U sys/sys/snoop.h U sys/sys/socket.h U sys/sys/socketvar.h U sys/sys/stat.h U sys/sys/syscall-hide.h U sys/sys/syscall.h U sys/sys/sysctl.h U sys/sys/sysproto.h U sys/sys/sysent.h U sys/sys/syslimits.h U sys/sys/syslog.h U sys/sys/systm.h U sys/sys/tablet.h U sys/sys/time.h U sys/sys/termios.h U sys/sys/user.h U sys/sys/timeb.h U sys/sys/timers.h U sys/sys/times.h U sys/sys/timex.h U sys/sys/tprintf.h U sys/sys/tty.h U sys/sys/ttychars.h U sys/sys/ttycom.h U sys/sys/ttydefaults.h U sys/sys/ttydev.h U sys/sys/types.h U sys/sys/ucred.h U sys/sys/uio.h U sys/sys/un.h U sys/sys/unistd.h U sys/sys/unpcb.h U sys/sys/vcmd.h U sys/sys/utsname.h U sys/sys/vadvise.h U sys/sys/vnode.h U sys/sys/vlimit.h U sys/sys/vmmeter.h U sys/sys/vnioctl.h U sys/sys/vsio.h U sys/sys/wait.h U sys/sys/wormio.h U sys/sys/ccdvar.h I sys/ufs/CVS I sys/ufs/ffs/CVS U sys/ufs/ffs/ffs_alloc.c U sys/ufs/ffs/ffs_balloc.c U sys/ufs/ffs/ffs_extern.h U sys/ufs/ffs/ffs_inode.c U sys/ufs/ffs/ffs_subr.c U sys/ufs/ffs/ffs_tables.c U sys/ufs/ffs/ffs_vfsops.c U sys/ufs/ffs/ffs_vnops.c U sys/ufs/ffs/fs.h I sys/ufs/lfs/CVS U sys/ufs/lfs/README U sys/ufs/lfs/TODO U sys/ufs/lfs/lfs.h U sys/ufs/lfs/lfs_alloc.c U sys/ufs/lfs/lfs_balloc.c U sys/ufs/lfs/lfs_bio.c U sys/ufs/lfs/lfs_cksum.c U sys/ufs/lfs/lfs_debug.c U sys/ufs/lfs/lfs_extern.h U sys/ufs/lfs/lfs_inode.c U sys/ufs/lfs/lfs_segment.c U sys/ufs/lfs/lfs_subr.c U sys/ufs/lfs/lfs_syscalls.c U sys/ufs/lfs/lfs_vfsops.c U sys/ufs/lfs/lfs_vnops.c I sys/ufs/mfs/CVS U sys/ufs/mfs/mfs_extern.h U sys/ufs/mfs/mfs_vfsops.c U sys/ufs/mfs/mfs_vnops.c U sys/ufs/mfs/mfsiom.h U sys/ufs/mfs/mfsnode.h I sys/ufs/ufs/CVS U sys/ufs/ufs/dinode.h U sys/ufs/ufs/dir.h U sys/ufs/ufs/inode.h U sys/ufs/ufs/quota.h U sys/ufs/ufs/ufs_bmap.c U sys/ufs/ufs/ufs_disksubr.c U sys/ufs/ufs/ufs_extern.h U sys/ufs/ufs/ufs_ihash.c U sys/ufs/ufs/ufs_inode.c U sys/ufs/ufs/ufs_lookup.c U sys/ufs/ufs/ufs_quota.c U sys/ufs/ufs/ufs_readwrite.c U sys/ufs/ufs/ufs_vfsops.c U sys/ufs/ufs/ufs_vnops.c U sys/ufs/ufs/ufsmount.h I sys/vm/CVS U sys/vm/default_pager.c U sys/vm/default_pager.h U sys/vm/device_pager.c U sys/vm/device_pager.h U sys/vm/kern_lock.c U sys/vm/lock.h U sys/vm/pmap.h U sys/vm/swap_pager.c U sys/vm/swap_pager.h U sys/vm/vm.h U sys/vm/vm_extern.h U sys/vm/vm_fault.c C sys/vm/vm_glue.c U sys/vm/vm_inherit.h U sys/vm/vm_init.c U sys/vm/vm_kern.c U sys/vm/vm_kern.h U sys/vm/vm_map.c U sys/vm/vm_map.h U sys/vm/vm_meter.c U sys/vm/vm_mmap.c U sys/vm/vm_object.c U sys/vm/vm_object.h U sys/vm/vm_page.c U sys/vm/vm_page.h U sys/vm/vm_pageout.c U sys/vm/vm_pageout.h U sys/vm/vm_pager.c U sys/vm/vm_pager.h U sys/vm/vm_param.h U sys/vm/vm_prot.h U sys/vm/vm_swap.c U sys/vm/vm_unix.c U sys/vm/vnode_pager.c U sys/vm/vnode_pager.h I sys/netatalk/CVS U sys/netatalk/aarp.c U sys/netatalk/aarp.h U sys/netatalk/at.h U sys/netatalk/at_control.c U sys/netatalk/at_extern.h U sys/netatalk/at_proto.c U sys/netatalk/at_rmx.c U sys/netatalk/at_var.h U sys/netatalk/ddp.h U sys/netatalk/ddp_input.c U sys/netatalk/ddp_output.c U sys/netatalk/ddp_usrreq.c U sys/netatalk/ddp_var.h U sys/netatalk/endian.h U sys/netatalk/phase2.h U sys/netatalk/COPYRIGHT 32 conflicts created by this import. Use the following command to help the merge: cvs checkout -jCURRENT:yesterday -jCURRENT sys From owner-freebsd-smp Wed Nov 20 13:06:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09953 for smp-outgoing; Wed, 20 Nov 1996 13:06:13 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA09946 for ; Wed, 20 Nov 1996 13:06:08 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id PAA00343; Wed, 20 Nov 1996 15:06:03 -0600 (CST) Message-Id: <199611202106.PAA00343@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of Wed, 20 Nov 1996 13:17:49 -0700. <199611202017.NAA26482@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 15:06:03 -0600 From: Chris Csanady Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I've never seen this, but have only been running APIC_LAZY since the >bug fix of last nite (approx 16 hours). > >We are both running the same MB and disk controller: GA586DX/7880 (true?) Yes. >Have you ever seen this b4, ie without APIC_LAZY defined? >When does it happen, at boot, or continually? Ok, I just tried it without APIC_IO altogether, and it still happens. I think the reason I never noticed it before was I didnt have option DIAGNOSTIC. (I looked, it is #ifdefed by DIAGNOSTIC) It happenes with or without APIC_IO, and on either 1 or 2 processors. This almost leads me to believe its not very SMP related at all. :\ It doesnt happen in current though I dont believe.. Chris >Any vm experts out there who can give a generic description of this error, >or what might cause it? > >-- >Steve Passe | powered by >smp@csn.net | FreeBSD > From owner-freebsd-smp Wed Nov 20 13:10:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10253 for smp-outgoing; Wed, 20 Nov 1996 13:10:43 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA10244 for ; Wed, 20 Nov 1996 13:10:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA26815; Wed, 20 Nov 1996 14:10:22 -0700 Message-Id: <199611202110.OAA26815@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Chris Csanady cc: Peter Wemm , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 15:06:03 CST." <199611202106.PAA00343@friley216.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 14:10:21 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >Have you ever seen this b4, ie without APIC_LAZY defined? > >When does it happen, at boot, or continually? > > Ok, I just tried it without APIC_IO altogether, and it still happens. I think > the reason I never noticed it before was I didnt have option DIAGNOSTIC. (I > looked, it is #ifdefed by DIAGNOSTIC) > > It happenes with or without APIC_IO, and on either 1 or 2 processors. This > almost leads me to believe its not very SMP related at all. :\ It doesnt > happen in current though I dont believe.. if it happens with only 1 processor running I would think it rules out the tlb theory... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 20 13:12:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10379 for smp-outgoing; Wed, 20 Nov 1996 13:12:38 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA10368 for ; Wed, 20 Nov 1996 13:12:33 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id FAA12954; Thu, 21 Nov 1996 05:12:18 +0800 (WST) Message-Id: <199611202112.FAA12954@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 cc: Chris Csanady , Steve Passe , freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Thu, 21 Nov 1996 04:58:24 +0800." <199611202058.EAA12835@spinner.DIALix.COM> Date: Thu, 21 Nov 1996 05:12:17 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm wrote: > Yes, and potentially rather nasty. :-( Here's why: > > CPU 1: Running in user mode > CPU 2: enters kernel, frees up pages that belong to the process that CPU > 1 is running, reassigns them elsewhere, flushes it's TLB and uses the new > mappings. > CPU 1: blissfully unaware while the TLB cache holds.. Continues to use > the page that it thinks it owns, but might now be being used to write an > inode or something... Hmm, I just reread that and realised that I didn't state the implications clearly enough.. This is not merely an "oops, the smp kernel crashed/hung!" type problem. It's potentially an "Oh shit! It just destroyed all my filesystems and lost all my data!!!" type problem. The fact that we've not heard of it happening yet is probably an indication of several things: - the developers machines have gobs of ram, reducing the page stealing. - the P5 appears to have a smallish TLB, so there may be a relatively quick recycling of TLB slots, again reducing the window. - The TLB is flushed on a context switch, and potentially on every syscall. This is why we say "for developers only" amd don't reccomend it for general use. I personally strongly discourage it for critical systems.. Cheers, -Peter From owner-freebsd-smp Wed Nov 20 13:36:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11697 for smp-outgoing; Wed, 20 Nov 1996 13:36:45 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA11642 for ; Wed, 20 Nov 1996 13:36:18 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id FAA13316; Thu, 21 Nov 1996 05:35:31 +0800 (WST) Message-Id: <199611202135.FAA13316@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Tue, 19 Nov 1996 21:59:04 MST." <199611200459.VAA22372@clem.systemsix.com> Date: Thu, 21 Nov 1996 05:35:30 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > The 8259 ICU latches an INT that occurs while that INT is masked. > The IO APIC looses any INT occuring while that INT is masked. > Intel calls this a "design consideration", I call it "brain damage". Also, don't forget, there are two types of masking with the apic system. (beware, I don't have the docs in front of me, I'm going from stale memory. Please be gentle :-) First: There is the single on/off bit in the IO apic registers. This is slow to get at and quite cumbersome, since it involves bit shuffling and accessing hardware via a bank-switched register system. This method looses edge triggered interrupts if they occur while the APIC pin is turned off (no real suprise there). Second: There is the local mask on the CPU, combined with focus processing. This method has advantages and disadvantages. It has a "pending" register so that it doesn't loose edge triggered interrupts. "Focus processing" means that while CPU 'n' is servicing a particular interrupt, the IO apic's route *all* further interrupts of that type to that processor. This is necessary since the local mask is per-cpu and this is how it prevents the handlers from interrupting themselves. It implements a priority system. The source IRQ is implicitly masked and unmasked during execution of the handler with no extra work by the OS, other than hitting the EOI register at the end. The big problem with approach #2 is that it's completely different to the way FreeBSD's traditional 8259-based interrupt system was implemented. It requires that you prioritise interrupts in numerical order (or you have to deal with 256-bit masking), and you have to choose things like whether splimp() is greater or less than spltty(). Also, you're dealing with 256 bit registers on a per-cpu basis, ie: cpu 2 cannot see what's masked in cpu 1's registers (without an APIC remote read) and so on. Since the IRQ system needs to be redone to handle > 32 interrupts since: - we need to be able to have the 8259's online for some (current) hardware. - we need to be able to deal with more than 1 IO apic. - we need to be able to deal with IPI's, and be able to mask them etc. I personally think that the right "temporary" solution for the edge trigger problem is to never disable the IO apic pin (for edge only), and simply wear the cost of the relatively rare occasions when the interrupts *do* interrupt their own handlers. Cheers, -Peter From owner-freebsd-smp Wed Nov 20 13:37:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11771 for smp-outgoing; Wed, 20 Nov 1996 13:37:55 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11750 for freebsd-smp; Wed, 20 Nov 1996 13:37:38 -0800 (PST) Date: Wed, 20 Nov 1996 13:37:38 -0800 (PST) From: Peter Wemm Message-Id: <199611202137.NAA11750@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/vm vm_glue.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:37:32 Modified: vm vm_glue.c Log: merge the easy conflicts Revision Changes Path 1.11 +12 -106 sys/vm/vm_glue.c From owner-freebsd-smp Wed Nov 20 13:40:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12113 for smp-outgoing; Wed, 20 Nov 1996 13:40:31 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12096 for freebsd-smp; Wed, 20 Nov 1996 13:40:20 -0800 (PST) Date: Wed, 20 Nov 1996 13:40:20 -0800 (PST) From: Peter Wemm Message-Id: <199611202140.NAA12096@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c kern_clock.c kern_exit.c kern_fork.c kern_shutdown.c kern_sig.c kern_synch.c vfs_bio.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:40:18 Modified: kern init_main.c kern_clock.c kern_exit.c kern_fork.c kern_shutdown.c kern_sig.c kern_synch.c vfs_bio.c Log: merge easy conflicts Revision Changes Path 1.30 +8 -2 sys/kern/init_main.c 1.3 +4 -1 sys/kern/kern_clock.c 1.10 +5 -2 sys/kern/kern_exit.c 1.8 +3 -2 sys/kern/kern_fork.c 1.6 +8 -2 sys/kern/kern_shutdown.c 1.6 +2 -9 sys/kern/kern_sig.c 1.12 +6 -2 sys/kern/kern_synch.c 1.11 +41 -45 sys/kern/vfs_bio.c From owner-freebsd-smp Wed Nov 20 13:42:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12267 for smp-outgoing; Wed, 20 Nov 1996 13:42:30 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12258 for freebsd-smp; Wed, 20 Nov 1996 13:42:28 -0800 (PST) Date: Wed, 20 Nov 1996 13:42:28 -0800 (PST) From: Peter Wemm Message-Id: <199611202142.NAA12258@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/sys proc.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:42:27 Modified: sys proc.h Log: merge -current Revision Changes Path 1.15 +3 -4 sys/sys/proc.h From owner-freebsd-smp Wed Nov 20 13:45:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12462 for smp-outgoing; Wed, 20 Nov 1996 13:45:01 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12447 for freebsd-smp; Wed, 20 Nov 1996 13:44:56 -0800 (PST) Date: Wed, 20 Nov 1996 13:44:56 -0800 (PST) From: Peter Wemm Message-Id: <199611202144.NAA12447@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/pci pci.c pcireg.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:44:54 Modified: pci pci.c pcireg.h Log: merge -current Revision Changes Path 1.5 +180 -34 sys/pci/pci.c 1.4 +7 -5 sys/pci/pcireg.h From owner-freebsd-smp Wed Nov 20 13:46:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12600 for smp-outgoing; Wed, 20 Nov 1996 13:46:32 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12588 for freebsd-smp; Wed, 20 Nov 1996 13:46:30 -0800 (PST) Date: Wed, 20 Nov 1996 13:46:30 -0800 (PST) From: Peter Wemm Message-Id: <199611202146.NAA12588@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa random_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:46:29 Modified: i386/isa random_machdep.c Log: easy merge Revision Changes Path 1.4 +8 -3 sys/i386/isa/random_machdep.c From owner-freebsd-smp Wed Nov 20 13:48:39 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12747 for smp-outgoing; Wed, 20 Nov 1996 13:48:39 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12738 for freebsd-smp; Wed, 20 Nov 1996 13:48:37 -0800 (PST) Date: Wed, 20 Nov 1996 13:48:37 -0800 (PST) From: Peter Wemm Message-Id: <199611202148.NAA12738@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/conf files.i386 options.i386 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:48:36 Modified: i386/conf files.i386 options.i386 Log: merge -current in. (!&@^%!*&#^ $Id$ spam!) Revision Changes Path 1.11 +8 -3 sys/i386/conf/files.i386 1.10 +13 -3 sys/i386/conf/options.i386 From owner-freebsd-smp Wed Nov 20 13:50:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12917 for smp-outgoing; Wed, 20 Nov 1996 13:50:08 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12908 for freebsd-smp; Wed, 20 Nov 1996 13:50:06 -0800 (PST) Date: Wed, 20 Nov 1996 13:50:06 -0800 (PST) From: Peter Wemm Message-Id: <199611202150.NAA12908@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 genassym.c identcpu.c locore.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:50:05 Modified: i386/i386 genassym.c identcpu.c locore.s Log: merge -current in Revision Changes Path 1.6 +2 -1 sys/i386/i386/genassym.c 1.4 +4 -4 sys/i386/i386/identcpu.c 1.30 +36 -17 sys/i386/i386/locore.s From owner-freebsd-smp Wed Nov 20 13:53:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13122 for smp-outgoing; Wed, 20 Nov 1996 13:53:56 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13108 for freebsd-smp; Wed, 20 Nov 1996 13:53:52 -0800 (PST) Date: Wed, 20 Nov 1996 13:53:52 -0800 (PST) From: Peter Wemm Message-Id: <199611202153.NAA13108@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include clock.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:53:51 Modified: i386/include clock.h Log: merge -current Revision Changes Path 1.3 +72 -58 sys/i386/include/clock.h From owner-freebsd-smp Wed Nov 20 13:55:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13219 for smp-outgoing; Wed, 20 Nov 1996 13:55:52 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13210 for freebsd-smp; Wed, 20 Nov 1996 13:55:50 -0800 (PST) Date: Wed, 20 Nov 1996 13:55:50 -0800 (PST) From: Peter Wemm Message-Id: <199611202155.NAA13210@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa clock.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:55:49 Modified: i386/isa clock.c Log: merge -current Revision Changes Path 1.10 +21 -25 sys/i386/isa/clock.c From owner-freebsd-smp Wed Nov 20 13:57:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13323 for smp-outgoing; Wed, 20 Nov 1996 13:57:36 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13316 for freebsd-smp; Wed, 20 Nov 1996 13:57:34 -0800 (PST) Date: Wed, 20 Nov 1996 13:57:34 -0800 (PST) From: Peter Wemm Message-Id: <199611202157.NAA13316@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa sio.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:57:32 Modified: i386/isa sio.c Log: merge -current ($Id$ spam) Revision Changes Path 1.10 +30 -21 sys/i386/isa/sio.c From owner-freebsd-smp Wed Nov 20 13:58:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13397 for smp-outgoing; Wed, 20 Nov 1996 13:58:47 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13390 for freebsd-smp; Wed, 20 Nov 1996 13:58:45 -0800 (PST) Date: Wed, 20 Nov 1996 13:58:45 -0800 (PST) From: Peter Wemm Message-Id: <199611202158.NAA13390@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa pcibus.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 13:58:44 Modified: i386/isa pcibus.c Log: merge -current Revision Changes Path 1.5 +5 -1 sys/i386/isa/pcibus.c From owner-freebsd-smp Wed Nov 20 14:05:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13678 for smp-outgoing; Wed, 20 Nov 1996 14:05:18 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13668 for freebsd-smp; Wed, 20 Nov 1996 14:05:14 -0800 (PST) Date: Wed, 20 Nov 1996 14:05:14 -0800 (PST) From: Peter Wemm Message-Id: <199611202205.OAA13668@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 14:05:11 Modified: i386/isa vector.s Log: merge -current (note, this file is seriously out of sync with -current.. It'll be lucky if it works) Revision Changes Path 1.22 +19 -4 sys/i386/isa/vector.s From owner-freebsd-smp Wed Nov 20 14:07:02 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13752 for smp-outgoing; Wed, 20 Nov 1996 14:07:02 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13744 for ; Wed, 20 Nov 1996 14:06:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA27179; Wed, 20 Nov 1996 15:05:38 -0700 Message-Id: <199611202205.PAA27179@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Thu, 21 Nov 1996 05:35:30 +0800." <199611202135.FAA13316@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 15:05:38 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >bit registers on a per-cpu basis, ie: cpu 2 cannot see what's masked in >cpu 1's registers (without an APIC remote read) and so on. beware, the P6 dropped the "Remote Read" delivery mode... --- >- we need to be able to have the 8259's online for some (current) hardware. I have an experimental model working where I am using ExtINT mode on APIC INT0 to read the 8254 timer via the 8259. Using the 8259 to pass a vector for ONE INT source turns out to be rather painless, handling more than 1 INT via the 8259 would be ugly, you have to start managing the masks & etc. in the 8259. But I also realized that there is a more fundimental problem. The 'low priority' and 'ExtInt' delivery modes are mutually exclusive! This means that INTs deliveried via the 8259/ExtInt CANNOT be sent by the 'low priority' delivery mode. They either go to a specific CPU or they can be "broadcast" (I think) to all CPUs. This might be OK for the 8259 timer INT, but more general INTs would be "cumbersome" in this mode. --- >I personally think that the right "temporary" solution for the edge >trigger problem is to never disable the IO apic pin (for edge only), and >simply wear the cost of the relatively rare occasions when the interrupts >*do* interrupt their own handlers. what is this cost, panic or corruption? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 20 14:07:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13818 for smp-outgoing; Wed, 20 Nov 1996 14:07:31 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13808 for freebsd-smp; Wed, 20 Nov 1996 14:07:28 -0800 (PST) Date: Wed, 20 Nov 1996 14:07:28 -0800 (PST) From: Peter Wemm Message-Id: <199611202207.OAA13808@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa icu.s if_ed.c isa.c npx.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 14:07:26 Modified: i386/isa icu.s if_ed.c isa.c npx.c Log: merge -current (most of the by hand stuff here was $Id$ spam) Revision Changes Path 1.15 +5 -1 sys/i386/isa/icu.s 1.3 +84 -101 sys/i386/isa/if_ed.c 1.8 +2 -3 sys/i386/isa/isa.c 1.11 +49 -13 sys/i386/isa/npx.c From owner-freebsd-smp Wed Nov 20 14:16:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15858 for smp-outgoing; Wed, 20 Nov 1996 14:16:23 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA15783 for ; Wed, 20 Nov 1996 14:16:14 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id GAA13894; Thu, 21 Nov 1996 06:15:34 +0800 (WST) Message-Id: <199611202215.GAA13894@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Wed, 20 Nov 1996 15:05:38 MST." <199611202205.PAA27179@clem.systemsix.com> Date: Thu, 21 Nov 1996 06:15:33 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > >bit registers on a per-cpu basis, ie: cpu 2 cannot see what's masked in > >cpu 1's registers (without an APIC remote read) and so on. > > beware, the P6 dropped the "Remote Read" delivery mode... Ahh, ok.. > --- > >- we need to be able to have the 8259's online for some (current) hardware. > > I have an experimental model working where I am using ExtINT mode on APIC > INT0 to read the 8254 timer via the 8259. Using the 8259 to pass a vector > for ONE INT source turns out to be rather painless, handling more than 1 > INT via the 8259 would be ugly, you have to start managing the masks & etc. > in the 8259. But I also realized that there is a more fundimental problem. > The 'low priority' and 'ExtInt' delivery modes are mutually exclusive! > This means that INTs deliveried via the 8259/ExtInt CANNOT be sent by > the 'low priority' delivery mode. They either go to a specific CPU > or they can be "broadcast" (I think) to all CPUs. This might be OK > for the 8259 timer INT, but more general INTs would be "cumbersome" > in this mode. Hmm, there are three ints that the docs mention from memory, aren't there? I think it was IRQ0(timer), IRQ8(rtc) and IRQ13(dma chaining/FPU). IRQ 8 is 'essential' (it drives process resource usage and profiling). We don't care about IRQ13 from memory. > --- > >I personally think that the right "temporary" solution for the edge > >trigger problem is to never disable the IO apic pin (for edge only), and > >simply wear the cost of the relatively rare occasions when the interrupts > >*do* interrupt their own handlers. > > what is this cost, panic or corruption? Neither.. Just have the interrupt serviced.. It or's it's bit in _ipending and returns since it's masked. If you have multiple interrupts during the handler execution, the effect is that the bit is set multiple times. Bruce profiled this and found that this was "insignificant" from memory (it happens something like the order of a fraction of a percent of cases). That way, we simply don't loose the edge interrupt, since we will see that another one arrived. (of course, this depends on exactly when the bit in _ipending is cleared) Cheers, -Peter From owner-freebsd-smp Wed Nov 20 14:28:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17989 for smp-outgoing; Wed, 20 Nov 1996 14:28:28 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17979 for freebsd-smp; Wed, 20 Nov 1996 14:28:24 -0800 (PST) Date: Wed, 20 Nov 1996 14:28:24 -0800 (PST) From: Peter Wemm Message-Id: <199611202228.OAA17979@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 machdep.c microtime.s pmap.c support.s swtch.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 14:28:22 Modified: i386/i386 machdep.c microtime.s pmap.c support.s swtch.s Log: merge -current *warning* there is some very broken stuff in here still.. Revision Changes Path 1.28 +27 -20 sys/i386/i386/machdep.c 1.14 +2 -2 sys/i386/i386/microtime.s 1.28 +329 -168 sys/i386/i386/pmap.c 1.13 +408 -99 sys/i386/i386/support.s 1.26 +16 -12 sys/i386/i386/swtch.s From owner-freebsd-smp Wed Nov 20 14:36:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18415 for smp-outgoing; Wed, 20 Nov 1996 14:36:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA18410 for ; Wed, 20 Nov 1996 14:36:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA27430; Wed, 20 Nov 1996 15:35:26 -0700 Message-Id: <199611202235.PAA27430@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: cbrown@aracnet.com, Barney Wolff , freebsd-smp@freebsd.org Subject: Re: reinventing vs copying In-reply-to: Your message of "Thu, 21 Nov 1996 06:15:33 +0800." <199611202215.GAA13894@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 15:35:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >Hmm, there are three ints that the docs mention from memory, aren't there? > I think it was IRQ0(timer), IRQ8(rtc) and IRQ13(dma chaining/FPU). IRQ 8 >is 'essential' (it drives process resource usage and profiling). We don't >care about IRQ13 from memory. no, only 2, IRQ0 and IRQ13. IRQ8 originates on the RTC chip, and thus is not localized to the same piece of silicon as are 0/13. I agree about IRQ13, only need would be by NON-busmaster EISA cards that use the EISA DMA chaining INT (ie INT13). So I guess it means my latest hack that supports this should be cleaned up and committed after you finish the merge, at least as a documented TEST in smptests.h To use it we would then need to define the final hardclock INT to either: 1: be sent to the boot CPU, which does the global work, and sends IPIs to all APs to let them do their per-CPU hardtick work. 2: be sent to all CPUs (ie broadcast), each of which does their per-CPU work, and the boot CPU realizes it also needs to do the global work. It would be nice if the same hardclock INT code be used reguardless of whether it comes via IRQ2 or via the 8259/IRQ0. If however, we find that the IRQ2 (most common) case has to be compromised to support the other, we could write 2 versions and plug in the address in the already existing re-direction variable. --- >Neither.. Just have the interrupt serviced.. It or's it's bit in >_ipending and returns since it's masked. If you have multiple interrupts >during the handler execution, the effect is that the bit is set multiple >times. Bruce profiled this and found that this was "insignificant" from >memory (it happens something like the order of a fraction of a percent of >cases). > >That way, we simply don't loose the edge interrupt, since we will see that >another one arrived. (of course, this depends on exactly when the bit in >_ipending is cleared) I need to really read Bruce's changes that I incorporated into vector/icu to see if this is what we are already getting... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 20 14:57:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA19397 for smp-outgoing; Wed, 20 Nov 1996 14:57:22 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA19389 for freebsd-smp; Wed, 20 Nov 1996 14:57:20 -0800 (PST) Date: Wed, 20 Nov 1996 14:57:20 -0800 (PST) From: Peter Wemm Message-Id: <199611202257.OAA19389@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mpapic.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 14:57:19 Modified: i386/i386 mpapic.c Log: check in the EISA hackery that is closest to working so far.. Revision Changes Path 1.19 +65 -29 sys/i386/i386/mpapic.c From owner-freebsd-smp Wed Nov 20 15:20:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20661 for smp-outgoing; Wed, 20 Nov 1996 15:20:33 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20639 for freebsd-smp; Wed, 20 Nov 1996 15:20:24 -0800 (PST) Date: Wed, 20 Nov 1996 15:20:24 -0800 (PST) From: Peter Wemm Message-Id: <199611202320.PAA20639@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/gnu/isdn if_ii.c iispy.c iitel.c iitty.c isdn.c isdn_ioctl.h sys/sys devconf.h sys/gnu/i386/isa nic3008.c nic3008.h nic3009.c nic3009.h niccyreg.h sys/i386/i386 dkbad.c ns_cksum.c serial.s sys/i386/include devconf.h laptops.h sys/i386/isa kbd.h sys/i386/isa/sound pas.h sb.h sys/kern kern_devconf.c sys/pci if_vx.c if_vxreg.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 15:20:18 Removed: gnu/i386/isa nic3008.c nic3008.h nic3009.c nic3009.h niccyreg.h gnu/isdn if_ii.c iispy.c iitel.c iitty.c isdn.c isdn_ioctl.h i386/i386 dkbad.c ns_cksum.c serial.s i386/include devconf.h laptops.h i386/isa kbd.h i386/isa/sound pas.h sb.h kern kern_devconf.c pci if_vx.c if_vxreg.h sys devconf.h Log: Remove defunct files no longer in -current From owner-freebsd-smp Wed Nov 20 18:35:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA28182 for smp-outgoing; Wed, 20 Nov 1996 18:35:31 -0800 (PST) Received: from mail001.mediacity.com (mail001.mediacity.com [206.24.105.68]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA28177 for ; Wed, 20 Nov 1996 18:35:29 -0800 (PST) From: brian@mediacity.com Received: (qmail-queue invoked from smtpd); 21 Nov 1996 02:35:16 -0000 Received: from home001.mediacity.com (HELO mediacity.com) (206.24.105.66) by mail001.mediacity.com with SMTP; 21 Nov 1996 02:35:16 -0000 Received: (qmail-queue invoked by uid 100); 21 Nov 1996 02:35:03 -0000 Message-ID: <19961121023503.8795.qmail@mediacity.com> Subject: I'm about to try dual pentium, any words of wisdom? To: freebsd-smp@freebsd.org Date: Wed, 20 Nov 1996 18:35:03 -0800 (PST) Reply-To: brian@mediacity.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I will soon have an ASUS DUAL Pentium Pro motherboard in my posession, with 512K cache per processor and 256MB of memory. I'd like to get FreeBSD up and running on this platform. Any advice on how to proceed would be appreciated. Thanks, -- Brian Litzinger Powered by FreeBSD http[s]://www.mpress.com From owner-freebsd-smp Wed Nov 20 18:48:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29285 for smp-outgoing; Wed, 20 Nov 1996 18:48:01 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA29273 for ; Wed, 20 Nov 1996 18:47:54 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id VAA02697; Wed, 20 Nov 1996 21:47:15 -0500 (EST) From: "John S. Dyson" Message-Id: <199611210247.VAA02697@dyson.iquest.net> Subject: Re: vm_page_alloc(ZERO): missing pages... To: smp@csn.net (Steve Passe) Date: Wed, 20 Nov 1996 21:47:14 -0500 (EST) Cc: ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com, freebsd-smp@freebsd.org In-Reply-To: <199611202110.OAA26815@clem.systemsix.com> from "Steve Passe" at Nov 20, 96 02:10:21 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > if it happens with only 1 processor running I would think it rules out the tlb > theory... > Is the SMP code totally sync'ed with -current? There was a severe problem in earlier versions (and could have manifest the problem that you describe.) vm_page.c had the problem. John From owner-freebsd-smp Wed Nov 20 18:52:51 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29736 for smp-outgoing; Wed, 20 Nov 1996 18:52:51 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA29729 for ; Wed, 20 Nov 1996 18:52:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA28744; Wed, 20 Nov 1996 19:52:19 -0700 Message-Id: <199611210252.TAA28744@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "John S. Dyson" cc: ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 21:47:14 EST." <199611210247.VAA02697@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 19:52:18 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >> if it happens with only 1 processor running I would think it rules out the tlb >> theory... >> >Is the SMP code totally sync'ed with -current? There was a severe problem >in earlier versions (and could have manifest the problem that you >describe.) vm_page.c had the problem. Peter is working on it now. FYI, there was a circular route hosing access to/from freefall for many of us the last few hours, so commit messages might have gotten lost for some of you. Access seems to be OK now. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 20 18:57:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29920 for smp-outgoing; Wed, 20 Nov 1996 18:57:10 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA29907 for ; Wed, 20 Nov 1996 18:57:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA28780; Wed, 20 Nov 1996 19:56:49 -0700 Message-Id: <199611210256.TAA28780@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: brian@mediacity.com cc: freebsd-smp@FreeBSD.org Subject: Re: I'm about to try dual pentium, any words of wisdom? In-reply-to: Your message of "Wed, 20 Nov 1996 18:35:03 PST." <19961121023503.8795.qmail@mediacity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 19:56:49 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, start in: http://www.freebsd.org/~fsmp/SMP/SMP.html Please keep notes of whats unclear in "getting started" and return to me so that I can improve on it! --- Note: Peter is currently merging SMP with current so this is a bad time to grab the source. This list and the web page will keep everyone informed of the progress. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 20 19:22:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01287 for smp-outgoing; Wed, 20 Nov 1996 19:22:21 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01282 for ; Wed, 20 Nov 1996 19:21:56 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id LAA19697; Thu, 21 Nov 1996 11:21:11 +0800 (WST) Message-Id: <199611210321.LAA19697@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: "John S. Dyson" cc: smp@csn.net (Steve Passe), ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of "Wed, 20 Nov 1996 21:47:14 EST." <199611210247.VAA02697@dyson.iquest.net> Date: Thu, 21 Nov 1996 11:21:10 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > > > if it happens with only 1 processor running I would think it rules out the tlb > > theory... > > > Is the SMP code totally sync'ed with -current? There was a severe problem > in earlier versions (and could have manifest the problem that you > describe.) vm_page.c had the problem. > > John I agree - it is looking much more like the VM problem.. The smp code has not recently been sync'ed with -current (like: 6-8 weeks ago), I'm in the middle of that right at the moment.. Cheers, -Peter From owner-freebsd-smp Wed Nov 20 19:37:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01899 for smp-outgoing; Wed, 20 Nov 1996 19:37:10 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01891 for ; Wed, 20 Nov 1996 19:37:01 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id WAA02859; Wed, 20 Nov 1996 22:36:12 -0500 (EST) From: "John S. Dyson" Message-Id: <199611210336.WAA02859@dyson.iquest.net> Subject: Re: vm_page_alloc(ZERO): missing pages... To: peter@spinner.dialix.com (Peter Wemm) Date: Wed, 20 Nov 1996 22:36:11 -0500 (EST) Cc: smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org In-Reply-To: <199611210321.LAA19697@spinner.DIALix.COM> from "Peter Wemm" at Nov 21, 96 11:21:10 am Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > "John S. Dyson" wrote: > > > > > > if it happens with only 1 processor running I would think it rules out the > tlb > > > theory... > > > > > Is the SMP code totally sync'ed with -current? There was a severe problem > > in earlier versions (and could have manifest the problem that you > > describe.) vm_page.c had the problem. > > > > John > > I agree - it is looking much more like the VM problem.. The smp code has > not recently been sync'ed with -current (like: 6-8 weeks ago), I'm in the > middle of that right at the moment.. > BTW, I now have an SMP capable P6 MB (SuperMicro P6DNF) with only one processor (so far.) I do have some filesystem, etc agendas in the offing, but hope (soon) to be able to help/test the SMP code. I know that my efforts are best spent where I am most knowledgable, but do want to sync up and help with the fine grained effort (whatever that might be) in the future. (I certainly am not expert in SMP enough to architect the SMP code -- you all seem to be doing really well, but am willing to help (participate) in implementation of you all's good ideas :-)). John From owner-freebsd-smp Wed Nov 20 20:04:19 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA02732 for smp-outgoing; Wed, 20 Nov 1996 20:04:19 -0800 (PST) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA02719; Wed, 20 Nov 1996 20:04:11 -0800 (PST) Received: from thurston.eng.umd.edu (thurston.eng.umd.edu [129.2.103.25]) by po2.glue.umd.edu (8.8.2/8.7.3) with ESMTP id XAA00901; Wed, 20 Nov 1996 23:04:06 -0500 (EST) Received: from localhost (chuckr@localhost) by thurston.eng.umd.edu (8.8.3/8.7.3) with SMTP id XAA04901; Wed, 20 Nov 1996 23:04:05 -0500 (EST) X-Authentication-Warning: thurston.eng.umd.edu: chuckr owned process doing -bs Date: Wed, 20 Nov 1996 23:04:05 -0500 (EST) From: Chuck Robey X-Sender: chuckr@thurston.eng.umd.edu To: dyson@freebsd.org cc: Peter Wemm , smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-Reply-To: <199611210336.WAA02859@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 20 Nov 1996, John S. Dyson wrote: > BTW, I now have an SMP capable P6 MB (SuperMicro P6DNF) with only one > processor (so far.) I do have some filesystem, etc agendas in the offing, > but hope (soon) to be able to help/test the SMP code. I know that my efforts > are best spent where I am most knowledgable, but do want to sync up and > help with the fine grained effort (whatever that might be) in the future. > (I certainly am not expert in SMP enough to architect the SMP code -- you > all seem to be doing really well, but am willing to help (participate) in > implementation of you all's good ideas :-)). John If you get the SuperMicro running smp, I'd like to know. The only reason I didn't buy that board was because Michael Van Loon reported trouble trying to get it to run smp. It has an on-board scsi controller which I REALLY liked, but I couldn't take a chance with that much cash. If it does work, I think it''s only be fair to tell folks, because it's an excellent choice if it works. (price right, features right, right chipset too.) ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Wed Nov 20 20:16:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03562 for smp-outgoing; Wed, 20 Nov 1996 20:16:11 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03553 for freebsd-smp; Wed, 20 Nov 1996 20:16:07 -0800 (PST) Date: Wed, 20 Nov 1996 20:16:07 -0800 (PST) From: Peter Wemm Message-Id: <199611210416.UAA03553@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/boot/biosboot asm.h sys/net rtsock.c sys/sys kernel.h proc.h sys/ufs/ufs ufs_inode.c sys/ddb db_trap.c sys/i386/i386 autoconf.c machdep.c pmap.c support.s sys/i386/include ipl.h pcb.h segments.h sys/i386/isa icu.h icu.s if_ed.c if_ze.c isa_device.h npx.c pcibus.c sio.c sys/kern init_main.c subr_prf.c sys/pci pci.c pcibus.h sys/scsi scsi_ioctl.c sd.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/20 20:16:03 Modified: ddb db_trap.c i386/boot/biosboot asm.h i386/i386 autoconf.c machdep.c pmap.c support.s i386/include ipl.h pcb.h segments.h i386/isa icu.h icu.s if_ed.c if_ze.c isa_device.h npx.c pcibus.c sio.c kern init_main.c subr_prf.c net rtsock.c pci pci.c pcibus.h scsi scsi_ioctl.c sd.c sys kernel.h proc.h ufs/ufs ufs_inode.c Log: Attempt to minimise unnecessary differences with -current (eg: whitespace, add/remove blank lines, defunct code, etc) to try and make future merges go a bit easier. It compiles now, but icu.s and vector.s has some unresolved merge problems. (ie: there have been changes in -current which are applicable to all three (or four?) sets of duplicated INTR macros, but the merge only did one of them, and probably the wrong one. Steve needs to look more closely at the effects of this) Revision Changes Path 1.3 +0 -1 sys/ddb/db_trap.c 1.4 +39 -0 sys/i386/boot/biosboot/asm.h 1.8 +5 -0 sys/i386/i386/autoconf.c 1.29 +49 -50 sys/i386/i386/machdep.c 1.29 +2 -2 sys/i386/i386/pmap.c 1.14 +21 -21 sys/i386/i386/support.s 1.5 +1 -2 sys/i386/include/ipl.h 1.10 +2 -3 sys/i386/include/pcb.h 1.4 +1 -1 sys/i386/include/segments.h 1.7 +1 -1 sys/i386/isa/icu.h 1.16 +7 -1 sys/i386/isa/icu.s 1.4 +0 -4 sys/i386/isa/if_ed.c 1.6 +1 -1 sys/i386/isa/if_ze.c 1.5 +1 -2 sys/i386/isa/isa_device.h 1.12 +2 -1 sys/i386/isa/npx.c 1.6 +0 -1 sys/i386/isa/pcibus.c 1.11 +1 -1 sys/i386/isa/sio.c 1.31 +0 -33 sys/kern/init_main.c 1.9 +0 -2 sys/kern/subr_prf.c 1.4 +1 -3 sys/net/rtsock.c 1.6 +0 -2 sys/pci/pci.c 1.5 +1 -2 sys/pci/pcibus.h 1.4 +0 -2 sys/scsi/scsi_ioctl.c 1.8 +0 -1 sys/scsi/sd.c 1.12 +1 -1 sys/sys/kernel.h 1.16 +2 -4 sys/sys/proc.h 1.3 +0 -4 sys/ufs/ufs/ufs_inode.c From owner-freebsd-smp Wed Nov 20 20:16:51 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03578 for smp-outgoing; Wed, 20 Nov 1996 20:16:51 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA03573; Wed, 20 Nov 1996 20:16:42 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id XAA03079; Wed, 20 Nov 1996 23:16:06 -0500 (EST) From: "John S. Dyson" Message-Id: <199611210416.XAA03079@dyson.iquest.net> Subject: Re: vm_page_alloc(ZERO): missing pages... To: chuckr@Glue.umd.edu (Chuck Robey) Date: Wed, 20 Nov 1996 23:16:06 -0500 (EST) Cc: dyson@freebsd.org, peter@spinner.dialix.com, smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org In-Reply-To: from "Chuck Robey" at Nov 20, 96 11:04:05 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > If you get the SuperMicro running smp, I'd like to know. The only reason > I didn't buy that board was because Michael Van Loon reported trouble > trying to get it to run smp. It has an on-board scsi controller which I > REALLY liked, but I couldn't take a chance with that much cash. If it > does work, I think it''s only be fair to tell folks, because it's an > excellent choice if it works. (price right, features right, right chipset > too.) > My P6DNF doesn't have a scsi adaptor on board, or even a scsi bios. Sounds like you are talking about Micronics or AIR? John From owner-freebsd-smp Wed Nov 20 20:31:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA04134 for smp-outgoing; Wed, 20 Nov 1996 20:31:31 -0800 (PST) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA04127; Wed, 20 Nov 1996 20:31:15 -0800 (PST) Received: from thurston.eng.umd.edu (thurston.eng.umd.edu [129.2.103.25]) by po1.glue.umd.edu (8.8.2/8.7.3) with ESMTP id XAA04365; Wed, 20 Nov 1996 23:31:10 -0500 (EST) Received: from localhost (chuckr@localhost) by thurston.eng.umd.edu (8.8.3/8.7.3) with SMTP id XAA07811; Wed, 20 Nov 1996 23:31:09 -0500 (EST) X-Authentication-Warning: thurston.eng.umd.edu: chuckr owned process doing -bs Date: Wed, 20 Nov 1996 23:31:08 -0500 (EST) From: Chuck Robey X-Sender: chuckr@thurston.eng.umd.edu To: "John S. Dyson" cc: dyson@freebsd.org, peter@spinner.dialix.com, smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-Reply-To: <199611210416.XAA03079@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 20 Nov 1996, John S. Dyson wrote: > > > > If you get the SuperMicro running smp, I'd like to know. The only reason > > I didn't buy that board was because Michael Van Loon reported trouble > > trying to get it to run smp. It has an on-board scsi controller which I > > REALLY liked, but I couldn't take a chance with that much cash. If it > > does work, I think it''s only be fair to tell folks, because it's an > > excellent choice if it works. (price right, features right, right chipset > > too.) > > > My P6DNF doesn't have a scsi adaptor on board, or even a scsi bios. Sounds > like you are talking about Micronics or AIR? Darn, I must have gotten it confused with another, I thought the SuperMicro was the one with the SCSI. Sorry, I guess. Michael did report what I said, but I must have thought for some reason it had a scsi interface. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Wed Nov 20 20:43:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA04558 for smp-outgoing; Wed, 20 Nov 1996 20:43:32 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA04552; Wed, 20 Nov 1996 20:43:24 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id XAA03187; Wed, 20 Nov 1996 23:43:18 -0500 (EST) From: "John S. Dyson" Message-Id: <199611210443.XAA03187@dyson.iquest.net> Subject: Re: vm_page_alloc(ZERO): missing pages... To: chuckr@Glue.umd.edu (Chuck Robey) Date: Wed, 20 Nov 1996 23:43:18 -0500 (EST) Cc: toor@dyson.iquest.net, dyson@freebsd.org, peter@spinner.dialix.com, smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org In-Reply-To: from "Chuck Robey" at Nov 20, 96 11:31:08 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Wed, 20 Nov 1996, John S. Dyson wrote: > > > > > > > If you get the SuperMicro running smp, I'd like to know. The only reason > > > I didn't buy that board was because Michael Van Loon reported trouble > > > trying to get it to run smp. It has an on-board scsi controller which I > > > REALLY liked, but I couldn't take a chance with that much cash. If it > > > does work, I think it''s only be fair to tell folks, because it's an > > > excellent choice if it works. (price right, features right, right chipset > > > too.) > > > > > My P6DNF doesn't have a scsi adaptor on board, or even a scsi bios. Sounds > > like you are talking about Micronics or AIR? > > Darn, I must have gotten it confused with another, I thought the > SuperMicro was the one with the SCSI. Sorry, I guess. Michael did report > what I said, but I must have thought for some reason it had a scsi > interface. > Oh, well -- it is supposed to work really well on NT (per various anecdotal evidence)... I assume that Michael VanLoon had problems with NT on his board? John From owner-freebsd-smp Wed Nov 20 20:53:54 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA05009 for smp-outgoing; Wed, 20 Nov 1996 20:53:54 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA04996; Wed, 20 Nov 1996 20:53:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA29522; Wed, 20 Nov 1996 21:53:28 -0700 Message-Id: <199611210453.VAA29522@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/i386/boot/biosboot asm.h sys/net rtsock.c sys/sys kernel.h proc.h sys/ufs/ufs ufs_inode.c sys/ddb db_trap.c sys/i386/i386 autoconf.c machdep.c pmap.c support.s sys/i386/include ipl.h pcb.h segments.h sys/i386/isa icu.h icu.s if_ed.c if_ze.c isa_device.h npx.c pcibus.c sio.c sys/kern init_main.c subr_prf.c sys/pci pci.c pcibus.h sys/scsi scsi_ioctl.c sd.c In-reply-to: Your message of "Wed, 20 Nov 1996 20:16:07 PST." <199611210416.UAA03553@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 21:53:28 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > It compiles now, but icu.s and vector.s has some unresolved merge problems. > (ie: there have been changes in -current which are applicable to all three > (or four?) sets of duplicated INTR macros, but the merge only did one of > them, and probably the wrong one. Steve needs to look more closely at > the effects of this) I'm on it... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 20 21:46:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06850 for smp-outgoing; Wed, 20 Nov 1996 21:46:31 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA06840 for ; Wed, 20 Nov 1996 21:46:28 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id XAA26029 for ; Wed, 20 Nov 1996 23:46:26 -0600 (CST) Message-Id: <199611210546.XAA26029@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-smp@freebsd.org Subject: netns for current merge? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 1996 23:46:26 -0600 From: Chris Csanady Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have tried to build the 11/20 source and notice it dies in libc, trying to include netns/ns.h and such. Are there plans to add this back into the smp source as well? Just thought I'd point it out.. --Chris Csanady From owner-freebsd-smp Thu Nov 21 00:55:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA13184 for smp-outgoing; Thu, 21 Nov 1996 00:55:06 -0800 (PST) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA13177; Thu, 21 Nov 1996 00:55:02 -0800 (PST) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id AAA00474; Thu, 21 Nov 1996 00:55:04 -0800 (PST) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id AAA04380; Thu, 21 Nov 1996 00:54:47 -0800 (PST) Message-Id: <199611210854.AAA04380@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: "John S. Dyson" cc: chuckr@Glue.umd.edu (Chuck Robey), dyson@freebsd.org, peter@spinner.dialix.com, smp@csn.net, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... In-reply-to: Your message of Wed, 20 Nov 96 23:43:18 -0500. <199611210443.XAA03187@dyson.iquest.net> Date: Thu, 21 Nov 1996 00:54:47 -0800 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > > If you get the SuperMicro running smp, I'd like to know. The only reason >> > > I didn't buy that board was because Michael Van Loon reported trouble >> > > trying to get it to run smp. It has an on-board scsi controller which I >> > > REALLY liked, but I couldn't take a chance with that much cash. If it >> > > does work, I think it''s only be fair to tell folks, because it's an >> > > excellent choice if it works. (price right, features right, right chipset >> > > too.) >> > My P6DNF doesn't have a scsi adaptor on board, or even a scsi bios. Sounds >> > like you are talking about Micronics or AIR? >> Darn, I must have gotten it confused with another, I thought the >> SuperMicro was the one with the SCSI. Sorry, I guess. Michael did report >> what I said, but I must have thought for some reason it had a scsi >> interface. >Oh, well -- it is supposed to work really well on NT (per various anecdotal >evidence)... I assume that Michael VanLoon had problems with NT on his board? Actually, I didn't have problems with SMP -- I had problems with *everything*. Basically, the thing wouldn't run anything but DOS without crashing badly. A replacement board worked just as badly. They sent me a single-CPU Asus (P6NP5) the third time, and it have been working beautifully ever since (running NetBSD for the first 72 hours, running benchmarks, make worlds, etc. the entire time), and NT and Descent II ever since. :-) Other people told me they had SuperMicro P6DNF and P6SNF boards working with *BSD. I had to conclude from this (and from other people with other reports about SuperMicro) that their quality control must just suck. If you get a good board, it will probably be a good board as long as you own it. However, I obviously got two bad boards in a row. For the record, it was a P6DNF with one 200MHz CPU. This board does not contain an on-board SCSI controller. It is a full-size board with eight full slots (not shared), four PCI, and has eight SIMM sockets. Unfortunately, the Asus doesn't have all the gee-whiz features of the SuperMicro. But, I'm still quite happy with it -- it has been as absolutely rock solid as I have come to expect from Asus. For what it's worth, I also determined that you should avoid doing business with Aberdeen. They are nice, friendly people, and they really seem to be well-meaning. But, it took them more then two weeks, with repeated phone calls, to get a replacement board back from them through RMA (both times). So, Aberdeen is probably nice if you buy something that works the first time and never breaks. But beware that their RMA department is a black hole. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-smp Thu Nov 21 03:07:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA17912 for smp-outgoing; Thu, 21 Nov 1996 03:07:23 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA17900 for ; Thu, 21 Nov 1996 03:06:15 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id MAA00719; Thu, 21 Nov 1996 12:00:39 +0100 Received: by donau.informatik.uni-rostock.de id MAA23833; Thu, 21 Nov 1996 12:00:37 +0100 (MET) Date: Thu, 21 Nov 1996 12:00:37 +0100 (MET) From: Gunther Hipper Message-Id: <199611211100.MAA23833@donau.informatik.uni-rostock.de> To: freebsd-smp@FreeBSD.org Subject: A Problem: ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') X-Sun-Charset: US-ASCII Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi all ! First - the installation manual in http://www.freebsd.org/~fsmp/SMP/SMP.html is okay. The only thing i wonder is the second passage about the latest snapshot. Why do you have to get the latest snapshot ? The source tree is after the cvsup/cvs checkout in the /usr/src/sys - so is it for the latest user-binaries ? Now my problem: cc -c -x assembler-with-cpp -DLOCORE -nostdinc -I- -I. -I../.. -I../../../include -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL ../../i386/i386/locore.s ../../i386/i386/locore.s: Assembler messages ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') ../../i386/i386/locore.s:707: Error: bad register name ('%cr4') *** Error code 1 Stop. I really do not know what to do ... it was the first time i cvssupped - so maybe it's this ? Or is it an inlcude-file problem ? Please, give ma a hint and bye Gunther Gunther Hipper | University of Rostock | Department of Computer Science | Tel +49 381 498 3391 Albert-Einstein-Str. 21 | Fax +49 381 498 3440 18051 Rostock - Germany | Email Gunther.Hipper@informatik.uni-rostock.de From owner-freebsd-smp Thu Nov 21 04:40:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA21585 for smp-outgoing; Thu, 21 Nov 1996 04:40:28 -0800 (PST) Received: from netwolf.NetMasters.com (netwolf.netmasters.com [199.201.245.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA21580 for ; Thu, 21 Nov 1996 04:40:25 -0800 (PST) Received: from netwolf.NetMasters.com (localhost [127.0.0.1]) by netwolf.NetMasters.com (8.7.6/8.7.3) with ESMTP id HAA02669; Thu, 21 Nov 1996 07:40:03 -0500 (EST) Message-Id: <199611211240.HAA02669@netwolf.NetMasters.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Gunther Hipper cc: freebsd-smp@FreeBSD.org Subject: Re: A Problem: ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') In-reply-to: Your message of "Thu, 21 Nov 1996 12:00:37 +0100." <199611211100.MAA23833@donau.informatik.uni-rostock.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 07:40:03 -0500 From: Michael Petry Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I ran into the same issue and was able to resolve it by building a new /usr/src/gnu/usr.bin/as from the -current. It appears that this was the first use of %cr4 in any of the .s modules and the assembler from previous versions didn't know about the definition. From owner-freebsd-smp Thu Nov 21 08:05:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00432 for smp-outgoing; Thu, 21 Nov 1996 08:05:14 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA00425 for ; Thu, 21 Nov 1996 08:05:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id IAA02760; Thu, 21 Nov 1996 08:58:36 -0700 Message-Id: <199611211558.IAA02760@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Gunther Hipper cc: freebsd-smp@FreeBSD.org Subject: Re: A Problem: ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') In-reply-to: Your message of "Thu, 21 Nov 1996 12:00:37 +0100." <199611211100.MAA23833@donau.informatik.uni-rostock.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 08:58:36 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > First - the installation manual in http://www.freebsd.org/~fsmp/SMP/SMP.html > is okay. The only thing i wonder is the second passage about the latest > snapshot. Why do you have to get the latest snapshot ? The source tree is > after the cvsup/cvs checkout in the /usr/src/sys - so is it for the latest > user-binaries ? various reasons of compatibility --- > Now my problem: > cc -c -x assembler-with-cpp -DLOCORE -nostdinc -I- -I. -I../.. -I../../../include -DFAILSAFE -DCOMPAT_43 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL ../../i386/i386/locore.s > ../../i386/i386/locore.s: Assembler messages > ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') > ../../i386/i386/locore.s:707: Error: bad register name ('%cr4') > *** Error code 1 this is a good example of one of those reasons. I believe what is happening here is that the assembler has been upgraded, and the one you are currently using doesn't know adout this instruction. I hit the same problem last nite. cvsuping with standard-supfile.cvsup, followed by a "make world" fixed it. Now I'm chasing down some problem with syscons.c referencing a fistload of undefined functions. > I really do not know what to do ... it was the first time i cvssupped - so > maybe it's this ? Or is it an inlcude-file problem ? I think you need to get you entire system up to -current and "make world". thanx for the report, -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 21 10:28:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA09761 for smp-outgoing; Thu, 21 Nov 1996 10:28:17 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA09756 for ; Thu, 21 Nov 1996 10:28:13 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA11376; Thu, 21 Nov 1996 11:28:08 -0700 (MST) Date: Thu, 21 Nov 1996 11:28:08 -0700 (MST) Message-Id: <199611211828.LAA11376@rocky.mt.sri.com> From: Nate Williams To: Steve Passe Cc: freebsd-smp@freebsd.org Subject: Re: A Problem: ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') In-Reply-To: <199611211558.IAA02760@clem.systemsix.com> References: <199611211100.MAA23833@donau.informatik.uni-rostock.de> <199611211558.IAA02760@clem.systemsix.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > fixed it. Now I'm chasing down some problem with syscons.c referencing > a fistload of undefined functions. There from i386/isa/kbdio.[ch]. I didn't notice, but did Peter update i386/conf/files.i386? If not, you'll need to add these lines to it. If so, then you'll need to re-configure your kernel. i386/isa/kbdio.c optional psm device-driver i386/isa/kbdio.c optional sc device-driver Nate From owner-freebsd-smp Thu Nov 21 10:33:54 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA09984 for smp-outgoing; Thu, 21 Nov 1996 10:33:54 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA09979 for ; Thu, 21 Nov 1996 10:33:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA03549; Thu, 21 Nov 1996 11:33:39 -0700 Message-Id: <199611211833.LAA03549@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: freebsd-smp@freebsd.org Subject: Re: A Problem: ../../i386/i386/locore.s:705: Error: bad register name ('%cr4') In-reply-to: Your message of "Thu, 21 Nov 1996 11:28:08 MST." <199611211828.LAA11376@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 11:33:38 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > fixed it. Now I'm chasing down some problem with syscons.c referencing > > a fistload of undefined functions. > > There from i386/isa/kbdio.[ch]. I didn't notice, but did Peter update > i386/conf/files.i386? If not, you'll need to add these lines to it. If > so, then you'll need to re-configure your kernel. re-configing the kernel fixed things, thanx. I can now build a LOCAL non-SMP kernel. I am almost finished dealing with vector.s and friends. Since some of Bruce's changes that address the "missing INT" problem are now in current it is getting a little cleaner. I am adding some macros to clean it up even further. It will take several hours to test non-APIC, APIC & APIC_LAZY versions... stay tuned. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Thu Nov 21 12:54:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16423 for smp-outgoing; Thu, 21 Nov 1996 12:54:00 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16416; Thu, 21 Nov 1996 12:53:59 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199611212053.MAA16416@freefall.freebsd.org> Subject: Re: vm_page_alloc(ZERO): missing pages... To: ccsanady@friley216.res.iastate.edu (Chris Csanady) Date: Thu, 21 Nov 1996 12:53:58 -0800 (PST) Cc: peter@spinner.dialix.com, smp@csn.net, freebsd-smp@freebsd.org In-Reply-To: <199611202050.OAA02373@friley216.res.iastate.edu> from "Chris Csanady" at Nov 20, 96 02:50:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > > A great deal of paging. I was running a benchmark (hint) which beats on the > memory quite hard. VM as well. Besides being a wonderful benchmark, I also > use it every now and then to try to break things. :) did you compile it to use both processors? if so, lets talk about that more off-line. please send me your results and dmesg output ;) jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-smp Thu Nov 21 13:36:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA18992 for smp-outgoing; Thu, 21 Nov 1996 13:36:53 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA18969; Thu, 21 Nov 1996 13:36:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA04559; Thu, 21 Nov 1996 14:36:41 -0700 Message-Id: <199611212136.OAA04559@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/i386/boot/biosboot asm.h sys/net rtsock.c sys/sys kernel.h proc.h sys/ufs/ufs ufs_inode.c sys/ddb db_trap.c sys/i386/i386 autoconf.c machdep.c pmap.c support.s sys/i386/include ipl.h pcb.h segments.h sys/i386/isa icu.h icu.s if_ed.c if_ze.c isa_device.h npx.c pcibus.c sio.c sys/kern init_main.c subr_prf.c sys/pci pci.c pcibus.h sys/scsi scsi_ioctl.c sd.c In-reply-to: Your message of "Wed, 20 Nov 1996 20:16:07 PST." <199611210416.UAA03553@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 14:36:40 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, so I have "make world' done, a non-SMP kernel built and working. I can build both APIC_IO and non-APIC_IO kernels. They start, show no problems, both get to point of wanting keyboard input, (i started them '-s') At this point they both lock, looks like keyboard input is hosed. If I hit numlock i get "^@^@", but no change, ie the numlock light stays lit. So the kernel appears to be catching INT1, but the sc driver seems unhappy. Any theories??? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 21 14:07:34 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20545 for smp-outgoing; Thu, 21 Nov 1996 14:07:34 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA20538; Thu, 21 Nov 1996 14:07:27 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA12263; Thu, 21 Nov 1996 15:07:18 -0700 (MST) Date: Thu, 21 Nov 1996 15:07:18 -0700 (MST) Message-Id: <199611212207.PAA12263@rocky.mt.sri.com> From: Nate Williams To: Steve Passe Cc: Peter Wemm , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-Reply-To: <199611212136.OAA04559@clem.systemsix.com> References: <199611210416.UAA03553@freefall.freebsd.org> <199611212136.OAA04559@clem.systemsix.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > so I have "make world' done, a non-SMP kernel built and working. Does it work fine all the time? > I can build both APIC_IO and non-APIC_IO kernels. > They start, show no problems, both get to point of wanting keyboard input, > (i started them '-s') > At this point they both lock, looks like keyboard input is hosed. If I hit > numlock i get "^@^@", but no change, ie the numlock light stays lit. So the > kernel appears to be catching INT1, but the sc driver seems unhappy. > > Any theories??? Syscons has changed quite a bit in the last week or so to accomodate the PS/2 mouse. There are known bugs/bogosities in the code (according to Bruce), but the author's fixes cause it to not work at all on one of my test boxes, so I haven't applied the fixes to the tree. We've got to get on this pretty quick, so hopefully we'll have this resolved soon. In the meantime, if you can back out to the 1.186 version of syscons from the CVS tree I suspect all of your problems will go away. Nate From owner-freebsd-smp Thu Nov 21 14:20:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21277 for smp-outgoing; Thu, 21 Nov 1996 14:20:22 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21136; Thu, 21 Nov 1996 14:19:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA04779; Thu, 21 Nov 1996 15:18:47 -0700 Message-Id: <199611212218.PAA04779@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: Peter Wemm , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-reply-to: Your message of "Thu, 21 Nov 1996 15:07:18 MST." <199611212207.PAA12263@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 15:18:47 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > so I have "make world' done, a non-SMP kernel built and working. > > Does it work fine all the time? yes, just fine for editing in emacs, etc. > > Any theories??? > > Syscons has changed quite a bit in the last week or so to accomodate the > PS/2 mouse. There are known bugs/bogosities in the code (according to > Bruce), but the author's fixes cause it to not work at all on one of my > test boxes, so I haven't applied the fixes to the tree. > > We've got to get on this pretty quick, so hopefully we'll have this > resolved soon. > > In the meantime, if you can back out to the 1.186 version of syscons > from the CVS tree I suspect all of your problems will go away. the syscons.h/syscons.c files are identical between LOCAL and SMP kernels. I see something about lkm drivers being needed now, is that a possibility? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Thu Nov 21 14:23:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21445 for smp-outgoing; Thu, 21 Nov 1996 14:23:08 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21439 for ; Thu, 21 Nov 1996 14:22:59 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA12347; Thu, 21 Nov 1996 15:22:48 -0700 (MST) Date: Thu, 21 Nov 1996 15:22:48 -0700 (MST) Message-Id: <199611212222.PAA12347@rocky.mt.sri.com> From: Nate Williams To: Steve Passe Cc: Nate Williams , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-Reply-To: <199611212218.PAA04779@clem.systemsix.com> References: <199611212207.PAA12263@rocky.mt.sri.com> <199611212218.PAA04779@clem.systemsix.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ Keyboard lockup with SMP kernels ] > > > Any theories??? > > > > Syscons has changed quite a bit in the last week or so to accomodate the > > PS/2 mouse. There are known bugs/bogosities in the code (according to > > Bruce), but the author's fixes cause it to not work at all on one of my > > test boxes, so I haven't applied the fixes to the tree. > > > > In the meantime, if you can back out to the 1.186 version of syscons > > from the CVS tree I suspect all of your problems will go away. > > the syscons.h/syscons.c files are identical between LOCAL and SMP kernels. > I see something about lkm drivers being needed now, is that a possibility? Nope, but the existing bugs in syscons are causing similar problems to what you are seeing with normal kernels, so seeing it in the SMP kernel may be due to some timing issues. As I said above, try reverting to V1.186 of syscons.c and see if the problem goes away. Nate From owner-freebsd-smp Thu Nov 21 14:25:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21595 for smp-outgoing; Thu, 21 Nov 1996 14:25:57 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21583 for ; Thu, 21 Nov 1996 14:25:47 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA12369; Thu, 21 Nov 1996 15:25:42 -0700 (MST) Date: Thu, 21 Nov 1996 15:25:42 -0700 (MST) Message-Id: <199611212225.PAA12369@rocky.mt.sri.com> From: Nate Williams To: Nate Williams Cc: Steve Passe , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-Reply-To: <199611212222.PAA12347@rocky.mt.sri.com> References: <199611212207.PAA12263@rocky.mt.sri.com> <199611212218.PAA04779@clem.systemsix.com> <199611212222.PAA12347@rocky.mt.sri.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > As I said above, try reverting to V1.186 of syscons.c and see if the > problem goes away. I also forgot to mention, you'll also need to revert to V1.25 of i386/include/console.h as well. Nate From owner-freebsd-smp Thu Nov 21 15:00:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23833 for smp-outgoing; Thu, 21 Nov 1996 15:00:50 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA23825 for ; Thu, 21 Nov 1996 15:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA05005; Thu, 21 Nov 1996 16:00:31 -0700 Message-Id: <199611212300.QAA05005@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-reply-to: Your message of "Thu, 21 Nov 1996 15:25:42 MST." <199611212225.PAA12369@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 16:00:30 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > As I said above, try reverting to V1.186 of syscons.c and see if the > > problem goes away. > > I also forgot to mention, you'll also need to revert to V1.25 of > i386/include/console.h as well. so that lets me build & run the non APIC_IO version of the SMP kernel, but it immediately jumps off a cliff when I start the second CPU... I'll be back. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Thu Nov 21 15:03:34 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23927 for smp-outgoing; Thu, 21 Nov 1996 15:03:34 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA23920 for ; Thu, 21 Nov 1996 15:03:31 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA12606; Thu, 21 Nov 1996 16:03:18 -0700 (MST) Date: Thu, 21 Nov 1996 16:03:18 -0700 (MST) Message-Id: <199611212303.QAA12606@rocky.mt.sri.com> From: Nate Williams To: Steve Passe Cc: Nate Williams , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-Reply-To: <199611212300.QAA05005@clem.systemsix.com> References: <199611212225.PAA12369@rocky.mt.sri.com> <199611212300.QAA05005@clem.systemsix.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > Hi, > > > > As I said above, try reverting to V1.186 of syscons.c and see if the > > > problem goes away. > > > > I also forgot to mention, you'll also need to revert to V1.25 of > > i386/include/console.h as well. > > so that lets me build & run the non APIC_IO version of the SMP kernel, > but it immediately jumps off a cliff when I start the second CPU... I'll > be back. I'm assuming you're not using a PS/2 mouse, are you? Nate From owner-freebsd-smp Thu Nov 21 15:09:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24161 for smp-outgoing; Thu, 21 Nov 1996 15:09:04 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA24155 for ; Thu, 21 Nov 1996 15:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA05064; Thu, 21 Nov 1996 16:08:33 -0700 Message-Id: <199611212308.QAA05064@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: Steve Passe , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-reply-to: Your message of "Thu, 21 Nov 1996 16:03:18 MST." <199611212303.QAA12606@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 16:08:33 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > > > As I said above, try reverting to V1.186 of syscons.c and see if the > > > > problem goes away. > > > > > > I also forgot to mention, you'll also need to revert to V1.25 of > > > i386/include/console.h as well. > > > > so that lets me build & run the non APIC_IO version of the SMP kernel, > > but it immediately jumps off a cliff when I start the second CPU... I'll > > be back. > > I'm assuming you're not using a PS/2 mouse, are you? no I'm not. the mb has one built in, but I don't configure the kernel for it. and I'm getting some console wierdness on the SMP kernel built with the older files now, not sure whats up... did I need an older syscons.h? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Thu Nov 21 15:20:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24902 for smp-outgoing; Thu, 21 Nov 1996 15:20:06 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA24872 for ; Thu, 21 Nov 1996 15:20:02 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA12743; Thu, 21 Nov 1996 16:19:57 -0700 (MST) Date: Thu, 21 Nov 1996 16:19:57 -0700 (MST) Message-Id: <199611212319.QAA12743@rocky.mt.sri.com> From: Nate Williams To: Steve Passe Cc: Nate Williams , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-Reply-To: <199611212308.QAA05064@clem.systemsix.com> References: <199611212303.QAA12606@rocky.mt.sri.com> <199611212308.QAA05064@clem.systemsix.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm assuming you're not using a PS/2 mouse, are you? > > no I'm not. the mb has one built in, but I don't configure the kernel > for it. Is it disabled in HW (meaning are there possible spurious interrupts being generated on IRQ 12?) > and I'm getting some console wierdness on the SMP kernel built with the > older files now, not sure whats up... did I need an older syscons.h? Nope, that was the last 'known good working' version, but it broke PS/2 mouse support. Nate From owner-freebsd-smp Thu Nov 21 15:23:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25070 for smp-outgoing; Thu, 21 Nov 1996 15:23:04 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA25065 for ; Thu, 21 Nov 1996 15:23:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA05196; Thu, 21 Nov 1996 16:22:45 -0700 Message-Id: <199611212322.QAA05196@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: Steve Passe , freebsd-smp@freefall.freebsd.org Subject: Re: Console lockup In-reply-to: Your message of "Thu, 21 Nov 1996 16:19:57 MST." <199611212319.QAA12743@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 16:22:45 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I'm assuming you're not using a PS/2 mouse, are you? > > > > no I'm not. the mb has one built in, but I don't configure the kernel > > for it. > > Is it disabled in HW (meaning are there possible spurious interrupts > being generated on IRQ 12?) not sure, I'll check next time I reboot (or crash!). I've never seen spurious IRQ12's, so I don't think its a problem. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Thu Nov 21 16:04:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28199 for smp-outgoing; Thu, 21 Nov 1996 16:04:27 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA28192 for ; Thu, 21 Nov 1996 16:04:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA05407 for ; Thu, 21 Nov 1996 17:04:19 -0700 Message-Id: <199611220004.RAA05407@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org Subject: SMP -current merge In-reply-to: Your message of "Thu, 21 Nov 1996 16:00:30 MST." <199611212300.QAA05005@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 17:04:19 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, so far: 1: modified i386/isa/icu.s and i386/isa/vector.s to do "the good thing" tried both APIC_IO and non APIC_IO versions of merged SMP kernel, keyboard input hosed at single-usr prompt 2: reverted to i386/isa/syscons.c v1.186 reverted to i386/include/console.h v1.25 tried non APIC_IO version of merged SMP kernel, boots, starting 2nd CPU causes spontanious REBOOT 3: reverted to pre-merge icu.s and vector.s tried non APIC_IO version of merged SMP kernel, boots, starting 2nd CPU causes spontanious REBOOT conclusion: the problem is (probably) not in icu.s or vector.s something has changed in -current that is eating our shorts... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 21 17:21:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA03075 for smp-outgoing; Thu, 21 Nov 1996 17:21:18 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA03033 for ; Thu, 21 Nov 1996 17:21:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id SAA05752 for ; Thu, 21 Nov 1996 18:21:08 -0700 Message-Id: <199611220121.SAA05752@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org Subject: SMP -current merge In-reply-to: Your message of "Thu, 21 Nov 1996 16:00:30 MST." <199611212300.QAA05005@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 18:21:07 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >so far: > .. >conclusion: the problem is (probably) not in icu.s or vector.s > >something has changed in -current that is eating our shorts... I just put files1.tar.gz into freefall:/incoming this contains the older console.h and syscons.c that seem to be necessary. this contains the old vector.s and icu.s that I think are usable. So... you can cvsup the latest SMP stuff, overlay these 4 files and go crazy with me! The death seems to be when the 2nd CPU runs its 1st process. I can start it up with sysctl and have it stop at a cngetc() in secondary_main just b4 it calls 'cpu_switch(curproc)'. The system is healthy at this point. I hit return, the 2nd CPU presummably enters cpu_switch, and I get a root prompt back on the console ( "# " ). I can hit repeatedly and get another prompt. The moment I try to do anything, even a shell builtin like "echo foo", I get a reboot. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 21 17:33:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA04001 for smp-outgoing; Thu, 21 Nov 1996 17:33:52 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA03996 for ; Thu, 21 Nov 1996 17:33:50 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id TAA06109; Thu, 21 Nov 1996 19:33:42 -0600 (CST) Message-Id: <199611220133.TAA06109@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of Thu, 21 Nov 1996 18:21:07 -0700. <199611220121.SAA05752@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 19:33:42 -0600 From: Chris Csanady Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just a thought, but what about the i586 optimized stuff? It is now default, and I believe its all included even in the SMP case. How about trying the old npx stuff? --Chris Csanady >Hi, > >>so far: >> .. >>conclusion: the problem is (probably) not in icu.s or vector.s >> >>something has changed in -current that is eating our shorts... > >I just put files1.tar.gz into freefall:/incoming >this contains the older console.h and syscons.c that seem to be necessary. >this contains the old vector.s and icu.s that I think are usable. > >So... you can cvsup the latest SMP stuff, overlay these 4 files and >go crazy with me! > >The death seems to be when the 2nd CPU runs its 1st process. I can >start it up with sysctl and have it stop at a cngetc() in secondary_main >just b4 it calls 'cpu_switch(curproc)'. The system is healthy at this point. >I hit return, the 2nd CPU presummably enters cpu_switch, and I get a >root prompt back on the console ( "# " ). I can hit repeatedly >and get another prompt. The moment I try to do anything, even a shell builtin >like "echo foo", I get a reboot. > >-- >Steve Passe | powered by >smp@csn.net | FreeBSD > > From owner-freebsd-smp Thu Nov 21 18:27:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA06819 for smp-outgoing; Thu, 21 Nov 1996 18:27:20 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA06800 for ; Thu, 21 Nov 1996 18:26:50 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id KAA25749; Fri, 22 Nov 1996 10:26:21 +0800 (WST) Message-Id: <199611220226.KAA25749@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Chris Csanady cc: Steve Passe , freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of "Thu, 21 Nov 1996 19:33:42 CST." <199611220133.TAA06109@friley216.res.iastate.edu> Date: Fri, 22 Nov 1996 10:26:20 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > > Just a thought, but what about the i586 optimized stuff? It is now default, > and I believe its all included even in the SMP case. How about trying the > old npx stuff? > > --Chris Csanady I changed all the "#ifdef I586_CPU" conditionals for the p5-only optimisations to "#if defined(I586_CPU) && !defined(SMP)" so that the p5 uses the generic bcopy/bzero/copyin/copyout like the rest of the cpu's. Cheers, -Peter From owner-freebsd-smp Thu Nov 21 19:04:25 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA12195 for smp-outgoing; Thu, 21 Nov 1996 19:04:25 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA12186 for freebsd-smp; Thu, 21 Nov 1996 19:04:18 -0800 (PST) Date: Thu, 21 Nov 1996 19:04:18 -0800 (PST) From: Peter Wemm Message-Id: <199611220304.TAA12186@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys - Imported sources Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/21 19:04:14 sys - Imported sources Update of /home/smp/sys In directory freefall.freebsd.org:/f/peter/work/sys Revision/Branch: 1.1.1 Log Message: Import -current 961121 (including netns and pc98) Status: Vendor Tag: CURRENT Release Tags: v961121 I sys/CVS U sys/Makefile I sys/compile/CVS U sys/compile/.keep_me I sys/netkey/CVS U sys/netkey/key.c U sys/netkey/key.h U sys/netkey/key_debug.c U sys/netkey/key_debug.h I sys/conf/CVS U sys/conf/defines U sys/conf/files U sys/conf/files.newconf U sys/conf/newvers.sh U sys/conf/nfsswapkernel.c U sys/conf/options U sys/conf/param.c U sys/conf/systags.sh I sys/ddb/CVS U sys/ddb/db_access.c U sys/ddb/db_access.h U sys/ddb/db_aout.c U sys/ddb/db_break.c U sys/ddb/db_break.h U sys/ddb/db_command.c U sys/ddb/db_command.h U sys/ddb/db_examine.c U sys/ddb/db_expr.c U sys/ddb/db_input.c U sys/ddb/db_lex.c U sys/ddb/db_lex.h U sys/ddb/db_output.c U sys/ddb/db_output.h U sys/ddb/db_print.c U sys/ddb/db_ps.c U sys/ddb/db_run.c U sys/ddb/db_sym.c U sys/ddb/db_sym.h U sys/ddb/db_trap.c U sys/ddb/db_variables.c U sys/ddb/db_variables.h U sys/ddb/db_watch.c U sys/ddb/db_watch.h U sys/ddb/db_write_cmd.c U sys/ddb/ddb.h I sys/dev/CVS I sys/dev/aic7xxx/CVS U sys/dev/aic7xxx/aic7xxx.seq U sys/dev/aic7xxx/aic7xxx_asm.1 U sys/dev/aic7xxx/aic7xxx_asm.c U sys/dev/aic7xxx/aic7xxx_reg.h I sys/dev/vn/CVS U sys/dev/vn/vn.c I sys/dev/ccd/CVS U sys/dev/ccd/ccd.c I sys/dev/advansys/CVS U sys/dev/advansys/advlib.c U sys/dev/advansys/advlib.h U sys/dev/advansys/advmcode.c U sys/dev/advansys/advmcode.h I sys/dev/vx/CVS U sys/dev/vx/if_vx.c U sys/dev/vx/if_vxreg.h I sys/gnu/CVS I sys/gnu/ext2fs/CVS U sys/gnu/ext2fs/COPYRIGHT.INFO U sys/gnu/ext2fs/ext2_alloc.c U sys/gnu/ext2fs/ext2_balloc.c U sys/gnu/ext2fs/ext2_extern.h U sys/gnu/ext2fs/ext2_fs.h U sys/gnu/ext2fs/ext2_fs_i.h U sys/gnu/ext2fs/ext2_fs_sb.h U sys/gnu/ext2fs/ext2_inode.c U sys/gnu/ext2fs/ext2_inode_cnv.c U sys/gnu/ext2fs/ext2_linux_balloc.c U sys/gnu/ext2fs/ext2_linux_ialloc.c U sys/gnu/ext2fs/ext2_lookup.c U sys/gnu/ext2fs/ext2_readwrite.c U sys/gnu/ext2fs/ext2_subr.c U sys/gnu/ext2fs/ext2_vfsops.c U sys/gnu/ext2fs/ext2_vnops.c U sys/gnu/ext2fs/fs.h U sys/gnu/ext2fs/i386-bitops.h I sys/gnu/i386/CVS I sys/gnu/i386/fpemul/CVS U sys/gnu/i386/fpemul/Changelog U sys/gnu/i386/fpemul/README U sys/gnu/i386/fpemul/control_w.h U sys/gnu/i386/fpemul/div_small.s U sys/gnu/i386/fpemul/errors.c U sys/gnu/i386/fpemul/exception.h U sys/gnu/i386/fpemul/fpu_arith.c U sys/gnu/i386/fpemul/fpu_asm.h U sys/gnu/i386/fpemul/fpu_aux.c U sys/gnu/i386/fpemul/fpu_emu.h U sys/gnu/i386/fpemul/fpu_entry.c U sys/gnu/i386/fpemul/fpu_etc.c U sys/gnu/i386/fpemul/fpu_proto.h U sys/gnu/i386/fpemul/fpu_system.h U sys/gnu/i386/fpemul/fpu_trig.c U sys/gnu/i386/fpemul/get_address.c U sys/gnu/i386/fpemul/load_store.c U sys/gnu/i386/fpemul/math_emu.h U sys/gnu/i386/fpemul/poly_2xm1.c U sys/gnu/i386/fpemul/poly_atan.c U sys/gnu/i386/fpemul/poly_div.s U sys/gnu/i386/fpemul/poly_l2.c U sys/gnu/i386/fpemul/poly_mul64.s U sys/gnu/i386/fpemul/poly_sin.c U sys/gnu/i386/fpemul/poly_tan.c U sys/gnu/i386/fpemul/polynomial.s U sys/gnu/i386/fpemul/reg_add_sub.c U sys/gnu/i386/fpemul/reg_compare.c U sys/gnu/i386/fpemul/reg_constant.c U sys/gnu/i386/fpemul/reg_constant.h U sys/gnu/i386/fpemul/reg_div.s U sys/gnu/i386/fpemul/reg_ld_str.c U sys/gnu/i386/fpemul/reg_mul.c U sys/gnu/i386/fpemul/reg_norm.s U sys/gnu/i386/fpemul/reg_round.s U sys/gnu/i386/fpemul/reg_u_add.s U sys/gnu/i386/fpemul/reg_u_div.s U sys/gnu/i386/fpemul/reg_u_mul.s U sys/gnu/i386/fpemul/reg_u_sub.s U sys/gnu/i386/fpemul/status_w.h U sys/gnu/i386/fpemul/version.h U sys/gnu/i386/fpemul/wm_shrx.s U sys/gnu/i386/fpemul/wm_sqrt.s I sys/gnu/i386/isa/CVS U sys/gnu/i386/isa/dgb.c U sys/gnu/i386/isa/dgbios.h U sys/gnu/i386/isa/dgfep.h U sys/gnu/i386/isa/dgreg.h I sys/i386/CVS U sys/i386/Makefile I sys/i386/apm/CVS U sys/i386/apm/apm.c U sys/i386/apm/apm_setup.h U sys/i386/apm/apm_setup.s I sys/i386/apm/apm_init/CVS U sys/i386/apm/apm_init/Makefile U sys/i386/apm/apm_init/apm_init.S U sys/i386/apm/apm_init/apm_init.inc U sys/i386/apm/apm_init/bin2asm.c U sys/i386/apm/apm_init/real_prot.S U sys/i386/apm/apm_init/real_prot.h U sys/i386/apm/apm_init/rmaouthdr U sys/i386/apm/apm_init/table.c I sys/i386/boot/CVS U sys/i386/boot/Makefile I sys/i386/boot/biosboot/CVS U sys/i386/boot/biosboot/Makefile U sys/i386/boot/biosboot/README.386BSD U sys/i386/boot/biosboot/README.MACH U sys/i386/boot/biosboot/README.serial U sys/i386/boot/biosboot/asm.S U sys/i386/boot/biosboot/asm.h U sys/i386/boot/biosboot/bios.S U sys/i386/boot/biosboot/boot.c U sys/i386/boot/biosboot/boot.h U sys/i386/boot/biosboot/boot2.S U sys/i386/boot/biosboot/disk.c U sys/i386/boot/biosboot/io.c U sys/i386/boot/biosboot/probe_keyboard.c U sys/i386/boot/biosboot/serial.S U sys/i386/boot/biosboot/start.S U sys/i386/boot/biosboot/sys.c U sys/i386/boot/biosboot/table.c I sys/i386/boot/rawboot/CVS U sys/i386/boot/rawboot/Makefile U sys/i386/boot/rawboot/README I sys/i386/boot/dosboot/CVS U sys/i386/boot/dosboot/Makefile U sys/i386/boot/dosboot/ansi.h U sys/i386/boot/dosboot/boot.c U sys/i386/boot/dosboot/boot.h U sys/i386/boot/dosboot/bootinfo.h U sys/i386/boot/dosboot/cdefs.h U sys/i386/boot/dosboot/dinode.h U sys/i386/boot/dosboot/dir.h U sys/i386/boot/dosboot/dirent.h U sys/i386/boot/dosboot/disk.c U sys/i386/boot/dosboot/disklabe.h U sys/i386/boot/dosboot/dkbad.h U sys/i386/boot/dosboot/dosboot.c U sys/i386/boot/dosboot/dosboot.h U sys/i386/boot/dosboot/endian.h U sys/i386/boot/dosboot/exec.h U sys/i386/boot/dosboot/fbsdboot.c U sys/i386/boot/dosboot/fbsdboot.exe.uu U sys/i386/boot/dosboot/fbsdboot.mak U sys/i386/boot/dosboot/fs.h U sys/i386/boot/dosboot/imgact.h U sys/i386/boot/dosboot/inode.h U sys/i386/boot/dosboot/mexec.h U sys/i386/boot/dosboot/param.h U sys/i386/boot/dosboot/quota.h U sys/i386/boot/dosboot/protmod.c U sys/i386/boot/dosboot/protmod.h U sys/i386/boot/dosboot/readme U sys/i386/boot/dosboot/reboot.h U sys/i386/boot/dosboot/sys.c U sys/i386/boot/dosboot/syslimit.h U sys/i386/boot/dosboot/sysparam.h U sys/i386/boot/dosboot/types.h I sys/i386/boot/kzipboot/CVS U sys/i386/boot/kzipboot/Makefile U sys/i386/boot/kzipboot/README U sys/i386/boot/kzipboot/boot.c U sys/i386/boot/kzipboot/gzip.h U sys/i386/boot/kzipboot/head.S U sys/i386/boot/kzipboot/malloc.c U sys/i386/boot/kzipboot/misc.c U sys/i386/boot/kzipboot/tail.S U sys/i386/boot/kzipboot/unzip.c I sys/i386/boot/netboot/CVS U sys/i386/boot/netboot/3c509.c U sys/i386/boot/netboot/3c509.h U sys/i386/boot/netboot/Makefile U sys/i386/boot/netboot/bootmenu.c U sys/i386/boot/netboot/main.c U sys/i386/boot/netboot/makerom.c U sys/i386/boot/netboot/misc.c U sys/i386/boot/netboot/netboot.h U sys/i386/boot/netboot/ns8390.c U sys/i386/boot/netboot/ns8390.h U sys/i386/boot/netboot/rpc.c U sys/i386/boot/netboot/start2.S I sys/i386/conf/CVS U sys/i386/conf/GENERIC U sys/i386/conf/LINT U sys/i386/conf/Makefile.i386 U sys/i386/conf/devices.i386 U sys/i386/conf/files.i386 U sys/i386/conf/majors.i386 U sys/i386/conf/options.i386 I sys/i386/eisa/CVS U sys/i386/eisa/3c5x9.c U sys/i386/eisa/aha1742.c U sys/i386/eisa/aic7770.c U sys/i386/eisa/bt74x.c U sys/i386/eisa/eisaconf.c U sys/i386/eisa/eisaconf.h U sys/i386/eisa/if_vx_eisa.c I sys/i386/i386/CVS U sys/i386/i386/autoconf.c U sys/i386/i386/cons.c U sys/i386/i386/cons.h U sys/i386/i386/db_disasm.c U sys/i386/i386/db_interface.c U sys/i386/i386/db_trace.c U sys/i386/i386/exception.s U sys/i386/i386/genassym.c U sys/i386/i386/in_cksum.c U sys/i386/i386/locore.s U sys/i386/i386/machdep.c U sys/i386/i386/math_emu.h U sys/i386/i386/math_emulate.c U sys/i386/i386/mem.c U sys/i386/i386/microtime.s U sys/i386/i386/perfmon.c U sys/i386/i386/pmap.c U sys/i386/i386/procfs_machdep.c U sys/i386/i386/support.s U sys/i386/i386/swapgeneric.c U sys/i386/i386/swtch.s U sys/i386/i386/symbols.raw U sys/i386/i386/trap.c U sys/i386/i386/sys_machdep.c U sys/i386/i386/userconfig.c U sys/i386/i386/vm_machdep.c U sys/i386/i386/identcpu.c U sys/i386/i386/i386-gdbstub.c I sys/i386/ibcs2/CVS U sys/i386/ibcs2/coff.h U sys/i386/ibcs2/ibcs2_dirent.h U sys/i386/ibcs2/ibcs2_errno.c U sys/i386/ibcs2/ibcs2_errno.h U sys/i386/ibcs2/ibcs2_fcntl.c U sys/i386/ibcs2/ibcs2_fcntl.h U sys/i386/ibcs2/ibcs2_ioctl.c U sys/i386/ibcs2/ibcs2_ioctl.h U sys/i386/ibcs2/ibcs2_ipc.c U sys/i386/ibcs2/ibcs2_ipc.h U sys/i386/ibcs2/ibcs2_isc.c U sys/i386/ibcs2/ibcs2_isc_syscall.h U sys/i386/ibcs2/ibcs2_isc_sysent.c U sys/i386/ibcs2/ibcs2_misc.c U sys/i386/ibcs2/ibcs2_mount.h U sys/i386/ibcs2/ibcs2_msg.c U sys/i386/ibcs2/ibcs2_other.c U sys/i386/ibcs2/ibcs2_poll.h U sys/i386/ibcs2/ibcs2_proto.h U sys/i386/ibcs2/ibcs2_signal.c U sys/i386/ibcs2/ibcs2_signal.h U sys/i386/ibcs2/ibcs2_socksys.c U sys/i386/ibcs2/ibcs2_socksys.h U sys/i386/ibcs2/ibcs2_stat.c U sys/i386/ibcs2/ibcs2_stat.h U sys/i386/ibcs2/ibcs2_statfs.h U sys/i386/ibcs2/ibcs2_stropts.h U sys/i386/ibcs2/ibcs2_syscall.h U sys/i386/ibcs2/ibcs2_sysent.c U sys/i386/ibcs2/ibcs2_sysi86.c U sys/i386/ibcs2/ibcs2_sysvec.c U sys/i386/ibcs2/ibcs2_termios.h U sys/i386/ibcs2/ibcs2_time.h U sys/i386/ibcs2/ibcs2_types.h U sys/i386/ibcs2/ibcs2_unistd.h U sys/i386/ibcs2/ibcs2_ustat.h U sys/i386/ibcs2/ibcs2_util.c U sys/i386/ibcs2/ibcs2_util.h U sys/i386/ibcs2/ibcs2_utime.h U sys/i386/ibcs2/ibcs2_utsname.h U sys/i386/ibcs2/ibcs2_xenix.c U sys/i386/ibcs2/ibcs2_xenix.h U sys/i386/ibcs2/ibcs2_xenix_syscall.h U sys/i386/ibcs2/ibcs2_xenix_sysent.c U sys/i386/ibcs2/imgact_coff.c U sys/i386/ibcs2/syscalls.conf U sys/i386/ibcs2/syscalls.isc U sys/i386/ibcs2/syscalls.isc.conf U sys/i386/ibcs2/syscalls.master U sys/i386/ibcs2/syscalls.xenix U sys/i386/ibcs2/syscalls.xenix.conf I sys/i386/include/CVS U sys/i386/include/apm_bios.h U sys/i386/include/apm_segments.h U sys/i386/include/asc_ioctl.h U sys/i386/include/asmacros.h U sys/i386/include/bootinfo.h U sys/i386/include/clock.h U sys/i386/include/conf.h U sys/i386/include/cons.h U sys/i386/include/console.h U sys/i386/include/cpu.h U sys/i386/include/cpufunc.h U sys/i386/include/cputypes.h U sys/i386/include/cronyx.h U sys/i386/include/db_machdep.h U sys/i386/include/gsc.h U sys/i386/include/endian.h U sys/i386/include/exec.h U sys/i386/include/float.h U sys/i386/include/floatingpoint.h U sys/i386/include/frame.h U sys/i386/include/lpt.h U sys/i386/include/ieeefp.h U sys/i386/include/ioctl_ctx.h U sys/i386/include/ioctl_fd.h U sys/i386/include/ioctl_meteor.h U sys/i386/include/ipl.h U sys/i386/include/joystick.h U sys/i386/include/pcaudioio.h U sys/i386/include/limits.h U sys/i386/include/pmap.h U sys/i386/include/md_var.h U sys/i386/include/mouse.h U sys/i386/include/mtpr.h U sys/i386/include/npx.h U sys/i386/include/param.h U sys/i386/include/perfmon.h U sys/i386/include/pcb.h U sys/i386/include/pcvt_ioctl.h U sys/i386/include/random.h U sys/i386/include/types.h U sys/i386/include/proc.h U sys/i386/include/profile.h U sys/i386/include/psl.h U sys/i386/include/qcam.h U sys/i386/include/ptrace.h U sys/i386/include/spl.h U sys/i386/include/segments.h U sys/i386/include/reg.h U sys/i386/include/reloc.h U sys/i386/include/soundcard.h U sys/i386/include/si.h U sys/i386/include/signal.h U sys/i386/include/speaker.h U sys/i386/include/spigot.h U sys/i386/include/specialreg.h U sys/i386/include/trap.h U sys/i386/include/stdarg.h U sys/i386/include/sysarch.h U sys/i386/include/tss.h U sys/i386/include/ultrasound.h U sys/i386/include/varargs.h U sys/i386/include/vmparam.h U sys/i386/include/wtio.h U sys/i386/include/ansi.h U sys/i386/include/in_cksum.h U sys/i386/include/cdk.h U sys/i386/include/comstats.h I sys/i386/include/pc/CVS U sys/i386/include/pc/display.h U sys/i386/include/pc/msdos.h I sys/i386/isa/CVS U sys/i386/isa/README.le U sys/i386/isa/aic6360.c U sys/i386/isa/asc.c U sys/i386/isa/ascreg.h U sys/i386/isa/atapi.c U sys/i386/isa/atapi.h U sys/i386/isa/b004.c U sys/i386/isa/b004.h U sys/i386/isa/bt5xx-445.c U sys/i386/isa/clock.c U sys/i386/isa/cronyx.c U sys/i386/isa/ctx.c U sys/i386/isa/ctxreg.h U sys/i386/isa/cx.c U sys/i386/isa/cxreg.h U sys/i386/isa/cy.c U sys/i386/isa/cyreg.h U sys/i386/isa/diskslice_machdep.c U sys/i386/isa/elink.c U sys/i386/isa/elink.h U sys/i386/isa/fd.c U sys/i386/isa/fdc.h U sys/i386/isa/fdreg.h U sys/i386/isa/ft.c U sys/i386/isa/ftreg.h U sys/i386/isa/gpib.c U sys/i386/isa/gpib.h U sys/i386/isa/gpibreg.h U sys/i386/isa/gsc.c U sys/i386/isa/gscreg.h U sys/i386/isa/icu.h U sys/i386/isa/icu.s U sys/i386/isa/if_ar.c U sys/i386/isa/if_arregs.h U sys/i386/isa/if_cx.c U sys/i386/isa/if_ed.c U sys/i386/isa/if_edreg.h U sys/i386/isa/if_eg.c U sys/i386/isa/if_egreg.h U sys/i386/isa/if_el.c U sys/i386/isa/if_elreg.h U sys/i386/isa/if_ep.c U sys/i386/isa/if_epreg.h U sys/i386/isa/if_fe.c U sys/i386/isa/if_fereg.h U sys/i386/isa/if_ie.c U sys/i386/isa/if_ie507.h U sys/i386/isa/if_iereg.h U sys/i386/isa/if_ix.c U sys/i386/isa/if_ixreg.h U sys/i386/isa/if_le.c U sys/i386/isa/if_lnc.c U sys/i386/isa/if_lnc.h U sys/i386/isa/if_ze.c U sys/i386/isa/if_zp.c U sys/i386/isa/if_zpreg.h U sys/i386/isa/isa.c U sys/i386/isa/isa.h U sys/i386/isa/isa_device.h U sys/i386/isa/joy.c U sys/i386/isa/kbdio.c U sys/i386/isa/kbdtables.h U sys/i386/isa/labpc.c U sys/i386/isa/lpt.c U sys/i386/isa/lptreg.h U sys/i386/isa/mcd.c U sys/i386/isa/mcdreg.h U sys/i386/isa/mse.c U sys/i386/isa/ncr5380.c U sys/i386/isa/npx.c U sys/i386/isa/pcaudio.c U sys/i386/isa/pcibus.c U sys/i386/isa/pcic.h U sys/i386/isa/pcicx.c U sys/i386/isa/prof_machdep.c U sys/i386/isa/psm.c U sys/i386/isa/qcam.c U sys/i386/isa/qcamdefs.h U sys/i386/isa/qcamio.c U sys/i386/isa/qcamreg.h U sys/i386/isa/rc.c U sys/i386/isa/random_machdep.c U sys/i386/isa/rcreg.h U sys/i386/isa/rtc.h U sys/i386/isa/scd.c U sys/i386/isa/scdreg.h U sys/i386/isa/seagate.c U sys/i386/isa/si.c U sys/i386/isa/si_code.c U sys/i386/isa/sio.c U sys/i386/isa/sioreg.h U sys/i386/isa/sireg.h U sys/i386/isa/spigot.c U sys/i386/isa/spkr.c U sys/i386/isa/syscons.c U sys/i386/isa/syscons.h U sys/i386/isa/timerreg.h U sys/i386/isa/tw.c U sys/i386/isa/ultra14f.c U sys/i386/isa/vector.s U sys/i386/isa/wcd.c U sys/i386/isa/wd.c U sys/i386/isa/wd7000.c U sys/i386/isa/wdreg.h U sys/i386/isa/wt.c U sys/i386/isa/wtreg.h U sys/i386/isa/aha1542.c U sys/i386/isa/README.stl U sys/i386/isa/istallion.c U sys/i386/isa/stallion.c U sys/i386/isa/if_sr.c U sys/i386/isa/if_srregs.h U sys/i386/isa/adv_isa.c U sys/i386/isa/aic_98.h U sys/i386/isa/kbdio.h I sys/i386/isa/ic/CVS U sys/i386/isa/ic/Am7990.h U sys/i386/isa/ic/am7990.h U sys/i386/isa/ic/cd1400.h U sys/i386/isa/ic/cd180.h U sys/i386/isa/ic/esp.h U sys/i386/isa/ic/hd64570.h U sys/i386/isa/ic/i8042.h U sys/i386/isa/ic/i82365.h U sys/i386/isa/ic/i8237.h U sys/i386/isa/ic/i82586.h U sys/i386/isa/ic/lemac.h U sys/i386/isa/ic/mb86960.h U sys/i386/isa/ic/ncr53400.h U sys/i386/isa/ic/ncr5380.h U sys/i386/isa/ic/nec765.h U sys/i386/isa/ic/ns16450.h U sys/i386/isa/ic/ns16550.h U sys/i386/isa/ic/scd1400.h U sys/i386/isa/ic/i8251.h U sys/i386/isa/ic/wd33c93.h I sys/i386/isa/matcd/CVS U sys/i386/isa/matcd/TODO U sys/i386/isa/matcd/audio.c U sys/i386/isa/matcd/creative.h U sys/i386/isa/matcd/matcd.c U sys/i386/isa/matcd/matcddrv.h U sys/i386/isa/matcd/options.h I sys/i386/isa/pcvt/CVS U sys/i386/isa/pcvt/pcvt_conf.h U sys/i386/isa/pcvt/pcvt_drv.c U sys/i386/isa/pcvt/pcvt_ext.c U sys/i386/isa/pcvt/pcvt_hdr.h U sys/i386/isa/pcvt/pcvt_kbd.c U sys/i386/isa/pcvt/pcvt_kbd.h U sys/i386/isa/pcvt/pcvt_out.c U sys/i386/isa/pcvt/pcvt_sup.c U sys/i386/isa/pcvt/pcvt_tbl.h U sys/i386/isa/pcvt/pcvt_vtf.c I sys/i386/isa/sound/CVS U sys/i386/isa/sound/CHANGELOG U sys/i386/isa/sound/COPYING U sys/i386/isa/sound/README U sys/i386/isa/sound/Readme.aedsp16 U sys/i386/isa/sound/Readme.modules U sys/i386/isa/sound/Readme.v30 U sys/i386/isa/sound/ad1848.c U sys/i386/isa/sound/ad1848_mixer.h U sys/i386/isa/sound/adlib_card.c U sys/i386/isa/sound/aedsp16.c U sys/i386/isa/sound/audio.c U sys/i386/isa/sound/coproc.h U sys/i386/isa/sound/dev_table.c U sys/i386/isa/sound/dev_table.h U sys/i386/isa/sound/dmabuf.c U sys/i386/isa/sound/finetune.h U sys/i386/isa/sound/gus_card.c U sys/i386/isa/sound/gus_hw.h U sys/i386/isa/sound/gus_linearvol.h U sys/i386/isa/sound/gus_midi.c U sys/i386/isa/sound/gus_vol.c U sys/i386/isa/sound/gus_wave.c U sys/i386/isa/sound/hex2hex.h U sys/i386/isa/sound/ics2101.c U sys/i386/isa/sound/local.h U sys/i386/isa/sound/mad16.h U sys/i386/isa/sound/midi_ctrl.h U sys/i386/isa/sound/midi_synth.c U sys/i386/isa/sound/midi_synth.h U sys/i386/isa/sound/midibuf.c U sys/i386/isa/sound/mpu401.c U sys/i386/isa/sound/opl3.c U sys/i386/isa/sound/opl3.h U sys/i386/isa/sound/os.h U sys/i386/isa/sound/pas2_card.c U sys/i386/isa/sound/pas2_midi.c U sys/i386/isa/sound/pas2_mixer.c U sys/i386/isa/sound/pas2_pcm.c U sys/i386/isa/sound/patmgr.c U sys/i386/isa/sound/sb16_dsp.c U sys/i386/isa/sound/sb16_midi.c U sys/i386/isa/sound/sb_card.c U sys/i386/isa/sound/sb_dsp.c U sys/i386/isa/sound/sb_midi.c U sys/i386/isa/sound/sb_mixer.c U sys/i386/isa/sound/sb_mixer.h U sys/i386/isa/sound/sequencer.c U sys/i386/isa/sound/sound.doc U sys/i386/isa/sound/sound_calls.h U sys/i386/isa/sound/sound_config.h U sys/i386/isa/sound/sound_switch.c U sys/i386/isa/sound/sound_timer.c U sys/i386/isa/sound/soundcard.c U sys/i386/isa/sound/soundvers.h U sys/i386/isa/sound/sscape.c U sys/i386/isa/sound/sys_timer.c U sys/i386/isa/sound/trix.c U sys/i386/isa/sound/tuning.h U sys/i386/isa/sound/uart6850.c U sys/i386/isa/sound/ulaw.h U sys/i386/isa/sound/pcm86.c U sys/i386/isa/sound/awe_hw.h U sys/i386/isa/sound/awe_voice.h U sys/i386/isa/sound/awe_wave.c U sys/i386/isa/sound/pas_defs.h U sys/i386/isa/sound/sb_defs.h I sys/i386/linux/CVS U sys/i386/linux/imgact_linux.c U sys/i386/linux/linux.h U sys/i386/linux/linux_dummy.c U sys/i386/linux/linux_file.c U sys/i386/linux/linux_genassym.c U sys/i386/linux/linux_ioctl.c U sys/i386/linux/linux_ipc.c U sys/i386/linux/linux_locore.s U sys/i386/linux/linux_misc.c U sys/i386/linux/linux_proto.h U sys/i386/linux/linux_signal.c U sys/i386/linux/linux_socket.c U sys/i386/linux/linux_stats.c U sys/i386/linux/linux_syscall.h U sys/i386/linux/linux_sysent.c U sys/i386/linux/linux_sysvec.c U sys/i386/linux/linux_util.c U sys/i386/linux/linux_util.h U sys/i386/linux/syscalls.conf U sys/i386/linux/syscalls.master I sys/i386/scsi/CVS U sys/i386/scsi/93cx6.c U sys/i386/scsi/93cx6.h U sys/i386/scsi/aic7xxx.c U sys/i386/scsi/aic7xxx.h U sys/i386/scsi/bt.c U sys/i386/scsi/btreg.h U sys/i386/scsi/advansys.c U sys/i386/scsi/advansys.h I sys/isofs/CVS I sys/isofs/cd9660/CVS U sys/isofs/cd9660/TODO U sys/isofs/cd9660/TODO.hibler U sys/isofs/cd9660/cd9660_bmap.c U sys/isofs/cd9660/cd9660_lookup.c U sys/isofs/cd9660/cd9660_mount.h U sys/isofs/cd9660/cd9660_node.c U sys/isofs/cd9660/cd9660_node.h U sys/isofs/cd9660/cd9660_rrip.c U sys/isofs/cd9660/cd9660_rrip.h U sys/isofs/cd9660/cd9660_util.c U sys/isofs/cd9660/cd9660_vfsops.c U sys/isofs/cd9660/cd9660_vnops.c U sys/isofs/cd9660/iso.h U sys/isofs/cd9660/iso_rrip.h I sys/kern/CVS U sys/kern/Make.tags.inc U sys/kern/Makefile U sys/kern/imgact_aout.c U sys/kern/imgact_elf.c U sys/kern/imgact_gzip.c U sys/kern/imgact_shell.c U sys/kern/inflate.c U sys/kern/init_main.c U sys/kern/init_sysent.c U sys/kern/init_sysvec.c U sys/kern/kern_acct.c U sys/kern/kern_clock.c U sys/kern/kern_conf.c U sys/kern/kern_descrip.c U sys/kern/kern_exit.c U sys/kern/kern_exec.c U sys/kern/kern_mib.c U sys/kern/kern_fork.c U sys/kern/kern_ktrace.c U sys/kern/kern_lkm.c U sys/kern/kern_lockf.c U sys/kern/kern_malloc.c U sys/kern/kern_ntptime.c U sys/kern/kern_physio.c U sys/kern/kern_proc.c U sys/kern/kern_prot.c U sys/kern/kern_resource.c U sys/kern/kern_sig.c U sys/kern/kern_subr.c U sys/kern/kern_synch.c U sys/kern/kern_sysctl.c U sys/kern/kern_time.c U sys/kern/kern_xxx.c U sys/kern/makesyscalls.sh U sys/kern/subr_autoconf.c U sys/kern/subr_diskslice.c U sys/kern/subr_dkbad.c U sys/kern/subr_log.c U sys/kern/subr_prf.c U sys/kern/subr_prof.c U sys/kern/subr_rlist.c U sys/kern/subr_xxx.c U sys/kern/sys_pipe.c U sys/kern/sys_generic.c U sys/kern/sys_process.c U sys/kern/sys_socket.c U sys/kern/syscalls.c U sys/kern/syscalls.master U sys/kern/sysv_ipc.c U sys/kern/sysv_msg.c U sys/kern/sysv_sem.c U sys/kern/sysv_shm.c U sys/kern/tty.c U sys/kern/tty_compat.c U sys/kern/tty_conf.c U sys/kern/tty_pty.c U sys/kern/tty_snoop.c U sys/kern/tty_subr.c U sys/kern/tty_tb.c U sys/kern/tty_tty.c U sys/kern/uipc_domain.c U sys/kern/uipc_mbuf.c U sys/kern/uipc_proto.c U sys/kern/uipc_socket.c U sys/kern/uipc_socket2.c U sys/kern/uipc_syscalls.c U sys/kern/uipc_usrreq.c U sys/kern/vfs_bio.c U sys/kern/vfs_cache.c U sys/kern/vfs_cluster.c U sys/kern/vfs_conf.c U sys/kern/vfs_init.c U sys/kern/vfs_lookup.c U sys/kern/vfs_subr.c U sys/kern/vfs_syscalls.c U sys/kern/vfs_vnops.c U sys/kern/vnode_if.sh U sys/kern/vnode_if.src U sys/kern/kern_shutdown.c I sys/libkern/CVS U sys/libkern/adddi3.c U sys/libkern/anddi3.c U sys/libkern/ashldi3.c U sys/libkern/ashrdi3.c U sys/libkern/bcd.c U sys/libkern/bcmp.c U sys/libkern/cmpdi2.c U sys/libkern/divdi3.c U sys/libkern/ffs.c U sys/libkern/inet_ntoa.c U sys/libkern/iordi3.c U sys/libkern/locc.c U sys/libkern/lshldi3.c U sys/libkern/lshrdi3.c U sys/libkern/mcount.c U sys/libkern/moddi3.c U sys/libkern/muldi3.c U sys/libkern/negdi2.c U sys/libkern/notdi2.c U sys/libkern/qdivrem.c U sys/libkern/qsort.c U sys/libkern/quad.h U sys/libkern/random.c U sys/libkern/rindex.c U sys/libkern/scanc.c U sys/libkern/skpc.c U sys/libkern/strcat.c U sys/libkern/strcmp.c U sys/libkern/strcpy.c U sys/libkern/strlen.c U sys/libkern/strncmp.c U sys/libkern/strncpy.c U sys/libkern/subdi3.c U sys/libkern/ucmpdi2.c U sys/libkern/udivdi3.c U sys/libkern/umoddi3.c U sys/libkern/xordi3.c U sys/libkern/index.c I sys/miscfs/CVS I sys/miscfs/deadfs/CVS U sys/miscfs/deadfs/dead_vnops.c I sys/miscfs/devfs/CVS U sys/miscfs/devfs/README U sys/miscfs/devfs/devfs_proto.h U sys/miscfs/devfs/devfs_tree.c U sys/miscfs/devfs/devfs_vfsops.c U sys/miscfs/devfs/devfs_vnops.c U sys/miscfs/devfs/devfsdefs.h U sys/miscfs/devfs/reproto.sh I sys/miscfs/fdesc/CVS U sys/miscfs/fdesc/fdesc.h U sys/miscfs/fdesc/fdesc_vfsops.c U sys/miscfs/fdesc/fdesc_vnops.c I sys/miscfs/fifofs/CVS U sys/miscfs/fifofs/fifo.h U sys/miscfs/fifofs/fifo_vnops.c I sys/miscfs/kernfs/CVS U sys/miscfs/kernfs/kernfs.h U sys/miscfs/kernfs/kernfs_vfsops.c U sys/miscfs/kernfs/kernfs_vnops.c I sys/miscfs/nullfs/CVS U sys/miscfs/nullfs/null.h U sys/miscfs/nullfs/null_subr.c U sys/miscfs/nullfs/null_vfsops.c U sys/miscfs/nullfs/null_vnops.c I sys/miscfs/portal/CVS U sys/miscfs/portal/portal.h U sys/miscfs/portal/portal_vfsops.c U sys/miscfs/portal/portal_vnops.c I sys/miscfs/procfs/CVS U sys/miscfs/procfs/README U sys/miscfs/procfs/procfs.h U sys/miscfs/procfs/procfs_ctl.c U sys/miscfs/procfs/procfs_fpregs.c U sys/miscfs/procfs/procfs_mem.c U sys/miscfs/procfs/procfs_note.c U sys/miscfs/procfs/procfs_regs.c U sys/miscfs/procfs/procfs_status.c U sys/miscfs/procfs/procfs_subr.c U sys/miscfs/procfs/procfs_vfsops.c U sys/miscfs/procfs/procfs_vnops.c U sys/miscfs/procfs/procfs_map.c U sys/miscfs/procfs/procfs_type.c I sys/miscfs/specfs/CVS U sys/miscfs/specfs/spec_vnops.c U sys/miscfs/specfs/specdev.h I sys/miscfs/umapfs/CVS U sys/miscfs/umapfs/umap.h U sys/miscfs/umapfs/umap_subr.c U sys/miscfs/umapfs/umap_vfsops.c U sys/miscfs/umapfs/umap_vnops.c I sys/miscfs/union/CVS U sys/miscfs/union/README U sys/miscfs/union/libc.fts.c U sys/miscfs/union/libc.opendir.c U sys/miscfs/union/libc.readdir.c U sys/miscfs/union/union.h U sys/miscfs/union/union_subr.c U sys/miscfs/union/union_vfsops.c U sys/miscfs/union/union_vnops.c I sys/msdosfs/CVS U sys/msdosfs/bootsect.h U sys/msdosfs/bpb.h U sys/msdosfs/denode.h U sys/msdosfs/direntry.h U sys/msdosfs/fat.h U sys/msdosfs/msdosfs_conv.c U sys/msdosfs/msdosfs_denode.c U sys/msdosfs/msdosfs_fat.c U sys/msdosfs/msdosfs_lookup.c U sys/msdosfs/msdosfs_vfsops.c U sys/msdosfs/msdosfs_vnops.c U sys/msdosfs/msdosfsmount.h I sys/net/CVS U sys/net/bpf.c U sys/net/bpf.h U sys/net/bpf_compat.h U sys/net/bpf_filter.c U sys/net/bpfdesc.h U sys/net/bsd_comp.c U sys/net/if.c U sys/net/if.h U sys/net/if_arp.h U sys/net/if_disc.c U sys/net/if_dl.h U sys/net/if_ethersubr.c U sys/net/if_fddisubr.c U sys/net/if_llc.h U sys/net/if_loop.c U sys/net/if_ppp.c U sys/net/if_ppp.h U sys/net/if_pppvar.h U sys/net/if_sl.c U sys/net/if_slvar.h U sys/net/if_sppp.h U sys/net/if_spppsubr.c U sys/net/if_tun.c U sys/net/if_tun.h U sys/net/if_types.h U sys/net/netisr.h U sys/net/ppp_comp.h U sys/net/ppp_defs.h U sys/net/ppp_tty.c U sys/net/radix.c U sys/net/radix.h U sys/net/raw_cb.c U sys/net/raw_cb.h U sys/net/raw_usrreq.c U sys/net/route.c U sys/net/route.h U sys/net/rtsock.c U sys/net/slcompress.c U sys/net/slcompress.h U sys/net/slip.h U sys/net/ethernet.h U sys/net/if_mib.c U sys/net/if_mib.h I sys/netinet/CVS U sys/netinet/icmp_var.h U sys/netinet/if_ether.c U sys/netinet/if_ether.h U sys/netinet/if_fddi.h U sys/netinet/igmp.c U sys/netinet/igmp.h U sys/netinet/igmp_var.h U sys/netinet/in.c U sys/netinet/in.h U sys/netinet/in_cksum.c U sys/netinet/in_pcb.c U sys/netinet/in_pcb.h U sys/netinet/in_proto.c U sys/netinet/in_rmx.c U sys/netinet/in_systm.h U sys/netinet/in_var.h U sys/netinet/ip.h U sys/netinet/ip_fw.c U sys/netinet/ip_fw.h U sys/netinet/ip_icmp.c U sys/netinet/ip_icmp.h U sys/netinet/ip_input.c U sys/netinet/ip_mroute.c U sys/netinet/ip_mroute.h U sys/netinet/ip_output.c U sys/netinet/ip_var.h U sys/netinet/raw_ip.c U sys/netinet/tcp.h U sys/netinet/tcp_debug.c U sys/netinet/tcp_debug.h U sys/netinet/tcp_fsm.h U sys/netinet/tcp_input.c U sys/netinet/tcp_output.c U sys/netinet/tcp_seq.h U sys/netinet/tcp_subr.c U sys/netinet/tcp_timer.c U sys/netinet/tcp_timer.h U sys/netinet/tcp_usrreq.c U sys/netinet/tcp_var.h U sys/netinet/tcpip.h U sys/netinet/udp.h U sys/netinet/udp_usrreq.c U sys/netinet/udp_var.h U sys/netinet/ip_divert.c I sys/netipx/CVS U sys/netipx/README U sys/netipx/ipx.c U sys/netipx/ipx.h U sys/netipx/ipx_cksum.c U sys/netipx/ipx_error.c U sys/netipx/ipx_error.h U sys/netipx/ipx_if.h U sys/netipx/ipx_input.c U sys/netipx/ipx_ip.c U sys/netipx/ipx_ip.h U sys/netipx/ipx_outputfl.c U sys/netipx/ipx_pcb.c U sys/netipx/ipx_pcb.h U sys/netipx/ipx_proto.c U sys/netipx/ipx_tun.c U sys/netipx/ipx_usrreq.c U sys/netipx/ipx_var.h U sys/netipx/spx.h U sys/netipx/spx_debug.c U sys/netipx/spx_debug.h U sys/netipx/spx_timer.h U sys/netipx/spx_usrreq.c U sys/netipx/spx_var.h I sys/nfs/CVS U sys/nfs/nfs.h U sys/nfs/nfs_bio.c U sys/nfs/nfs_node.c U sys/nfs/nfs_nqlease.c U sys/nfs/nfs_serv.c U sys/nfs/nfs_socket.c U sys/nfs/nfs_srvcache.c U sys/nfs/nfs_subs.c U sys/nfs/nfs_syscalls.c U sys/nfs/nfs_vfsops.c U sys/nfs/nfs_vnops.c U sys/nfs/nfsdiskless.h U sys/nfs/nfsm_subs.h U sys/nfs/nfsmount.h U sys/nfs/nfsnode.h U sys/nfs/nfsproto.h U sys/nfs/nfsrtt.h U sys/nfs/nfsrvcache.h U sys/nfs/nfsv2.h U sys/nfs/nqnfs.h U sys/nfs/rpcv2.h U sys/nfs/xdr_subs.h I sys/pccard/CVS U sys/pccard/card.h U sys/pccard/cis.h U sys/pccard/driver.h U sys/pccard/i82365.h U sys/pccard/pccard.c U sys/pccard/pcic.c U sys/pccard/skel.c U sys/pccard/slot.h U sys/pccard/pcic98reg.h I sys/pci/CVS U sys/pci/README.de U sys/pci/README.de-le U sys/pci/aic7870.c U sys/pci/bt9xx.c U sys/pci/dc21040.h U sys/pci/if_de.c U sys/pci/if_fxp.c U sys/pci/if_fxpreg.h U sys/pci/if_pdq.c U sys/pci/meteor.c U sys/pci/ncr.c U sys/pci/locate.pl U sys/pci/ncrreg.h U sys/pci/meteor_reg.h U sys/pci/pci.c U sys/pci/pci_ioctl.h U sys/pci/pcibus.h U sys/pci/pcireg.h U sys/pci/pcisupport.c U sys/pci/pcivar.h U sys/pci/pdq.c U sys/pci/pdq_os.h U sys/pci/pdqreg.h U sys/pci/wd82371.c U sys/pci/wd82371reg.h U sys/pci/if_ed_p.c U sys/pci/if_lnc_p.c U sys/pci/cy_pci.c U sys/pci/cy_pcireg.h U sys/pci/if_sr_p.c U sys/pci/if_vx_pci.c I sys/scsi/CVS U sys/scsi/README U sys/scsi/cd.c U sys/scsi/ch.c U sys/scsi/od.c U sys/scsi/pt.c U sys/scsi/scsi_all.h U sys/scsi/scsi_base.c U sys/scsi/scsi_cd.h U sys/scsi/scsi_changer.h U sys/scsi/scsi_debug.h U sys/scsi/scsi_disk.h U sys/scsi/scsi_driver.c U sys/scsi/scsi_driver.h U sys/scsi/scsi_generic.h U sys/scsi/scsi_ioctl.c U sys/scsi/scsi_sense.c U sys/scsi/scsi_tape.h U sys/scsi/scsi_worm.h U sys/scsi/scsiconf.c U sys/scsi/scsiconf.h U sys/scsi/sctarg.c U sys/scsi/sd.c U sys/scsi/ssc.c U sys/scsi/st.c U sys/scsi/su.c U sys/scsi/uk.c U sys/scsi/worm.c U sys/scsi/scsi_message.h I sys/sys/CVS U sys/sys/acct.h U sys/sys/buf.h U sys/sys/callout.h U sys/sys/cdefs.h U sys/sys/cdio.h U sys/sys/chio.h U sys/sys/clist.h U sys/sys/conf.h U sys/sys/dataacq.h U sys/sys/disklabel.h U sys/sys/devfsext.h U sys/sys/device.h U sys/sys/dir.h U sys/sys/dirent.h U sys/sys/disk.h U sys/sys/diskslice.h U sys/sys/dkbad.h U sys/sys/ftape.h U sys/sys/dkstat.h U sys/sys/dmap.h U sys/sys/domain.h U sys/sys/errno.h U sys/sys/exec.h U sys/sys/fbio.h U sys/sys/fcntl.h U sys/sys/file.h U sys/sys/filedesc.h U sys/sys/filio.h U sys/sys/ioctl.h U sys/sys/gmon.h U sys/sys/imgact.h U sys/sys/imgact_aout.h U sys/sys/imgact_elf.h U sys/sys/inflate.h U sys/sys/ioccom.h U sys/sys/mount.h U sys/sys/ioctl_compat.h U sys/sys/ipc.h U sys/sys/kernel.h U sys/sys/ktrace.h U sys/sys/libkern.h U sys/sys/lkm.h U sys/sys/lockf.h U sys/sys/malloc.h U sys/sys/mbuf.h U sys/sys/mman.h U sys/sys/mtio.h U sys/sys/msg.h U sys/sys/msgbuf.h U sys/sys/proc.h U sys/sys/namei.h U sys/sys/param.h U sys/sys/pipe.h U sys/sys/scsiio.h U sys/sys/protosw.h U sys/sys/ptrace.h U sys/sys/queue.h U sys/sys/reboot.h U sys/sys/resource.h U sys/sys/resourcevar.h U sys/sys/rlist.h U sys/sys/rtprio.h U sys/sys/sockio.h U sys/sys/select.h U sys/sys/sem.h U sys/sys/shm.h U sys/sys/signal.h U sys/sys/signalvar.h U sys/sys/snoop.h U sys/sys/socket.h U sys/sys/socketvar.h U sys/sys/stat.h U sys/sys/syscall-hide.h U sys/sys/syscall.h U sys/sys/sysctl.h U sys/sys/sysproto.h U sys/sys/sysent.h U sys/sys/syslimits.h U sys/sys/syslog.h U sys/sys/systm.h U sys/sys/tablet.h U sys/sys/time.h U sys/sys/termios.h U sys/sys/user.h U sys/sys/timeb.h U sys/sys/timers.h U sys/sys/times.h U sys/sys/timex.h U sys/sys/tprintf.h U sys/sys/tty.h U sys/sys/ttychars.h U sys/sys/ttycom.h U sys/sys/ttydefaults.h U sys/sys/ttydev.h U sys/sys/types.h U sys/sys/ucred.h U sys/sys/uio.h U sys/sys/un.h U sys/sys/unistd.h U sys/sys/unpcb.h U sys/sys/vcmd.h U sys/sys/utsname.h U sys/sys/vadvise.h U sys/sys/vnode.h U sys/sys/vlimit.h U sys/sys/vmmeter.h U sys/sys/vnioctl.h U sys/sys/vsio.h U sys/sys/wait.h U sys/sys/wormio.h U sys/sys/ccdvar.h I sys/ufs/CVS I sys/ufs/ffs/CVS U sys/ufs/ffs/ffs_alloc.c U sys/ufs/ffs/ffs_balloc.c U sys/ufs/ffs/ffs_extern.h U sys/ufs/ffs/ffs_inode.c U sys/ufs/ffs/ffs_subr.c U sys/ufs/ffs/ffs_tables.c U sys/ufs/ffs/ffs_vfsops.c U sys/ufs/ffs/ffs_vnops.c U sys/ufs/ffs/fs.h I sys/ufs/lfs/CVS U sys/ufs/lfs/README U sys/ufs/lfs/TODO U sys/ufs/lfs/lfs.h U sys/ufs/lfs/lfs_alloc.c U sys/ufs/lfs/lfs_balloc.c U sys/ufs/lfs/lfs_bio.c U sys/ufs/lfs/lfs_cksum.c U sys/ufs/lfs/lfs_debug.c U sys/ufs/lfs/lfs_extern.h U sys/ufs/lfs/lfs_inode.c U sys/ufs/lfs/lfs_segment.c U sys/ufs/lfs/lfs_subr.c U sys/ufs/lfs/lfs_syscalls.c U sys/ufs/lfs/lfs_vfsops.c U sys/ufs/lfs/lfs_vnops.c I sys/ufs/mfs/CVS U sys/ufs/mfs/mfs_extern.h U sys/ufs/mfs/mfs_vfsops.c U sys/ufs/mfs/mfs_vnops.c U sys/ufs/mfs/mfsiom.h U sys/ufs/mfs/mfsnode.h I sys/ufs/ufs/CVS U sys/ufs/ufs/dinode.h U sys/ufs/ufs/dir.h U sys/ufs/ufs/inode.h U sys/ufs/ufs/quota.h U sys/ufs/ufs/ufs_bmap.c U sys/ufs/ufs/ufs_disksubr.c U sys/ufs/ufs/ufs_extern.h U sys/ufs/ufs/ufs_ihash.c U sys/ufs/ufs/ufs_inode.c U sys/ufs/ufs/ufs_lookup.c U sys/ufs/ufs/ufs_quota.c U sys/ufs/ufs/ufs_readwrite.c U sys/ufs/ufs/ufs_vfsops.c U sys/ufs/ufs/ufs_vnops.c U sys/ufs/ufs/ufsmount.h I sys/vm/CVS U sys/vm/default_pager.c U sys/vm/default_pager.h U sys/vm/device_pager.c U sys/vm/device_pager.h U sys/vm/kern_lock.c U sys/vm/lock.h U sys/vm/pmap.h U sys/vm/swap_pager.c U sys/vm/swap_pager.h U sys/vm/vm.h U sys/vm/vm_extern.h U sys/vm/vm_fault.c U sys/vm/vm_glue.c U sys/vm/vm_inherit.h U sys/vm/vm_init.c U sys/vm/vm_kern.c U sys/vm/vm_kern.h U sys/vm/vm_map.c U sys/vm/vm_map.h U sys/vm/vm_meter.c U sys/vm/vm_mmap.c U sys/vm/vm_object.c U sys/vm/vm_object.h U sys/vm/vm_page.c U sys/vm/vm_page.h U sys/vm/vm_pageout.c U sys/vm/vm_pageout.h U sys/vm/vm_pager.c U sys/vm/vm_pager.h U sys/vm/vm_param.h U sys/vm/vm_prot.h U sys/vm/vm_swap.c U sys/vm/vm_unix.c U sys/vm/vnode_pager.c U sys/vm/vnode_pager.h I sys/netatalk/CVS U sys/netatalk/aarp.c U sys/netatalk/aarp.h U sys/netatalk/at.h U sys/netatalk/at_control.c U sys/netatalk/at_extern.h U sys/netatalk/at_proto.c U sys/netatalk/at_rmx.c U sys/netatalk/at_var.h U sys/netatalk/ddp.h U sys/netatalk/ddp_input.c U sys/netatalk/ddp_output.c U sys/netatalk/ddp_usrreq.c U sys/netatalk/ddp_var.h U sys/netatalk/endian.h U sys/netatalk/phase2.h U sys/netatalk/COPYRIGHT I sys/netns/CVS N sys/netns/idp.h N sys/netns/idp_usrreq.c N sys/netns/idp_var.h N sys/netns/ns.c N sys/netns/ns.h N sys/netns/ns_cksum.c N sys/netns/ns_error.c N sys/netns/ns_error.h N sys/netns/ns_if.h N sys/netns/ns_input.c N sys/netns/ns_ip.c N sys/netns/ns_output.c N sys/netns/ns_pcb.c N sys/netns/ns_pcb.h N sys/netns/ns_proto.c N sys/netns/sp.h N sys/netns/spidp.h N sys/netns/spp_debug.c N sys/netns/spp_debug.h N sys/netns/spp_timer.h N sys/netns/spp_usrreq.c N sys/netns/spp_var.h I sys/pc98/CVS I sys/pc98/boot/CVS N sys/pc98/boot/Makefile I sys/pc98/boot/biosboot/CVS N sys/pc98/boot/biosboot/Makefile N sys/pc98/boot/biosboot/README.386BSD N sys/pc98/boot/biosboot/README.MACH N sys/pc98/boot/biosboot/README.serial N sys/pc98/boot/biosboot/README.serial.98 N sys/pc98/boot/biosboot/asm.S N sys/pc98/boot/biosboot/asm.h N sys/pc98/boot/biosboot/bios.S N sys/pc98/boot/biosboot/boot.c N sys/pc98/boot/biosboot/boot.h N sys/pc98/boot/biosboot/boot2.S N sys/pc98/boot/biosboot/disk.c N sys/pc98/boot/biosboot/io.c N sys/pc98/boot/biosboot/probe_keyboard.c N sys/pc98/boot/biosboot/serial.S N sys/pc98/boot/biosboot/start.S N sys/pc98/boot/biosboot/sys.c N sys/pc98/boot/biosboot/table.c I sys/pc98/boot/kzipboot/CVS N sys/pc98/boot/kzipboot/Makefile N sys/pc98/boot/kzipboot/README N sys/pc98/boot/kzipboot/boot.c N sys/pc98/boot/kzipboot/gzip.h N sys/pc98/boot/kzipboot/head.S N sys/pc98/boot/kzipboot/malloc.c N sys/pc98/boot/kzipboot/misc.c N sys/pc98/boot/kzipboot/tail.S N sys/pc98/boot/kzipboot/unzip.c I sys/pc98/boot/netboot/CVS N sys/pc98/boot/netboot/3c509.c N sys/pc98/boot/netboot/3c509.h N sys/pc98/boot/netboot/Makefile N sys/pc98/boot/netboot/bootmenu.c N sys/pc98/boot/netboot/ether.c N sys/pc98/boot/netboot/ether.h N sys/pc98/boot/netboot/if_epreg.h N sys/pc98/boot/netboot/main.c N sys/pc98/boot/netboot/makerom.c N sys/pc98/boot/netboot/misc.c N sys/pc98/boot/netboot/netboot.doc N sys/pc98/boot/netboot/netboot.h N sys/pc98/boot/netboot/ns8390.c N sys/pc98/boot/netboot/ns8390.h N sys/pc98/boot/netboot/rpc.c N sys/pc98/boot/netboot/start2.S I sys/pc98/boot/rawboot/CVS N sys/pc98/boot/rawboot/Makefile N sys/pc98/boot/rawboot/README I sys/pc98/conf/CVS N sys/pc98/conf/GENERIC98 N sys/pc98/conf/Makefile.pc98 N sys/pc98/conf/devices.pc98 N sys/pc98/conf/files.pc98 N sys/pc98/conf/majors.pc98 N sys/pc98/conf/options.pc98 I sys/pc98/i386/CVS N sys/pc98/i386/locore.s N sys/pc98/i386/machdep.c N sys/pc98/i386/microtime.s N sys/pc98/i386/trap.c N sys/pc98/i386/userconfig.c I sys/pc98/pc98/CVS N sys/pc98/pc98/30line.h N sys/pc98/pc98/atcompat_diskslice.c N sys/pc98/pc98/clock.c N sys/pc98/pc98/diskslice_machdep.c N sys/pc98/pc98/epsonio.h N sys/pc98/pc98/fd.c N sys/pc98/pc98/fdreg.h N sys/pc98/pc98/ft.c N sys/pc98/pc98/if_ed.c N sys/pc98/pc98/if_ed98.h N sys/pc98/pc98/if_fe.c N sys/pc98/pc98/kbd.h N sys/pc98/pc98/lpt.c N sys/pc98/pc98/module.h N sys/pc98/pc98/mse.c N sys/pc98/pc98/npx.c N sys/pc98/pc98/pc98.c N sys/pc98/pc98/pc98.h N sys/pc98/pc98/pc98_machdep.c N sys/pc98/pc98/pc98_machdep.h N sys/pc98/pc98/pcaudio.c N sys/pc98/pc98/sbic55.c N sys/pc98/pc98/sbic55.c.new N sys/pc98/pc98/sbicreg.h N sys/pc98/pc98/sbicvar.h N sys/pc98/pc98/scsireg.h N sys/pc98/pc98/sio.c N sys/pc98/pc98/sioreg.h N sys/pc98/pc98/spkr.c N sys/pc98/pc98/syscons.c N sys/pc98/pc98/syscons.h N sys/pc98/pc98/wd.c No conflicts created by this import From owner-freebsd-smp Fri Nov 22 08:30:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27129 for smp-outgoing; Fri, 22 Nov 1996 08:30:50 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA27118 for ; Fri, 22 Nov 1996 08:30:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id JAA10063 for ; Fri, 22 Nov 1996 09:30:36 -0700 Message-Id: <199611221630.JAA10063@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of "Thu, 21 Nov 1996 18:21:07 MST." <199611220121.SAA05752@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 1996 09:30:35 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Show of hands, please: Who has tried to get the merged 11-20 SMP kernel sources working? Did you suceed in creating a working kernel? If not, how does it fail? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Nov 22 09:34:24 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05378 for smp-outgoing; Fri, 22 Nov 1996 09:34:24 -0800 (PST) Received: from bluenose.na.tuns.ca (bluenose.na.tuns.ca [134.190.50.156]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05337 for ; Fri, 22 Nov 1996 09:34:18 -0800 (PST) Received: (from smp@localhost) by bluenose.na.tuns.ca (8.7.6/8.7.3) id NAA29403; Fri, 22 Nov 1996 13:47:38 -0400 (AST) From: "J.M. Chuang" Message-Id: <199611221747.NAA29403@bluenose.na.tuns.ca> Subject: Re: SMP -current merge To: smp@csn.net (Steve Passe) Date: Fri, 22 Nov 1996 13:47:37 -0400 (AST) Cc: freebsd-smp@freefall.freebsd.org In-Reply-To: <199611221630.JAA10063@clem.systemsix.com> from Steve Passe at "Nov 22, 96 09:30:35 am" X-Mailer: ELM [version 2.4ME+ PL13 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 1. For smp kernel + pcvt (not syscons), it works but the system rebooted as soon as the 2nd cpu launched. Besides, in the high load condition, the system with one active cpu) freezes. 2. For smp kernel + syscons, the response of the keyborad is not correct. These are for APIC_IO + APIC_LAZY kernel running in Tyan Tomcat III and Tyan Titan Pro. (smp kernel source supped lastnight, Nov. 21) Jim > Hi, > > Show of hands, please: > > Who has tried to get the merged 11-20 SMP kernel sources working? > > Did you suceed in creating a working kernel? > > If not, how does it fail? > > -- > Steve Passe | powered by > smp@csn.net | FreeBSD > > From owner-freebsd-smp Fri Nov 22 09:41:37 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05899 for smp-outgoing; Fri, 22 Nov 1996 09:41:37 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA05891 for ; Fri, 22 Nov 1996 09:41:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA10411; Fri, 22 Nov 1996 10:41:12 -0700 Message-Id: <199611221741.KAA10411@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "J.M. Chuang" cc: freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of "Fri, 22 Nov 1996 13:47:37 -0400." <199611221747.NAA29403@bluenose.na.tuns.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 1996 10:41:12 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jim, > > Who has tried to get the merged 11-20 SMP kernel sources working? > > > 1. For smp kernel + pcvt (not syscons), it works but the system rebooted as soon as > the 2nd cpu launched. Besides, in the high load condition, the system with one > active cpu) freezes. > > 2. For smp kernel + syscons, the response of the keyborad is not correct. > > These are for APIC_IO + APIC_LAZY kernel running in Tyan Tomcat III and Tyan Titan Pro. > > (smp kernel source supped lastnight, Nov. 21) Thanx for the report. At least I'm not the only one! What I've tried so far (without fixing anything: backed out pmap.c backed out support.c The syscons lock can be fixed by grabbing the versions of console.h and syscons.c if freefall.freebsd.org:/incoming/files1.tar.gz -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Fri Nov 22 19:50:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06863 for smp-outgoing; Fri, 22 Nov 1996 19:50:58 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06857 for ; Fri, 22 Nov 1996 19:50:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id UAA13108; Fri, 22 Nov 1996 20:50:46 -0700 Message-Id: <199611230350.UAA13108@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org cc: "John S. Dyson" Subject: Re: SMP -current merge Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 1996 20:50:46 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Additional clues on SMP brokeness. I added this patch to kern/init_main.c:smp_idle(): ----------------------------------- cut -------------------------------------- *** init_main.c 1996/11/22 18:04:29 1.1 --- init_main.c 1996/11/22 20:30:00 *************** *** 812,817 **** --- 812,835 ---- rel_mplock(); } + #if 1 + if (smp_active == 2 && cpunumber() != 0) { + get_mplock(); + printf("cpu#%d spinning; mp_lock: %08x\n", cpunumber(), + mp_lock); + wakeup((caddr_t)&smp_active); + rel_mplock(); + + while (smp_active == 2) { + __asm __volatile("" : : : "memory"); + } + get_mplock(); + printf("cpu#%d waking up! mp_lock: %08x\n", cpunumber(), + mp_lock); + rel_mplock(); + } + #endif /** 1 */ + if (whichqs || whichrtqs || whichidqs) { /* grab lock for kernel "entry" */ ----------------------------------- cut -------------------------------------- What it does is "freeze" the 2nd CPU after it has initialized itself and is about to run its first proc. When I start it via "sysctl kern.smp_active=2" it gets to this point without hurting the system. The first CPU returns from the sysctl, and I can continue to use the system without reboot. If I allow the 2nd CPU to exit this freeze via "sysctl kern.smp_active=3" I get the prompt back, but, as before, the first action causes a REBOOT. If I change: + if (smp_active == 2 && cpunumber() != 0) { to: + if (smp_active == 2 && cpunumber() == 0) { it works differently. This change causes the 1st CPU to be the one frozen, ie the 2nd CPU is now the only one running. I cannot do anything else after the sysctl returns without REBOOTing. Ie, its NOT that 2 CPUs are running, its the running of the 2nd CPU that REBOOTs. So it appears that the 2nd CPU is not getting a correct environment in which to run anymore. Could this be something different in the VM system? It appears to have changed alot since the last merge. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 11:22:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08802 for smp-outgoing; Sat, 23 Nov 1996 11:22:43 -0800 (PST) Received: from knight.cons.org (knight.cons.org [194.233.237.86]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA08797 for ; Sat, 23 Nov 1996 11:22:37 -0800 (PST) Received: (from cracauer@localhost) by knight.cons.org (8.7.5/8.7.3) id UAA08217; Sat, 23 Nov 1996 20:24:49 +0100 (MET) Date: Sat, 23 Nov 1996 20:24:49 +0100 (MET) Message-Id: <199611231924.UAA08217@knight.cons.org> From: Martin Cracauer To: freebsd-smp@freebsd.org Subject: Thread issues Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's maybe a little too early to discuss it, but what are the plans for MP-capable threads? The Linux folks decided to dump their previous thread packages (4, if I remember right) and have just a clone(2)-based kernel thread package. They claim they reduced the minimum syscall time to an extend that pure kernel-threads are the best choice. clone() is very similar to FreeBSD's rfork(). I looked into their pthread layer above clone() package at ftp://alpha.gnu.ai.mit.edu/gnu/linuxthreads-960922.tar.gz and it looks the thing can be easily used (or reimplemented) to have a pthread package on top of rfork(). The main Linux dependency in this package is the interfaces to the Linux sheduler. I'd like to ask a few questions and hope some people people with more experience than mine could drop me a note: Do you think that Linus' view could be applicable to FreeBSD, too? That it would be sufficient to have one pure thread library using rfork() only? How much overhead would be involved? As I understand, the biggest issue will be context switch time when a thread hits a locked mutex. Anyone has some numbers handy how often this happens in a typical pthread application, expressed in lock hits/CPU instruction? Having only kernel threads on FreeBSD causes some additional problems, i.e., there's no userlevel code left to handle Posix signal delivering specification. To solve this problem, Linux is about to extend their clone() call with an option to share the pid between mother and child. In addition, some new pid-like variable for each kernel 'execution context' (to name it) will be introduced. Do you think the FreeBSD community would be open to such a rather radical change? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer cracauer@wavehh.hanse.de (batched, preferred for large mails) Tel.: (daytime) +4940 41478712 (sometimes hacker's daytime :-) Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany From owner-freebsd-smp Sat Nov 23 13:47:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14938 for smp-outgoing; Sat, 23 Nov 1996 13:47:28 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA14930 for ; Sat, 23 Nov 1996 13:47:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA19699; Sat, 23 Nov 1996 14:47:16 -0700 Message-Id: <199611232147.OAA19699@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org cc: Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Fri, 22 Nov 1996 20:50:46 MST." <199611230350.UAA13108@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 14:47:16 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I think I just made an important breakthru on SMP efficiency. It has always bugged me that many things take longer to do with 2 CPUs running than with just 1 active. While looking for the current SMP "brokenness" (still haven't got a clue...) I noticed in sys/kern/init_main.c:smp_idleloop() the line: if (whichqs || whichrtqs || whichidqs) { appears to look in the queue of idle procs. my debugs seem to show the 2nd CPU switching back and forth from one idle proc to the other as a result. It appears that the 2nd CPU is spending ALOT of time grabbing the lock, switching idle procs, and releaseing the lock again! This seems like it is both unnecessary and wasting bus cycles. So I added the following patc (to the older, NON-broken SMP src): ---------------------------------- cut --------------------------------------- *** init_main.c~ Fri Nov 1 22:50:41 1996 --- init_main.c Sat Nov 23 12:29:17 1996 *************** *** 839,845 **** rel_mplock(); } ! if (whichqs || whichrtqs || whichidqs) { /* grab lock for kernel "entry" */ get_mplock(); --- 839,845 ---- rel_mplock(); } ! if (whichqs || whichrtqs) { /* grab lock for kernel "entry" */ get_mplock(); *************** *** 847,853 **** /* We need to retest due to the spin lock */ __asm __volatile("" : : : "memory"); ! if (whichqs || whichrtqs || whichidqs){ splhigh(); if (curproc) setrunqueue(curproc); --- 847,853 ---- /* We need to retest due to the spin lock */ __asm __volatile("" : : : "memory"); ! if (whichqs || whichrtqs) { splhigh(); if (curproc) setrunqueue(curproc); ---------------------------------- cut --------------------------------------- --- Summary of kernel build times: 1 CPU active, non SMP kernel, for reference: 446.65s real 337.68s user 22.54s system 2 CPUs active, idlequeue search in smp_idleloop(), ie before patch: 597.45s real 373.91s user 147.68s system 2 CPUs active, NO idlequeue search in smp_idleloop(), ie after patch: 433.87s real 332.11s user 44.69s system Now it seems to be working like you would expect!!! --- And some times with PARALLEL make: 2 CPUs active, NO idlequeue search in smp_idleloop(): # time make -j 2 ... 326.28s real 400.29s user 67.71s system Note that we get 400s of user time in 326s of real time!!! # time make -j 3 This dies, I think its a PARALLELISM problem: --- param.c --- --- aic7xxx_asm --- --- genassym.o --- rm -f param.c --- param.c --- cp ../../conf/param.c . --- aic7xxx_asm --- cc -Wall -o aic7xxx_asm ../../dev/aic7xxx/aic7xxx_asm.c --- cd9660_bmap.o --- --- genassym.o --- cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I/usr/include -DFAILSAFE -DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DMY_DEBUG -DKERNEL -DMAXUSERS=64 -UKERNEL ../../i386/i386/genassym.c --- cd9660_bmap.o --- cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I/usr/include -DFAILSAFE -DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DMY_DEBUG -DKERNEL ../../isofs/cd9660/cd9660_bma p.c vnode_if.h: In function `VOP_FSYNC': In file included from ../../sys/vnode.h:379, from ../../isofs/cd9660/cd9660_bmap.c:46: vnode_if.h:403: parse error before `struct' vnode_if.h:408: warning: control reaches end of non-void function ... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Nov 23 14:19:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15913 for smp-outgoing; Sat, 23 Nov 1996 14:19:45 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA15901 for ; Sat, 23 Nov 1996 14:19:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA01895; Sat, 23 Nov 1996 14:17:52 -0800 (PST) Message-Id: <199611232217.OAA01895@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 14:47:16 MST." <199611232147.OAA19699@clem.systemsix.com> From: David Greenman Reply-To: dg@Root.COM Date: Sat, 23 Nov 1996 14:17:52 -0800 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think I just made an important breakthru on SMP efficiency. It has always >bugged me that many things take longer to do with 2 CPUs running than with >just 1 active. While looking for the current SMP "brokenness" (still haven't >got a clue...) I noticed in sys/kern/init_main.c:smp_idleloop() the line: > > if (whichqs || whichrtqs || whichidqs) { > >appears to look in the queue of idle procs. my debugs seem to show >the 2nd CPU switching back and forth from one idle proc to the other >as a result. It appears that the 2nd CPU is spending ALOT of >time grabbing the lock, switching idle procs, and releaseing the lock >again! This seems like it is both unnecessary and wasting bus cycles. Uhh, the "idle" queue shouldn't have anything on it unless there is an "idprio" process running. If this patch truely makes a difference, then there is something very wrong with the handling of whichidqs somewhere. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Sat Nov 23 14:31:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16294 for smp-outgoing; Sat, 23 Nov 1996 14:31:49 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16289 for ; Sat, 23 Nov 1996 14:31:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA19920; Sat, 23 Nov 1996 15:31:29 -0700 Message-Id: <199611232231.PAA19920@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: dg@Root.COM cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 14:17:52 PST." <199611232217.OAA01895@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 15:31:29 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Uhh, the "idle" queue shouldn't have anything on it unless there is an >"idprio" process running. If this patch truely makes a difference, then >there is something very wrong with the handling of whichidqs somewhere. If there are 2 CPUS smp_kickoff() creates 2 idleprocs, and thus there are 2 possible processess that can be in the idleq. When there are no rtq procs and no norq procs to run, the 1st CPU is inside smp_idleloop of cpuidleX, and the 2nd CPU is in smp_idleloop of cpuidleY, and thus there are no procs in the idleq. When the 1st CPU is busy doing something usefull (running something other than an idleproc), the 2nd CPU will be in smp_idleloop of either cpuidleX or cpuidleY, and the other cpuidle[XY] will be in the idleq. So the 2nd CPU sees the idleproc that it ISN'T currently in and switches to that one, and on and on .... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 14:46:42 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16799 for smp-outgoing; Sat, 23 Nov 1996 14:46:42 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA16794 for ; Sat, 23 Nov 1996 14:46:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA01965; Sat, 23 Nov 1996 14:44:48 -0800 (PST) Message-Id: <199611232244.OAA01965@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 15:31:29 MST." <199611232231.PAA19920@clem.systemsix.com> From: David Greenman Reply-To: dg@Root.COM Date: Sat, 23 Nov 1996 14:44:48 -0800 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hi, > >> Uhh, the "idle" queue shouldn't have anything on it unless there is an >>"idprio" process running. If this patch truely makes a difference, then >>there is something very wrong with the handling of whichidqs somewhere. > >If there are 2 CPUS smp_kickoff() creates 2 idleprocs, and thus there >are 2 possible processess that can be in the idleq. Oh...I didn't realize that it was handled this way. This is going to need to be re-thought. The idle processes should probably not be on any of the queues and handled as a special case. Otherwise they will compete for CPU with other idprio processes, and that would be bad. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Sat Nov 23 14:54:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17101 for smp-outgoing; Sat, 23 Nov 1996 14:54:08 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA17095 for ; Sat, 23 Nov 1996 14:53:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA20073; Sat, 23 Nov 1996 15:53:51 -0700 Message-Id: <199611232253.PAA20073@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: dg@Root.COM cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 14:44:48 PST." <199611232244.OAA01965@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 15:53:50 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >>If there are 2 CPUS smp_kickoff() creates 2 idleprocs, and thus there >>are 2 possible processess that can be in the idleq. > > Oh...I didn't realize that it was handled this way. This is going to need >to be re-thought. The idle processes should probably not be on any of the >queues and handled as a special case. Otherwise they will compete for CPU >with other idprio processes, and that would be bad. ^^^^^^^^^^^^^^^^^^^^^^ perhaps I'm incorrect in my thinking here, I thought the idleq was strictly for the cpuidle[ NCPU ] processes. What other "idle" processes are there? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 15:25:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18032 for smp-outgoing; Sat, 23 Nov 1996 15:25:48 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA18020 for ; Sat, 23 Nov 1996 15:25:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id PAA02050; Sat, 23 Nov 1996 15:23:25 -0800 (PST) Message-Id: <199611232323.PAA02050@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 15:53:50 MST." <199611232253.PAA20073@clem.systemsix.com> From: David Greenman Reply-To: dg@Root.COM Date: Sat, 23 Nov 1996 15:23:25 -0800 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hi, > >>>If there are 2 CPUS smp_kickoff() creates 2 idleprocs, and thus there >>>are 2 possible processess that can be in the idleq. >> >> Oh...I didn't realize that it was handled this way. This is going to need >>to be re-thought. The idle processes should probably not be on any of the >>queues and handled as a special case. Otherwise they will compete for CPU >>with other idprio processes, and that would be bad. > ^^^^^^^^^^^^^^^^^^^^^^ > >perhaps I'm incorrect in my thinking here, I thought the idleq was strictly >for the cpuidle[ NCPU ] processes. What other "idle" processes are there? "man idprio" idprio is a compliment to rtprio. It was an idea I had back when the rtprio code was first submitted. I've always hated "nice" because it was never possible to say "run this process _only_ if nothing else is runnable". -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Sat Nov 23 15:40:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18657 for smp-outgoing; Sat, 23 Nov 1996 15:40:27 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA18650 for ; Sat, 23 Nov 1996 15:40:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA20297; Sat, 23 Nov 1996 16:40:05 -0700 Message-Id: <199611232340.QAA20297@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: dg@Root.COM cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 15:23:25 PST." <199611232323.PAA02050@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 16:40:05 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > "man idprio" > > idprio is a compliment to rtprio. It was an idea I had back when the >rtprio code was first submitted. I've always hated "nice" because it was >never possible to say "run this process _only_ if nothing else is runnable". Ok, so something does need to change. as most of us probably never run anything at idleprio the patch I submitted is better than nothing. Possibilities: a 4th queue that is just for cpuidle[ NCPU ] procs. ??? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 16:43:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA20651 for smp-outgoing; Sat, 23 Nov 1996 16:43:28 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA20636 for ; Sat, 23 Nov 1996 16:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA20563; Sat, 23 Nov 1996 17:43:09 -0700 Message-Id: <199611240043.RAA20563@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: dg@Root.COM cc: freebsd-smp@freefall.freebsd.org, Peter Wemm Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 15:23:25 PST." <199611232323.PAA02050@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 17:43:09 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I have tested the times reported by "time make" against a stopwatch, and they are accurate to within 0.5 second. I was surprised to see increasingly better times beyond "-j 2". I guess this is from parallelism on the disk accesses, ie when both CPUs are waiting for disk IO on a particular object build, there is another they can work on if jobs > 2. The point of diminishing returns seems to be around 8 jobs. ------------------------------ Summary of kernel build times: --- 1 CPU active, non SMP kernel: # time make: 446.65s real 337.68s user 22.54s system --- 2 CPUs active, idlequeue search in smp_idleloop(): # time make: 597.45s real 373.91s user 147.68s system --- 2 CPUs active, NO idlequeue search in smp_idleloop(): # time make: 433.87s real 332.11s user 44.69s system # time make -j 2: 326.28s real 400.29s user 67.71s system # time make -j 3: 293.41s real 420.08s user 77.28s system # time make -j 4: 285.10s real 425.32s user 79.71s system # time make -j 5: 277.74s real 428.25s user 78.97s system # time make -j 6: 276.35s real 429.64s user 80.22s system # time make -j 7: 274.97s real 432.54s user 80.01s system # time make -j 8: 274.53s real 431.80s user 81.16s system # time make -j 9: 276.46s real 433.53s user 81.20s system -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 17:29:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA21793 for smp-outgoing; Sat, 23 Nov 1996 17:29:01 -0800 (PST) Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA21787 for ; Sat, 23 Nov 1996 17:28:57 -0800 (PST) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id RAA20785; Sat, 23 Nov 1996 17:28:26 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id RAA28719; Sat, 23 Nov 1996 17:28:10 -0800 (PST) Date: Sat, 23 Nov 1996 17:28:10 -0800 (PST) Message-Id: <199611240128.RAA28719@chimp.jnx.com> From: Tony Li To: smp@csn.net (Steve Passe) Cc: freebsd-smp@freefall.freebsd.org, Peter Wemm In-reply-to: smp@csn.net's message of 24 Nov 96 00:43:09 GMT Subject: Re: SMP -current merge References: <199611232323.PAA02050@root.com> <199611240043.RAA20563@clem.systemsix.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have tested the times reported by "time make" against a stopwatch, and they are accurate to within 0.5 second. I was surprised to see increasingly better times beyond "-j 2". I guess this is from parallelism on the disk accesses, ie when both CPUs are waiting for disk IO on a particular object build, there is another they can work on if jobs > 2. The point of diminishing returns seems to be around 8 jobs. That's entirely consistent with the behavior of other SMP systems (e.g., Solbournes). The optimal point increases with your compute/IO ratio. For an 8 processor Solbourne, I normally used -j 11. Note that the -l flag to Gnu Make is what one would _like_ to use to insure a consistent load level. Unfortunately, it's implementation doesn't exhibit enough damping, so you get feast or famine. ;-( Tony From owner-freebsd-smp Sat Nov 23 17:35:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA22161 for smp-outgoing; Sat, 23 Nov 1996 17:35:50 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA22152; Sat, 23 Nov 1996 17:35:46 -0800 (PST) Message-Id: <199611240135.RAA22152@freefall.freebsd.org> To: Martin Cracauer cc: freebsd-smp@freebsd.org Subject: Re: Thread issues In-reply-to: Your message of "Sat, 23 Nov 1996 20:24:49 +0100." <199611231924.UAA08217@knight.cons.org> Date: Sat, 23 Nov 1996 17:35:45 -0800 From: "Justin T. Gibbs" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Having played with threads under NT, I must say that I find its APIs both clean and easy to use. I wonder if we should take a step back and consider what would be the best interface to supply for our users even if it vastly differs from a "conventional UNIX thread" implementation. We can always provide POSIX APIs on top of FreeBSD's native thread APIs. Threads and AIO are two features that the people doing embedded systems with FreeBSD really want. In most cases, they are interested in performance and time to market, not portability, so designing our own interfaces would not hinder their efforts. In fact, a cleaner, more logical set of APIs may reduce their TTM and make FreeBSD even more viable in this arena. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Sat Nov 23 18:26:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA23669 for smp-outgoing; Sat, 23 Nov 1996 18:26:44 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA23659 for ; Sat, 23 Nov 1996 18:26:38 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id KAA24610; Sun, 24 Nov 1996 10:26:09 +0800 (WST) Message-Id: <199611240226.KAA24610@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: dg@Root.COM, freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of "Sat, 23 Nov 1996 16:40:05 MST." <199611232340.QAA20297@clem.systemsix.com> Date: Sun, 24 Nov 1996 10:26:08 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > > "man idprio" > > > > idprio is a compliment to rtprio. It was an idea I had back when the > >rtprio code was first submitted. I've always hated "nice" because it was > >never possible to say "run this process _only_ if nothing else is runnable". > > Ok, so something does need to change. as most of us probably never run > anything at idleprio the patch I submitted is better than nothing. > > Possibilities: > > a 4th queue that is just for cpuidle[ NCPU ] procs. > > ??? No, it needs to be done correctly. This means that we need to have the CPU's call mi_switch()/cpu_switch() and if no runnable jobs are available then they need to halt or busy spin. halting is preferable, but that needs IPI's fully working with handlers to deal with them etc. The idle processes will not exist. Presently, the idle "process" is implented in the normal kernel via a partial process context, it's PTD is IdlePTD. It doesn't have a struct proc, but it does have it's own user area and stack. This is all hard-coded into the VM system's bootup. Do do things "right", we need to be able to make NCPU of these (or better still, one for each "found" and "enabled" cpu, since it's 12KB of kernel memory per idle proc). BTW, as as a general goal, we want to have as little as possible references to NCPU (or MAXCPU as it would be more correctly called). It would be just great to not need it at all, but I suspect there will be some cases where it'd be required for the few pointers to the per-cpu space we'd need. To "fix" this, I see something like this being the solution... Instead of having globals replaced with arrays, eg: struct proc *SMPcurproc[NCPU]; and #define curproc (SMPcurproc[cpunumbner()]), we need to move all these per-cpu global variables into a seperate VM page. So, it'll become "extern struct proc *curproc", and whichever cpu is running will see it's own version. To pull this off, we need a private per-cpu top-level page table directory entry pointing to a mostly empty 4K page directory entry (have I got the terminology the right way around?). In the per-cpu 4K page map, there is one mapping to the private "data" page, one mapping for the local apic, one for the IO apic(s). And here's the cute part.. We can store the cpunumber in the per-cpu data page, eliminating the need to read the APIC_ID register over and over again and all the shifting/masking and table lookups. When cpu_switch() changes the process context, it simply copies the per-cpu PTDE from the old process context into the new processes PTD, so the private pages stay with the current cpu.. hence there is never any need to read the APIC_ID after going online. I have other crazy ideas about certain problems too.. :-) Re: the scheduling problems and trying to avoid processes bouncing between cpu's which is critically important for P6's with no shared L3 cache. Presently, there is a routine called schedule() which is run 10 times/sec, or sooner if it's needed. This builds the 32 run queues, handles priorities, niceness, etc etc. The mi_switch()/cpu_switch() routines simply pick the first runnable job from the highest run queue. This is nice and quick, but it means the priorities are adjusted every 1/10 second or so rather than every context switch. We can use this to our advantage in the SMP case by having a seperate set of 32 RT run queues for each cpu... A cpu can still call a global reschedule to adjust the contents of the run queues, and they are redone every hz/10 as already. This means that the schedule() routine can take the "last cpu" of the process into consideration when assigning jobs amongst the cpus. I'm sure there are a zillion more effective ways of doing this (and I'll bet Terry will point out at least one. :-), but this is "easy" and will reduce a good deal of the problem for a small number of cpus which is a good short term goal. Once we have a reentrant kernel and can realistically support more than 4 or 8 cpus without them all bogging down in spin locks, then it would be worth doing something better. Cheers, -Peter From owner-freebsd-smp Sat Nov 23 20:54:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27954 for smp-outgoing; Sat, 23 Nov 1996 20:54:13 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA27948 for ; Sat, 23 Nov 1996 20:54:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id VAA21729 for ; Sat, 23 Nov 1996 21:54:03 -0700 Message-Id: <199611240454.VAA21729@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freefall.freebsd.org Subject: Re: SMP -current merge In-reply-to: Your message of "Sun, 24 Nov 1996 11:09:44 +0800." <199611240309.LAA24845@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Nov 1996 21:54:03 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi gang, I found it!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- The problem was in machdep.c: someone realized that r_gdt and r_idt were only used locally and moved them from global scope to local scope. Unfortunately rcsmerge (I assumme) retained the global copy. mp_machdep.c:init_secondary() uses the global ones, which are now NOT initialized by init386()! this patch fixes the problem: ------------------------------------ cut -------------------------------- *** i386/i386/machdep.c~ 1996/11/24 03:55:31 --- i386/i386/machdep.c 1996/11/24 03:57:18 *************** *** 989,996 **** --- 989,998 ---- struct gate_descriptor *gdp; int gsel_tss; struct isa_device *idp; + #if 0 /** FIXME: this is what broke the 11-20 merge */ /* table descriptors - used to load tables by microp */ struct region_descriptor r_gdt, r_idt; + #endif /** 0 */ int pagesinbase, pagesinext; int target_page, pa_indx; #ifdef SMP ------------------------------------ cut -------------------------------- In addition to this patch you do need to replace syscons.c and console.h to make the 11-21 sources work. These files can be found in freefall:/incoming/files1.tar.gz. Ignore the icu.s and vector.s files in that tar, I don't think they're needed. Alternately you can revert to rev 1.186 of i386/isa/syscons.c and rev 1.25 of i386/include/console.h I have tested non-APIC_IO, APIC_IO, & APIC_IO-LAZY, all seem to work. I need to do a lot of cleanup and further testing b4 I officially commit this stuff, but the above changes should get you back in business. I will hit it hard tomorrow and try to get everything properly tested and committed by the end of the day. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 23 21:52:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA29953 for smp-outgoing; Sat, 23 Nov 1996 21:52:15 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA29946 for freebsd-smp; Sat, 23 Nov 1996 21:52:13 -0800 (PST) Date: Sat, 23 Nov 1996 21:52:13 -0800 (PST) From: Peter Wemm Message-Id: <199611240552.VAA29946@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/23 21:52:13 Modified: i386/i386 machdep.c Log: Fix the accidental shadowing of the r_gdt and i_gdt variables that caused the second cpu to fault and reboot the system when turning on the second cpu. It was getting the uninitialised globals.. Found by: Steve Passe Revision Changes Path 1.30 +0 -2 sys/i386/i386/machdep.c