From owner-freebsd-smp Sun Sep 29 00:11:07 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA12781 for smp-outgoing; Sun, 29 Sep 1996 00:11:07 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA12725 for freebsd-smp; Sun, 29 Sep 1996 00:11:03 -0700 (PDT) Date: Sun, 29 Sep 1996 00:11:03 -0700 (PDT) From: Steve Passe Message-Id: <199609290711.AAA12725@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/conf files.i386 sys/i386/i386 mp_machdep.c mpapic.c mpcore.c locore.s machdep.c pmap.c mpcore.s sys/i386/include apic.h mpasm.h smp.h smpasm.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/09/29 00:11:02 Modified: i386/conf files.i386 Log: for option smp: replaced mpcore.s with mpcore.c added mpapic.c and mp_machdep.c Revision Changes Path 1.7 +4 -2 sys/i386/conf/files.i386 Modified: i386/i386 locore.s machdep.c pmap.c Added: i386/i386 mp_machdep.c mpapic.c mpcore.c Removed: i386/i386 mpcore.s Log: general cleanup replace mpcore.s with mpcore.c added apic support with mpapic.c additional SMP startup routines in mp_machdep.c parse MP table for CPU and IO APIC IDs, and for APIC addresses. support sparse/un-ordered CPU/IO APIC numbering. Revision Changes Path 1.26 +1 -6 sys/i386/i386/locore.s 1.22 +98 -73 sys/i386/i386/machdep.c 1.19 +41 -14 sys/i386/i386/pmap.c Modified: i386/include apic.h mpasm.h smp.h smpasm.h Log: general cleanup #defines for IO APIC. macros for SPARSE/un-ordered APIC IDs. #defines for MP table parse. Revision Changes Path 1.3 +164 -10 sys/i386/include/apic.h 1.13 +6 -1 sys/i386/include/mpasm.h 1.8 +23 -2 sys/i386/include/smp.h 1.5 +6 -5 sys/i386/include/smpasm.h From owner-freebsd-smp Sun Sep 29 01:36:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA13550 for smp-outgoing; Sun, 29 Sep 1996 01:36:33 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA13518 for freebsd-smp; Sun, 29 Sep 1996 01:36:28 -0700 (PDT) Date: Sun, 29 Sep 1996 01:36:28 -0700 (PDT) From: Peter Wemm Message-Id: <199609290836.BAA13518@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c kern_shutdown.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/09/29 01:36:27 Modified: kern init_main.c kern_shutdown.c Log: Attempt to fix the boot() problems in obtaining cpu#0, as pointed out by: Hidetoshi Shimokawa I'm not 100% sure I've got this right, cpunumber() now returns a logical cpu id, doesn't it? Steve?? Therefore, the boot cpu logical id is always zero, right?? :-) I've got to run, somebody else feel free to fix this if I've botched it. Revision Changes Path 1.22 +6 -4 sys/kern/init_main.c 1.4 +15 -9 sys/kern/kern_shutdown.c From owner-freebsd-smp Sun Sep 29 02:22:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09829 for smp-outgoing; Sun, 29 Sep 1996 02:22:31 -0700 (PDT) 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 CAA09746; Sun, 29 Sep 1996 02:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id DAA17778; Sun, 29 Sep 1996 03:22:15 -0600 Message-Id: <199609290922.DAA17778@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/kern init_main.c kern_shutdown.c In-reply-to: Your message of "Sun, 29 Sep 1996 01:36:28 PDT." <199609290836.BAA13518@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Sep 1996 03:22:14 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Peter said: > Modified: kern init_main.c kern_shutdown.c > Log: > Attempt to fix the boot() problems in obtaining cpu#0, as pointed out > by: Hidetoshi Shimokawa > > I'm not 100% sure I've got this right, cpunumber() now returns a logical > cpu id, doesn't it? Steve?? Therefore, the boot cpu logical id is always > zero, right?? :-) yes, this is correct. The BSP (Boot Strap Processor) is always logical #0. APs (Application Processors) follow in logical order 1,2,3,n. These are the numbers returned by 'cpunumber()' and 'GETPROCID()'. If you need the actual APIC ID of a logical CPU, use 'CPU_TO_ID( logical# )'. Inversly, to get the logical # from an APIC ID use 'ID_TO_CPU( physical# )'. These values are now parsed from the MP table during boot, supporting machines with SPARSE and/or un-ordered CPU/IO APIC ID numbering (most P6 machines). It also supports non-standard APIC addresses. Note that we are a long way from supporting more than 2 CPUs, ie. if you try to set NCPU=4 it will probably go down in flames. I'll check the patch in a moment and confirm. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Sep 29 02:38:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA19850 for smp-outgoing; Sun, 29 Sep 1996 02:38:05 -0700 (PDT) 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 CAA19774; Sun, 29 Sep 1996 02:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id DAA17864; Sun, 29 Sep 1996 03:37:55 -0600 Message-Id: <199609290937.DAA17864@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/kern init_main.c kern_shutdown.c In-reply-to: Your message of "Sun, 29 Sep 1996 03:22:14 MDT." <199609290922.DAA17778@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Sep 1996 03:37:55 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >> I'm not 100% sure I've got this right, cpunumber() now returns a logical >> cpu id, doesn't it? Steve?? Therefore, the boot cpu logical id is always >> zero, right?? :-) > ... >I'll check the patch in a moment and confirm. works well, the SMP kernel no longer hangs on sync during halt/reboot! -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Sep 29 04:13:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA18084 for smp-outgoing; Sun, 29 Sep 1996 04:13:06 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA18031 for ; Sun, 29 Sep 1996 04:13:00 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id MAA11926 for smp@freebsd.org; Sun, 29 Sep 1996 12:00:35 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id MAA24184 for ; Sun, 29 Sep 1996 12:03:49 +0200 (MET DST) Date: Sun, 29 Sep 1996 12:03:49 +0200 (MET DST) From: Andreas Klemm To: smp@freebsd.org Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How stable is the smp support. Did it ever blow up someones machine, crashing the superblock, ... I think about getting a smp board as the tomcat II but am not sure if I should perhaps wait a bit ?! Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Sun Sep 29 05:01:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA18915 for smp-outgoing; Sun, 29 Sep 1996 05:01:11 -0700 (PDT) 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 FAA18845 for ; Sun, 29 Sep 1996 05:01:05 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id UAA01014; Sun, 29 Sep 1996 20:00:47 +0800 (WST) Message-Id: <199609291200.UAA01014@spinner.DIALix.COM> To: Andreas Klemm cc: smp@freebsd.org In-reply-to: Your message of "Sun, 29 Sep 1996 12:03:49 +0200." Date: Sun, 29 Sep 1996 20:00:47 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm wrote: > How stable is the smp support. > Did it ever blow up someones machine, crashing the superblock, ... > > I think about getting a smp board as the tomcat II but am not sure > if I should perhaps wait a bit ?! > > Andreas /// Well, based on what we now know about things that we don't do, I'm a little amazed that it's working as well as it seems to be in general. We are not doing TLB invalidation of other cpu's into account when modifying other processes page tables (which are possibly running on another cpu). This is a time-bomb that will affect low-memory or otherwise memory starved systems far worse than those that have plenty. (I run on 48M of ram and don't see it at all for days. I would expect 16M systems would be pretty bumpy.) The risk is probably exponentially proportional to the page-stealing rate. Although I've not heard of it happening, I would not be suprised if it can cause disk corruption, because one processor may have a read/write page in it's TLB on a running process in usermode, and the other cpu could enter the kernel, change that running processes page table to reclaim the page and assign it to a disk buffer or something. The running processor would be unaware that the physical page has been reclaimed (it's in it's TLB) and would allow the user process to modify the physical page as if it was it's data segment, even though it's been reallocated to a disk buffer or another process. I guess this means that I'm not reccomending it for a "production" system somewhere, although it's usually fine for hacking on if you've got ram. Cheers, -Peter From owner-freebsd-smp Sun Sep 29 05:49:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA02783 for smp-outgoing; Sun, 29 Sep 1996 05:49:23 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA02722 for freebsd-smp; Sun, 29 Sep 1996 05:49:19 -0700 (PDT) Date: Sun, 29 Sep 1996 05:49:19 -0700 (PDT) From: Peter Wemm Message-Id: <199609291249.FAA02722@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/09/29 05:49:18 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 960929 Status: Vendor Tag: CURRENT Release Tags: v960929 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/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 U sys/gnu/i386/isa/nic3008.c U sys/gnu/i386/isa/nic3008.h U sys/gnu/i386/isa/nic3009.c U sys/gnu/i386/isa/nic3009.h U sys/gnu/i386/isa/niccyreg.h I sys/gnu/isdn/CVS U sys/gnu/isdn/if_ii.c U sys/gnu/isdn/iispy.c U sys/gnu/isdn/iitel.c U sys/gnu/isdn/iitty.c U sys/gnu/isdn/isdn.c U sys/gnu/isdn/isdn_ioctl.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 N sys/i386/boot/rawboot/Makefile N 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 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 C 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 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 U 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 C 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 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 C 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/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 C 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/types.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 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/kbd.h 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 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 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 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 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 N sys/i386/isa/ic/i8251.h N 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/pas.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/sb.h 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 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 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 U 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 U sys/kern/kern_fork.c C 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 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/if_vx.c U sys/pci/if_vxreg.h U sys/pci/locate.pl U sys/pci/meteor.c U sys/pci/meteor_reg.h U sys/pci/ncr.c U sys/pci/ncrreg.h U sys/pci/pci.c 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 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 C 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 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 C 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/vlimit.h U sys/sys/vmmeter.h U sys/sys/vnioctl.h U sys/sys/vnode.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 25 conflicts created by this import. Use the following command to help the merge: cvs checkout -jCURRENT:yesterday -jCURRENT sys From owner-freebsd-smp Sun Sep 29 06:13:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21471 for smp-outgoing; Sun, 29 Sep 1996 06:13:22 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21409 for freebsd-smp; Sun, 29 Sep 1996 06:13:17 -0700 (PDT) Date: Sun, 29 Sep 1996 06:13:17 -0700 (PDT) From: Peter Wemm Message-Id: <199609291313.GAA21409@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/conf files.i386 options.i386 sys/scsi sd.c sys/sys kernel.h proc.h sys/i386/i386 db_interface.c identcpu.c machdep.c pmap.c support.s swtch.s trap.c sys/i386/include cpufunc.h segments.h sys/i386/isa clock.c npx.c random_machdep.c sio.c sys/kern init_main.c kern_exit.c kern_ktrace.c kern_shutdown.c kern_synch.c vfs_bio.c sys/vm vm_glue.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/09/29 06:13:16 Modified: i386/conf files.i386 options.i386 i386/i386 db_interface.c identcpu.c machdep.c pmap.c support.s swtch.s trap.c i386/include cpufunc.h segments.h i386/isa clock.c npx.c random_machdep.c sio.c kern init_main.c kern_exit.c kern_ktrace.c kern_shutdown.c kern_synch.c vfs_bio.c scsi sd.c sys kernel.h proc.h vm vm_glue.c Log: Merge in changes from -current that conflicted with something Revision Changes Path 1.8 +2 -2 sys/i386/conf/files.i386 1.6 +12 -2 sys/i386/conf/options.i386 1.5 +3 -3 sys/i386/i386/db_interface.c 1.3 +1 -15 sys/i386/i386/identcpu.c 1.23 +11 -23 sys/i386/i386/machdep.c 1.20 +650 -337 sys/i386/i386/pmap.c 1.12 +37 -29 sys/i386/i386/support.s 1.23 +2 -2 sys/i386/i386/swtch.s 1.13 +3 -3 sys/i386/i386/trap.c 1.10 +20 -56 sys/i386/include/cpufunc.h 1.3 +3 -2 sys/i386/include/segments.h 1.3 +8 -6 sys/i386/isa/clock.c 1.5 +1 -30 sys/i386/isa/npx.c 1.3 +30 -1 sys/i386/isa/random_machdep.c 1.5 +2 -65 sys/i386/isa/sio.c 1.23 +9 -1 sys/kern/init_main.c 1.8 +3 -3 sys/kern/kern_exit.c 1.5 +36 -1 sys/kern/kern_ktrace.c 1.5 +4 -8 sys/kern/kern_shutdown.c 1.11 +2 -7 sys/kern/kern_synch.c 1.9 +96 -27 sys/kern/vfs_bio.c 1.7 +3 -26 sys/scsi/sd.c 1.8 +2 -3 sys/sys/kernel.h 1.12 +3 -3 sys/sys/proc.h 1.10 +1 -38 sys/vm/vm_glue.c From owner-freebsd-smp Sun Sep 29 06:22:41 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA29065 for smp-outgoing; Sun, 29 Sep 1996 06:22:41 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA29021 for freebsd-smp; Sun, 29 Sep 1996 06:22:36 -0700 (PDT) Date: Sun, 29 Sep 1996 06:22:36 -0700 (PDT) From: Peter Wemm Message-Id: <199609291322.GAA29021@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 pmap.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/09/29 06:22:34 Modified: i386/i386 pmap.c Log: missed a pmap_update() -> invltlb() change Revision Changes Path 1.21 +2 -2 sys/i386/i386/pmap.c From owner-freebsd-smp Sun Sep 29 06:30:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA05360 for smp-outgoing; Sun, 29 Sep 1996 06:30:11 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA05319 for ; Sun, 29 Sep 1996 06:30:08 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id OAA14582; Sun, 29 Sep 1996 14:15:44 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id OAA00309; Sun, 29 Sep 1996 14:20:20 +0200 (MET DST) Date: Sun, 29 Sep 1996 14:20:20 +0200 (MET DST) From: Andreas Klemm To: Peter Wemm cc: smp@freebsd.org Subject: Re: your mail In-Reply-To: <199609291200.UAA01014@spinner.DIALix.COM> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 29 Sep 1996, Peter Wemm wrote: [...] > I guess this means that I'm not reccomending it for a "production" system > somewhere, although it's usually fine for hacking on if you've got ram. Well, then I'll wait... Although it would be simply interesting for me, since I'm a fan of multiprozessor systems, since we got a CPU upgrade in the company to 4 x 90 MHz Hypersparcs. Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Sun Sep 29 10:11:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA19151 for smp-outgoing; Sun, 29 Sep 1996 10:11:16 -0700 (PDT) Received: from mail0.iij.ad.jp (root@mail0.iij.ad.jp [192.244.176.61]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA19116 for ; Sun, 29 Sep 1996 10:11:06 -0700 (PDT) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [192.244.176.73]) by mail0.iij.ad.jp (8.6.12+2.4W/3.3W9-MAIL) with ESMTP id CAA07983 for ; Mon, 30 Sep 1996 02:10:46 +0900 Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id CAA11232 for FreeBSD-smp@freefall.freebsd.org; Mon, 30 Sep 1996 02:10:39 +0900 Received: by forusgw.forus.or.jp (8.6.12/1.0ForUs) id BAA09426; Mon, 30 Sep 1996 01:44:11 +0900 Received: (from uucp@localhost) by skuld.yggdrasil.forus.or.jp (8.7.5/3.3W9-skuld) with UUCP id BAA22222 for FreeBSD-smp@freefall.freebsd.org; Mon, 30 Sep 1996 01:19:28 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by urd.yggdrasil.forus.or.jp (8.7.5/3.3W9-urd) with SMTP id BAA28320 for ; Mon, 30 Sep 1996 01:22:39 +0900 (JST) Message-Id: <199609291622.BAA28320@urd.yggdrasil.forus.or.jp> X-Authentication-Warning: urd.yggdrasil.forus.or.jp: Host localhost [127.0.0.1] didn't use HELO protocol To: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Steve Passe's message of Sat, 28 Sep 1996 11:50:22 -0600 Date: Mon, 30 Sep 1996 01:22:39 +0900 From: ODA Kazutoshi Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, > for you without applying test[123]. Please try it that way: > FreeBSD-current + FreeBSD-SMP I tried no testX patches. Single make works fine with no bad signals. But 2 concurrent make is failed, (Of cource, it worked fine this concurrency on no smp_active mode.) on ttyv0: cd /sys/compile/TEST1; make all on ttyv1: cd /sys/compile/TEST2; make all If make failed once, next ld is immediately failed. > # ld > Segmentation fault (core dumped) I copied /usr/bin/ld to another machine. Similarly it dumped. I checked the copied file and original. > # diff /usr/bin/ld /usr/tmp/ld.copied > Binary files /usr/bin/ld and /usr/tmp/ld.copied differ Hmm, buffer cache data was corrupted? -- ODA, Kazutoshi okaz@yggdrasil.forus.or.jp From owner-freebsd-smp Sun Sep 29 10:49:25 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07673 for smp-outgoing; Sun, 29 Sep 1996 10:49:25 -0700 (PDT) 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 KAA07620 for ; Sun, 29 Sep 1996 10:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA20086; Sun, 29 Sep 1996 11:49:05 -0600 Message-Id: <199609291749.LAA20086@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: ODA Kazutoshi cc: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Mon, 30 Sep 1996 01:22:39 +0900." <199609291622.BAA28320@urd.yggdrasil.forus.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Sep 1996 11:49:05 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, [ for the record: Tyan S1562D Tomcat2 ] > > for you without applying test[123]. Please try it that way: > > FreeBSD-current + FreeBSD-SMP > > I tried no testX patches. > > Single make works fine with no bad signals. > But 2 concurrent make is failed, Thanx for running the test, at least I now know its not something I introduced with my last set of changes. > (Of cource, it worked fine this concurrency on no smp_active mode.) > on ttyv0: cd /sys/compile/TEST1; make all > on ttyv1: cd /sys/compile/TEST2; make all > If make failed once, next ld is immediately failed. > > # ld > > Segmentation fault (core dumped) > > I copied /usr/bin/ld to another machine. > Similarly it dumped. > > I checked the copied file and original. > > # diff /usr/bin/ld /usr/tmp/ld.copied > > Binary files /usr/bin/ld and /usr/tmp/ld.copied differ > > Hmm, buffer cache data was corrupted? or a page, Peter just mailed an explanation of the page problem. How much memory do you have in this machine? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Sep 29 14:10:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22301 for smp-outgoing; Sun, 29 Sep 1996 14:10:31 -0700 (PDT) Received: from mail0.iij.ad.jp (root@mail0.iij.ad.jp [192.244.176.61]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA22263 for ; Sun, 29 Sep 1996 14:10:26 -0700 (PDT) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [192.244.176.73]) by mail0.iij.ad.jp (8.6.12+2.4W/3.3W9-MAIL) with ESMTP id GAA20543 for ; Mon, 30 Sep 1996 06:10:24 +0900 Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id GAA20257 for FreeBSD-smp@freefall.freebsd.org; Mon, 30 Sep 1996 06:10:24 +0900 Received: by forusgw.forus.or.jp (8.6.12/1.0ForUs) id FAA11201; Mon, 30 Sep 1996 05:42:43 +0900 Received: (from uucp@localhost) by skuld.yggdrasil.forus.or.jp (8.7.5/3.3W9-skuld) with UUCP id FAA22484 for FreeBSD-smp@freefall.freebsd.org; Mon, 30 Sep 1996 05:29:58 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by urd.yggdrasil.forus.or.jp (8.7.5/3.3W9-urd) with SMTP id FAA29962 for ; Mon, 30 Sep 1996 05:28:16 +0900 (JST) Message-Id: <199609292028.FAA29962@urd.yggdrasil.forus.or.jp> X-Authentication-Warning: urd.yggdrasil.forus.or.jp: Host localhost [127.0.0.1] didn't use HELO protocol To: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Steve Passe's message of Sun, 29 Sep 1996 11:49:05 -0600 Date: Mon, 30 Sep 1996 05:28:16 +0900 From: ODA Kazutoshi Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, > How much memory do you have in this machine? 32MBytes. -- ODA, Kazutoshi okaz@yggdrasil.forus.or.jp From owner-freebsd-smp Sun Sep 29 15:53:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18048 for smp-outgoing; Sun, 29 Sep 1996 15:53:01 -0700 (PDT) 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 PAA17986 for ; Sun, 29 Sep 1996 15:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA21480; Sun, 29 Sep 1996 16:52:39 -0600 Message-Id: <199609292252.QAA21480@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: ODA Kazutoshi cc: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Mon, 30 Sep 1996 05:28:16 +0900." <199609292028.FAA29962@urd.yggdrasil.forus.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Sep 1996 16:52:39 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >> How much memory do you have in this machine? > > 32MBytes. Peter reports (NOT directly in reply to this mailing): ------------------------------------------------------------------------------ Well, based on what we now know about things that we don't do, I'm a little amazed that it's working as well as it seems to be in general. We are not doing TLB invalidation of other cpu's into account when modifying other processes page tables (which are possibly running on another cpu). This is a time-bomb that will affect low-memory or otherwise memory starved systems far worse than those that have plenty. (I run on 48M of ram and don't see it at all for days. I would expect 16M systems would be pretty bumpy.) ------------------------------------------------------------------------------ I have 64 meg and never see it. I suspect your getting hit by this problem. Unfortunately I don't have a solution. Anyone have a suggestion for "proving" this theory? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Sep 29 16:24:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA02302 for smp-outgoing; Sun, 29 Sep 1996 16:24:06 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA02224 for ; Sun, 29 Sep 1996 16:23:59 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id QAA28911; Sun, 29 Sep 1996 16:24:11 -0700 (PDT) Message-Id: <199609292324.QAA28911@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Sun, 29 Sep 1996 16:52:39 MDT." <199609292252.QAA21480@clem.systemsix.com> Date: Sun, 29 Sep 1996 16:24:11 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > Peter reports (NOT directly in reply to this mailing): > ------------------------------------------------------------------------------ > Well, based on what we now know about things that we don't do, I'm a little > amazed that it's working as well as it seems to be in general. We are not > doing TLB invalidation of other cpu's into account when modifying other > processes page tables (which are possibly running on another cpu). > > This is a time-bomb that will affect low-memory or otherwise memory starved > systems far worse than those that have plenty. (I run on 48M of ram and don't > see it at all for days. I would expect 16M systems would be pretty bumpy.) > ------------------------------------------------------------------------------ > > I have 64 meg and never see it. I suspect your getting hit by this > problem. Unfortunately I don't have a solution. Anyone have a suggestion > for "proving" this theory? > I have 64MB and see something like this problem quite a bit once I turn on the second CPU (well, if I'm doing something big like a GCC compile). I'm not claiming it is exactly the same problem. Interestingly enough, it always seems particular problems are caused by "ln" (it gets memory core dumps very often) and GCC's "enquire" simply locks the machine solid. -- 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 Sep 29 16:46:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17660 for smp-outgoing; Sun, 29 Sep 1996 16:46:26 -0700 (PDT) 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 QAA17621 for ; Sun, 29 Sep 1996 16:46:22 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id HAA04870; Mon, 30 Sep 1996 07:44:58 +0800 (WST) Message-Id: <199609292344.HAA04870@spinner.DIALix.COM> To: erich@uruk.org cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Sun, 29 Sep 1996 16:24:11 MST." <199609292324.QAA28911@uruk.org> Date: Mon, 30 Sep 1996 07:44:58 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk erich@uruk.org wrote: > > Steve Passe writes: > > I have 64 meg and never see it. I suspect your getting hit by this > > problem. Unfortunately I don't have a solution. Anyone have a suggestion > > for "proving" this theory? How about commenting out the invalidate-tlb calls and see how long it lasts? :-) That's about the size of what's happening to the second cpu. > I have 64MB and see something like this problem quite a bit once I turn > on the second CPU (well, if I'm doing something big like a GCC compile). > I'm not claiming it is exactly the same problem. > > Interestingly enough, it always seems particular problems are caused by > "ln" (it gets memory core dumps very often) and GCC's "enquire" simply > locks the machine solid. Hmm. I have some old 386 motherboards that lock solid on enquire, I seem to recall it was dismissed as "FERR->INT 13 linkage foulup".. Perhaps enquire is triggering a floating point IRQ-13 on the second cpu which is currently not being handled? The second cpu does not get any IRQ's at all at present, and if IRQ-13 is being generated directly within the cpu then that might explain it. > -- > Erich Stefan Boleyn \_ E-mail (preferred): ; Sun, 29 Sep 1996 17:06:26 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id RAA28992 for ; Sun, 29 Sep 1996 17:07:53 -0700 (PDT) Message-Id: <199609300007.RAA28992@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: freebsd-smp@freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Mon, 30 Sep 1996 07:44:58 +0800." <199609292344.HAA04870@spinner.DIALix.COM> Date: Sun, 29 Sep 1996 17:07:52 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [I didn't copy this to this list last time I sent it] Peter Wemm writes: > erich@uruk.org wrote: > > > I have 64MB and see something like this problem quite a bit once I turn > > on the second CPU (well, if I'm doing something big like a GCC compile). > > I'm not claiming it is exactly the same problem. > > > > Interestingly enough, it always seems particular problems are caused by > > "ln" (it gets memory core dumps very often) and GCC's "enquire" simply > > locks the machine solid. > > Hmm. I have some old 386 motherboards that lock solid on enquire, I seem > to recall it was dismissed as "FERR->INT 13 linkage foulup".. My suspicion has been a floating-point error problem. > Perhaps enquire is triggering a floating point IRQ-13 on the second cpu > which is currently not being handled? The second cpu does not get any > IRQ's at all at present, and if IRQ-13 is being generated directly within > the cpu then that might explain it. Yikes!!! This is definitely a major problem. With the APIC hardware, the I/O APIC is handling PIC interrupts only. Anything that is directly handled via the CPU or local APIC will of course generate interrupts on the CPU in question. -- 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" -- 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 Sep 29 17:32:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA23298 for smp-outgoing; Sun, 29 Sep 1996 17:32:22 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA21228 for ; Sun, 29 Sep 1996 17:29:49 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id RAA29056; Sun, 29 Sep 1996 17:29:59 -0700 (PDT) Message-Id: <199609300029.RAA29056@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: freebsd-smp@freebsd.org, linux-smp@vger.rutgers.edu cc: alan@cymru.net, peter@spinner.dialix.com, smp@csn.net, terry@lambert.org Subject: Generic SMP startup sequence and some docs Date: Sun, 29 Sep 1996 17:29:02 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I finally have most of it almost done (complaints about work, other projects, etc. appropriate here ;-). The main part missing is the inclusion of most of the the CPU startup sequence itself, a generic IPI sender routine of some sort (still thinking on that one a bit), and one more look over the "default" configuration startup (there's some things missing right now, though they are only relevant to using the APIC in Symmetric I/O modes). Look on my MPS webpage in the "Example Code/Clarifications" section for details: http://www.uruk.org/~erich/mps.html Several more details about how to support integrated vs. discrete APICs are in this code and docs. When I get more of the Symmetic I/O stuff done, yet more will come out. One interesting detail is to note that in general, the other CPUs are already set up for generic symmetic delivery... all you have to do is to enable the LINTIN0 (ISA interrupts) and LINTIN1 (NMI interrupt) entries on each CPU, as they should already be programmed. The "local interrupt" entries of the MP Configuration Table, if set to "0xFF" APIC destination, are already set up on all the CPUs. The code I have parses all these, plus sets up a "fake" table which calls all the appropriate callbacks for the default configurations (the debugging I mentioned is making sure all the entries are correct). Anyway... I'll send more soon. -- 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 Sep 29 18:01:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA14761 for smp-outgoing; Sun, 29 Sep 1996 18:01:11 -0700 (PDT) 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 RAA13755 for ; Sun, 29 Sep 1996 17:59:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id SAA22106; Sun, 29 Sep 1996 18:58:10 -0600 Message-Id: <199609300058.SAA22106@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: erich@uruk.org cc: freebsd-smp@freebsd.org, peter@spinner.dialix.com, terry@lambert.org Subject: Re: Generic SMP startup sequence and some docs In-reply-to: Your message of "Sun, 29 Sep 1996 17:29:02 PDT." <199609300029.RAA29056@uruk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Sep 1996 18:58:10 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >One interesting detail is to note that in general, the other CPUs >are already set up for generic symmetic delivery... all you have >to do is to enable the LINTIN0 (ISA interrupts) and LINTIN1 (NMI >interrupt) entries on each CPU, as they should already be programmed. >The "local interrupt" entries of the MP Configuration Table, if >set to "0xFF" APIC destination, are already set up on all the CPUs. This is the area I am currently working on. I could use some clarification here. In this symmetric model are you using the 8259, or programming the IO APIC to handle everything? My take on this is that you program the IO APIC to replace the 8259, disable the 8259, and handle all ISA INTs thru the APIC bus, NOT the LINTIN0/1 lines. -- 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 Sep 30 04:08:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA01296 for smp-outgoing; Mon, 30 Sep 1996 04:08:20 -0700 (PDT) Received: from snowcrash.cymru.net (root@snowcrash.cymru.net [163.164.160.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA29960 for ; Mon, 30 Sep 1996 04:06:54 -0700 (PDT) Received: (from alan@localhost) by snowcrash.cymru.net (8.7.1/8.7.1) id LAA25026; Mon, 30 Sep 1996 11:52:09 +0100 From: Alan Cox Message-Id: <199609301052.LAA25026@snowcrash.cymru.net> Subject: Re: Generic SMP startup sequence and some docs To: erich@uruk.org Date: Mon, 30 Sep 1996 11:52:07 +0100 (BST) Cc: freebsd-smp@freebsd.org, linux-smp@vger.rutgers.edu, alan@cymru.net, peter@spinner.dialix.com, smp@csn.net, terry@lambert.org In-Reply-To: <199609300029.RAA29056@uruk.org> from "erich@uruk.org" at Sep 29, 96 05:29:02 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 > calls all the appropriate callbacks for the default configurations > (the debugging I mentioned is making sure all the entries are correct). It also assumes direct physical mapping of addresses. It might be a good idea (in all that ficticious free time) to make it use some macro like PHYS_TO_VIRTUAL(addr) VIRTUAL_TO_PHYS(addr) Alan From owner-freebsd-smp Tue Oct 1 11:45:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA10126 for smp-outgoing; Tue, 1 Oct 1996 11:45:13 -0700 (PDT) Received: from Central.KeyWest.MPGN.COM (Central.TanSoft.COM [206.175.4.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA10110; Tue, 1 Oct 1996 11:45:10 -0700 (PDT) Received: from devious.Tansoft.com (Devious.TanSoft.COM [206.175.4.10]) by Central.KeyWest.MPGN.COM (8.6.9/8.6.9) with SMTP id OAA11919; Tue, 1 Oct 1996 14:44:13 -0400 Message-Id: <3.0b24.32.19961001144413.006e4040@central.TanSoft.COM> X-Sender: rwm@central.TanSoft.COM X-Mailer: Windows Eudora Pro Version 3.0b24 (32) Date: Tue, 01 Oct 1996 14:44:14 -0400 To: freebsd-current@freebsd.org, freebsd-smp@freebsd.org From: Rob Miracle Subject: Problem w/ New Kernels Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just put up the lastest SMP kernel (and I had the same problem with the normal Kernel when I ftp'ed the sys tree from ftp.freebsd.org last week) and I have an odd problem: If I do a 'ps' or a 'w' I get a message back saying ps: proc size mismatch (18960 total, 612 chunks) or w: proc size mismatch (18960 total, 612 chunks) Any ideas? Thanks Rob -- Rob Miracle Tantalus Inc. Be patient or be a patient. -- Anton Devious From owner-freebsd-smp Tue Oct 1 12:54:34 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA20116 for smp-outgoing; Tue, 1 Oct 1996 12:54:34 -0700 (PDT) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA20104; Tue, 1 Oct 1996 12:54:29 -0700 (PDT) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.7.5/8.7.5) with SMTP id PAA05103; Tue, 1 Oct 1996 15:54:18 -0400 (EDT) Date: Tue, 1 Oct 1996 15:54:17 -0400 (EDT) From: "Marc G. Fournier" To: Rob Miracle cc: freebsd-current@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Problem w/ New Kernels In-Reply-To: <3.0b24.32.19961001144413.006e4040@central.TanSoft.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 Tue, 1 Oct 1996, Rob Miracle wrote: > I just put up the lastest SMP kernel (and I had the same problem with the > normal Kernel when I ftp'ed the sys tree from ftp.freebsd.org last week) > and I have an odd problem: > > If I do a 'ps' or a 'w' I get a message back saying > > ps: proc size mismatch (18960 total, 612 chunks) > > or > > w: proc size mismatch (18960 total, 612 chunks) > > Any ideas? > Did you remember to recompile ps/w? If *that* doesn't do it, then libkvm has to be recompiled as well... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-smp Tue Oct 1 13:54:34 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24315 for smp-outgoing; Tue, 1 Oct 1996 13:54:34 -0700 (PDT) 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 NAA24298 for ; Tue, 1 Oct 1996 13:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA04450; Tue, 1 Oct 1996 14:54:08 -0600 Message-Id: <199610012054.OAA04450@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Rob Miracle cc: freebsd-smp@FreeBSD.org Subject: Re: Problem w/ New Kernels In-reply-to: Your message of "Tue, 01 Oct 1996 14:44:14 EDT." <3.0b24.32.19961001144413.006e4040@central.TanSoft.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Oct 1996 14:54:08 -0600 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I just put up the lastest SMP kernel (and I had the same problem with the > normal Kernel when I ftp'ed the sys tree from ftp.freebsd.org last week) > and I have an odd problem: > > If I do a 'ps' or a 'w' I get a message back saying > > ps: proc size mismatch (18960 total, 612 chunks) > ... > Any ideas? I had this till I supped the SMP kernel as of 960929, at which point it went away. Note that I did NOT sup the latest -current at the same time, ie my kernel is now AHEAD of everything else. The problem is a mismatch of versions, not the SMP kernel itself. There hase been a thread in hackers about this (I think this is the same problem...) ------------------------------------------------------------------------ >From: Karl Denninger >Date: Sun, 29 Sep 1996 14:18:06 -0500 (CDT) >Subject: PS broke again -- what has to be rebuilt to stop this? > >Hi folks, > >Well, the kernel structures changed AGAIN between 8/24 and today. ------------------------------------------------------------------------- you might check that thread for ideas. you might have to re-sup -current and remake the world... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Tue Oct 1 14:02:51 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25164 for smp-outgoing; Tue, 1 Oct 1996 14:02:51 -0700 (PDT) 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 OAA25153 for ; Tue, 1 Oct 1996 14:02:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA04537 for ; Tue, 1 Oct 1996 15:02:42 -0600 Message-Id: <199610012102.PAA04537@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@freebsd.org Subject: New SMP kernel patches Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Oct 1996 15:02:41 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, for the adventurous out there, I have just put up a new set of files on the SMP web page: test4b (ignore 4a) these files eliminate (I hope) problems for machines with less than 640k of base memory. They also cleanup ALOT of the low level AP boot code. I would like testers to let me know if anything breaks, so that I can get these commited to the tree and go on to something else! -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Oct 2 07:49:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA12769 for smp-outgoing; Wed, 2 Oct 1996 07:49:09 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA12760 for freebsd-smp; Wed, 2 Oct 1996 07:49:07 -0700 (PDT) Date: Wed, 2 Oct 1996 07:49:07 -0700 (PDT) From: Steve Passe Message-Id: <199610021449.HAA12760@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/conf files.i386 sys/i386/i386 locore.s machdep.c mp_machdep.c mpapic.c mpboot.s mpcore.c sys/i386/include mpasm.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/02 07:49:05 Modified: i386/conf files.i386 Log: removed mpcore.c Revision Changes Path 1.9 +2 -2 sys/i386/conf/files.i386 Modified: i386/i386 locore.s machdep.c mp_machdep.c mpapic.c mpboot.s Removed: i386/i386 mpcore.c Log: removed last of SMP code from locore.s cleaned up SMP code in machdep. made MPentry & bootMP relocatable, eliminating 640k basemem requirement. kernel calculates usable address for bootMP at runtime. added code to use "default" configurations. Revision Changes Path 1.27 +1 -86 sys/i386/i386/locore.s 1.24 +34 -62 sys/i386/i386/machdep.c 1.2 +416 -141 sys/i386/i386/mp_machdep.c 1.2 +1 -2 sys/i386/i386/mpapic.c 1.3 +121 -47 sys/i386/i386/mpboot.s Removed: i386/include mpasm.h Log: mpasm.h goes away, its hard addresse no longer needed. From owner-freebsd-smp Wed Oct 2 11:58:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27972 for smp-outgoing; Wed, 2 Oct 1996 11:58:57 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27961 for freebsd-smp; Wed, 2 Oct 1996 11:58:55 -0700 (PDT) Date: Wed, 2 Oct 1996 11:58:55 -0700 (PDT) From: Peter Wemm Message-Id: <199610021858.LAA27961@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 locore.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/02 11:58:55 Modified: i386/i386 locore.s Log: This is now in sync with -current Revision Changes Path 1.28 +1 -14 sys/i386/i386/locore.s From owner-freebsd-smp Wed Oct 2 12:07:12 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28527 for smp-outgoing; Wed, 2 Oct 1996 12:07:12 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28520 for freebsd-smp; Wed, 2 Oct 1996 12:07:11 -0700 (PDT) Date: Wed, 2 Oct 1996 12:07:11 -0700 (PDT) From: Peter Wemm Message-Id: <199610021907.MAA28520@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c sys/i386/i386 mpboot.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/02 12:07:10 Modified: kern init_main.c i386/i386 mpboot.s Log: Kill some NCPU == 2 dependencies. Theoretically, it can now run 'n' cpus (n < 15). It creates as many idle procs as are needed, and carefully brings them online so that it can reuse mp_stk each time. I've not looked very closely, but I think most other places in the code deal with 'NCPU'. I'll check soon. It uses a new type of mutex semaphore for unlocking the cpus, as suggested in some intel docs. Also... shudder.. It fires up the alternate cpus as soon as the idle proc is scheduled, ie: at boot time immediately after init. No more need to set kern.smp_active to 2. In theory, if you have 4 cpus, smp_active should end up with the value "4". Raising and lowering it will probably enable and disable the appropriate numbered cpus. Setting smp_active to 1 should cause the system to effectively run uniprocessor. "It works for me (TM)".. Revision Changes Path 1.24 +63 -40 sys/kern/init_main.c 1.4 +30 -8 sys/i386/i386/mpboot.s From owner-freebsd-smp Wed Oct 2 12:09:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28819 for smp-outgoing; Wed, 2 Oct 1996 12:09:47 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA28809 for freebsd-smp; Wed, 2 Oct 1996 12:09:45 -0700 (PDT) Date: Wed, 2 Oct 1996 12:09:45 -0700 (PDT) From: Peter Wemm Message-Id: <199610021909.MAA28809@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/sys kernel.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/02 12:09:44 Modified: sys kernel.h Log: I had better not forget to commit the replaced SYSINIT sequence number. :-) Revision Changes Path 1.9 +1 -1 sys/sys/kernel.h From owner-freebsd-smp Wed Oct 2 13:02:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02319 for smp-outgoing; Wed, 2 Oct 1996 13:02:55 -0700 (PDT) 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 NAA02281 for ; Wed, 2 Oct 1996 13:02:13 -0700 (PDT) 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 OAA00385; Wed, 2 Oct 1996 14:49:38 -0500 (CDT) Message-Id: <199610021949.OAA00385@friley216.res.iastate.edu> To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of Wed, 02 Oct 1996 12:07:11 -0700. <199610021907.MAA28520@freefall.freebsd.org> Date: Wed, 02 Oct 1996 14:49:37 -0500 From: "Chris Csanady" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >peter 96/10/02 12:07:10 > > Modified: kern init_main.c > i386/i386 mpboot.s > Log: > Kill some NCPU == 2 dependencies. > > Theoretically, it can now run 'n' cpus (n < 15). It creates as many > idle procs as are needed, and carefully brings them online so that it > can reuse mp_stk each time. I've not looked very closely, but I think > most other places in the code deal with 'NCPU'. I'll check soon. > It uses a new type of mutex semaphore for unlocking the cpus, as suggested > in some intel docs. Should we perhaps set the var hw.ncpu early on, and get rid of the NCPU config variable? It seems to be there for nothing right now.. > > Also... shudder.. It fires up the alternate cpus as soon as the idle proc > is scheduled, ie: at boot time immediately after init. No more need to > set kern.smp_active to 2. In theory, if you have 4 cpus, smp_active should > end up with the value "4". Raising and lowering it will probably enable and > disable the appropriate numbered cpus. Setting smp_active to 1 should cause > the system to effectively run uniprocessor. On this topic, the smp.todo mentions we want to get rid of the idle processes?! I have been looking at the scheduling code, and although I am currently somewhat confused, it does not seem that this would be possible until we have a threaded kernel. Am I incorrect in assuming this? the current idle loop in the UP code is in the kernel, so it doesnt seem as if we could do it that way without some degree of threading. More generally though, Is anyone looking at rewriting the scheduler? And based upon what? I was going to try and work on this, but currently, I havent gotten a complete understanding of everything going on, and how to go about it the right way. I dont know.. perhaps I should just stay away from some stuff. :) Chris Csanady > > "It works for me (TM)".. > > Revision Changes Path > 1.24 +63 -40 sys/kern/init_main.c > 1.4 +30 -8 sys/i386/i386/mpboot.s From owner-freebsd-smp Wed Oct 2 14:01:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07052 for smp-outgoing; Wed, 2 Oct 1996 14:01:56 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA07030 for ; Wed, 2 Oct 1996 14:01:44 -0700 (PDT) Received: by groa.uct.ac.za via sendmail with stdio id for freebsd-smp@freebsd.org; Wed, 2 Oct 1996 22:57:51 +0200 (SAT) (Smail-3.2 1996-Jul-4 #2 built 1996-Oct-2) Message-Id: From: rv@groa.uct.ac.za (Russell Vincent) Subject: ASUS P55P2T4D works To: smp@csn.net Date: Wed, 2 Oct 1996 22:57:51 +0200 (SAT) Cc: freebsd-smp@freebsd.org X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Steve, I can confirm that the ASUS P55P2T4D motherboard works with FreeBSD's SMP code as of about 4 hours ago (before Peter's latest commits). This is with dual P5-133, 512K PB Sync cache, 256MB DRAM, lots of disk. I successfully did a kernel compile with both CPU's active. 'mptable' output is attached. -Russell -------------------------- snip ------------------------ # ./mptable Warning: EBDA support is BROKEN!!! Found MP Table in BIOS, physical addr: 0x000f0d3c -------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0d3c signature: '_MP_' length: 208 bytes version: 1.232 checksum: 0x63 warning, MP feature byte 2: 0xefbfdd58 mode: PIC warning, MP feature byte 3 NONZERO! warning, MP feature byte 5 NONZERO! -------------------------------------------------------------------------- MP default config type: 22 future type -------------------------------------------------------------------------- -------------------------- snip ------------------------ From owner-freebsd-smp Wed Oct 2 18:44:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21152 for smp-outgoing; Wed, 2 Oct 1996 18:44:56 -0700 (PDT) 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 SAA21146 for ; Wed, 2 Oct 1996 18:44:53 -0700 (PDT) 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 UAA00282 for ; Wed, 2 Oct 1996 20:44:52 -0500 (CDT) Message-Id: <199610030144.UAA00282@friley216.res.iastate.edu> To: freebsd-smp@freebsd.org Subject: Load avg fixes.. Date: Wed, 02 Oct 1996 20:44:52 -0500 From: "Chris Csanady" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ive been working on making the statistics for SMP look nice. So far with the following patches, the load average looks reasonable. I was thinking of ignoring all the RTP_IDLE procs, but this just does not seem right. Other than hard coding the pids of the idle procs, all I could think of is an added p_flag for now. Also, how would one go about properly calculating cpu %ages now? It almost seems futile. :\ Chris Csanady here are the diffs from before the last commits. anything else, let me know.. *** sys/sys/proc.h.old Wed Oct 2 19:43:04 1996 --- sys/sys/proc.h Wed Oct 2 19:55:17 1996 *************** *** 218,223 **** --- 218,226 ---- #define P_SWAPPING 0x40000 /* Process is being swapped. */ + /* Hack for SMP idle procs XXX */ + #define P_IGNORE 0x80000 /* Ignore during load average calculation. */ + /* * MOVE TO ucred.h? * *** sys/vm/vm_meter.c.old Wed Oct 2 19:35:56 1996 --- sys/vm/vm_meter.c Wed Oct 2 19:52:40 1996 *************** *** 79,84 **** --- 79,86 ---- register struct proc *p; for (nrun = 0, p = allproc.lh_first; p != 0; p = p->p_list.le_next) { + if (p->p_flag & P_IGNORE) + continue; switch (p->p_stat) { case SSLEEP: if (p->p_priority > PZERO || p->p_slptime != 0) *** sys/kern/init_main.c.old Wed Oct 2 19:59:56 1996 --- sys/kern/init_main.c Wed Oct 2 19:53:32 1996 *************** *** 688,693 **** --- 688,694 ---- struct proc *p = curproc; p->p_rtprio.type = RTP_PRIO_IDLE; /* last of the three classes */ p->p_rtprio.prio = RTP_PRIO_MAX; /* lowest priority possible */ + p->p_flag |= P_IGNORE; /* ignore during ldavg calc */ smp_idleloop(); /*NOTREACHED*/ } From owner-freebsd-smp Wed Oct 2 19:29:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA23203 for smp-outgoing; Wed, 2 Oct 1996 19:29:55 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA23196 for freebsd-smp; Wed, 2 Oct 1996 19:29:53 -0700 (PDT) Date: Wed, 2 Oct 1996 19:29:53 -0700 (PDT) From: Steve Passe Message-Id: <199610030229.TAA23196@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 machdep.c mp_machdep.c mpapic.c sys/i386/include apic.h smp.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/02 19:29:52 Modified: i386/i386 machdep.c mp_machdep.c mpapic.c i386/include apic.h smp.h Log: cleaned up code for 'style' added support for sending APIC IPI INTerrupts Revision Changes Path 1.25 +4 -32 sys/i386/i386/machdep.c 1.3 +5 -19 sys/i386/i386/mp_machdep.c 1.3 +176 -9 sys/i386/i386/mpapic.c 1.4 +202 -19 sys/i386/include/apic.h 1.9 +32 -15 sys/i386/include/smp.h From owner-freebsd-smp Thu Oct 3 00:32:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA08818 for smp-outgoing; Thu, 3 Oct 1996 00:32:27 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA08810 for freebsd-smp; Thu, 3 Oct 1996 00:32:26 -0700 (PDT) Date: Thu, 3 Oct 1996 00:32:26 -0700 (PDT) From: Peter Wemm Message-Id: <199610030732.AAA08810@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/conf files.i386 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/03 00:32:25 Modified: i386/conf files.i386 Log: minor nit, the entries are supposed to be in alphabetical order.. :-) Revision Changes Path 1.10 +2 -3 sys/i386/conf/files.i386 From owner-freebsd-smp Thu Oct 3 05:40:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA24540 for smp-outgoing; Thu, 3 Oct 1996 05:40:15 -0700 (PDT) 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 FAA24528 for ; Thu, 3 Oct 1996 05:40:06 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id UAA05805; Thu, 3 Oct 1996 20:39:33 +0800 (WST) Message-Id: <199610031239.UAA05805@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: "Chris Csanady" cc: freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of "Wed, 02 Oct 1996 14:49:37 EST." <199610021949.OAA00385@friley216.res.iastate.edu> Date: Thu, 03 Oct 1996 20:39:32 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Chris Csanady" wrote: > Should we perhaps set the var hw.ncpu early on, and get rid of the NCPU confi g > variable? It seems to be there for nothing right now.. NCPU is rather important at the moment, it defines how much room we reserve in various tables, and really it should be called "MAXCPU" which would be more accurate. There should be nothing stopping somebody configuring NCPU to 10 at present, it will only create the idle procs for the number of active cpus (providing there's enough available slots of course) > > > > Also... shudder.. It fires up the alternate cpus as soon as the idle proc > > is scheduled, ie: at boot time immediately after init. No more need to > > set kern.smp_active to 2. In theory, if you have 4 cpus, smp_active shoul d > > end up with the value "4". Raising and lowering it will probably enable a nd > > disable the appropriate numbered cpus. Setting smp_active to 1 should cau se > > the system to effectively run uniprocessor. > > On this topic, the smp.todo mentions we want to get rid of the idle processes ?! > I have been looking at the scheduling code, and although I am currently > somewhat confused, it does not seem that this would be possible until we have > a threaded kernel. Am I incorrect in assuming this? the current idle loop i n > the UP code is in the kernel, so it doesnt seem as if we could do it that > way without some degree of threading. This is equal top of my "todo" list. I think we'll get the tlb invalidation going next though, since it's a showstopper. > More generally though, Is anyone looking at rewriting the scheduler? And bas ed > upon what? I was going to try and work on this, but currently, I havent gott en > a complete understanding of everything going on, and how to go about it the > right way. At present, we have 32 run queues with 4 (8?) priority levels in each queue. When the scheduler runs, it picks the first process off the top of the highest priority queue. Something has to be done here since there seems to be no real way to bias processes to attempt to give them preference for a single cpu to get some advantage of the on-cpu cache. Otherwise, the processes seem to bounce backwards and forwards from one cpu to the other and so on. I don't know an easy answer offhand.. If we maintain this strategy, perhaps we'd need to have one set of 32 run queues for each cpu as well as the common one. The scheduler could look in the per-cpu queue first and if there's a process available that's "near enough" to the head of the "real" run queue then choose that. That starts to get messy though, perhaps a simple list of "recently run processes" to look in the run queues for may be enough. > I dont know.. perhaps I should just stay away from some stuff. :) Well, if anybody comes up with a better strategy that fits the kernel without too much trauma (that's also understandable), it's worth hearing. > Chris Csanady Cheers, -Peter From owner-freebsd-smp Thu Oct 3 06:25:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA25920 for smp-outgoing; Thu, 3 Oct 1996 06:25:00 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA25915 for ; Thu, 3 Oct 1996 06:24:57 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id IAA00634; Thu, 3 Oct 1996 08:23:53 -0500 (EST) From: "John S. Dyson" Message-Id: <199610031323.IAA00634@dyson.iquest.net> Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . To: peter@spinner.dialix.com (Peter Wemm) Date: Thu, 3 Oct 1996 08:23:53 -0500 (EST) Cc: ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org In-Reply-To: <199610031239.UAA05805@spinner.DIALix.COM> from "Peter Wemm" at Oct 3, 96 08:39:32 pm 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 > > This is equal top of my "todo" list. I think we'll get the tlb > invalidation going next though, since it's a showstopper. > If you need help, I intend to come up with an ifdef'ed version of pmap that removes the 1 page invalidations. This will mean that all you have to do is to communicate the tlbflush (invltlb) operation. Will that help? John From owner-freebsd-smp Thu Oct 3 06:58:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA28196 for smp-outgoing; Thu, 3 Oct 1996 06:58:46 -0700 (PDT) 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 GAA28188; Thu, 3 Oct 1996 06:58:40 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id VAA06005; Thu, 3 Oct 1996 21:58:35 +0800 (WST) Message-Id: <199610031358.VAA06005@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: dyson@freebsd.org cc: freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . In-reply-to: Your message of "Thu, 03 Oct 1996 08:23:53 EST." <199610031323.IAA00634@dyson.iquest.net> Date: Thu, 03 Oct 1996 21:58:34 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > > > This is equal top of my "todo" list. I think we'll get the tlb > > invalidation going next though, since it's a showstopper. > > > If you need help, I intend to come up with an ifdef'ed version > of pmap that removes the 1 page invalidations. This will mean that > all you have to do is to communicate the tlbflush (invltlb) operation. > > Will that help? Probably not necessary at this stage.. For the first round, we'll try for an "either call invalidates everything" approach, then try and optimise it a bit. :-) We can do message passing if it's worth it, ie: store the address in a specific location, then have the target cpu invalidate based on that address. But I suspect the cost of an apic IPI transaction is far higher than the potential savings so it may not be worth the effort. We'd probably better worry about the basics first.. (we've gotta do an EOI somehow, I need to check the docs) > John Cheers, -Peter From owner-freebsd-smp Thu Oct 3 07:17:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29361 for smp-outgoing; Thu, 3 Oct 1996 07:17:26 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA29351 for ; Thu, 3 Oct 1996 07:17:17 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id PAA26230; Thu, 3 Oct 1996 15:15:59 +0100 Date: Thu, 3 Oct 1996 15:15:59 +0100 (BST) From: Doug Rabson To: Peter Wemm cc: Chris Csanady , freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-Reply-To: <199610031239.UAA05805@spinner.DIALix.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 Thu, 3 Oct 1996, Peter Wemm wrote: > > At present, we have 32 run queues with 4 (8?) priority levels in each > queue. When the scheduler runs, it picks the first process off the top of > the highest priority queue. > > Something has to be done here since there seems to be no real way to bias > processes to attempt to give them preference for a single cpu to get some > advantage of the on-cpu cache. Otherwise, the processes seem to bounce > backwards and forwards from one cpu to the other and so on. > > I don't know an easy answer offhand.. > > If we maintain this strategy, perhaps we'd need to have one set of 32 run > queues for each cpu as well as the common one. The scheduler could look > in the per-cpu queue first and if there's a process available that's "near > enough" to the head of the "real" run queue then choose that. That starts > to get messy though, perhaps a simple list of "recently run processes" to > look in the run queues for may be enough. > > > I dont know.. perhaps I should just stay away from some stuff. :) > > Well, if anybody comes up with a better strategy that fits the kernel > without too much trauma (that's also understandable), it's worth hearing. Why not use a byte in struct proc for the cpuid of the processor which most recently ran the process. If there is a choice of highest-priority processes, each cpu could choose a process which it has run before, otherwise just pick the highest priority process as normal. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-smp Thu Oct 3 07:23:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29742 for smp-outgoing; Thu, 3 Oct 1996 07:23:46 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA29736 for ; Thu, 3 Oct 1996 07:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id HAA12159; Thu, 3 Oct 1996 07:24:07 -0700 (PDT) Message-Id: <199610031424.HAA12159@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Doug Rabson cc: Peter Wemm , Chris Csanady , freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of "Thu, 03 Oct 1996 15:15:59 BST." From: David Greenman Reply-To: dg@Root.COM Date: Thu, 03 Oct 1996 07:24:07 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Why not use a byte in struct proc for the cpuid of the processor which >most recently ran the process. If there is a choice of highest-priority >processes, each cpu could choose a process which it has run before, >otherwise just pick the highest priority process as normal. Right, if the CPU that it ran on last isn't available, but another one is, you don't want to *not* run it just because of the processor affinity. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Thu Oct 3 10:45:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA11085 for smp-outgoing; Thu, 3 Oct 1996 10:45:45 -0700 (PDT) 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 KAA11076 for ; Thu, 3 Oct 1996 10:45:42 -0700 (PDT) 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 MAA03088; Thu, 3 Oct 1996 12:45:32 -0500 (CDT) Message-Id: <199610031745.MAA03088@friley216.res.iastate.edu> To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of Thu, 03 Oct 1996 20:39:32 +0800. <199610031239.UAA05805@spinner.DIALix.COM> Date: Thu, 03 Oct 1996 12:45:31 -0500 From: "Chris Csanady" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >"Chris Csanady" wrote: >> Should we perhaps set the var hw.ncpu early on, and get rid of the NCPU confi > g >> variable? It seems to be there for nothing right now.. > >NCPU is rather important at the moment, it defines how much room we >reserve in various tables, and really it should be called "MAXCPU" which >would be more accurate. There should be nothing stopping somebody >configuring NCPU to 10 at present, it will only create the idle procs for >the number of active cpus (providing there's enough available slots of >course) I was more thinking of the hw.ncpu sysctl variable that just sits there. ;) I Its quite nice that this all gets started automatically now. > >> > >> > Also... shudder.. It fires up the alternate cpus as soon as the idle proc >> > is scheduled, ie: at boot time immediately after init. No more need to >> > set kern.smp_active to 2. In theory, if you have 4 cpus, smp_active shoul > d >> > end up with the value "4". Raising and lowering it will probably enable a > nd >> > disable the appropriate numbered cpus. Setting smp_active to 1 should cau > se >> > the system to effectively run uniprocessor. >> >> On this topic, the smp.todo mentions we want to get rid of the idle processes > ?! >> I have been looking at the scheduling code, and although I am currently >> somewhat confused, it does not seem that this would be possible until we have >> a threaded kernel. Am I incorrect in assuming this? the current idle loop i > n >> the UP code is in the kernel, so it doesnt seem as if we could do it that >> way without some degree of threading. > >This is equal top of my "todo" list. I think we'll get the tlb >invalidation going next though, since it's a showstopper. > >> More generally though, Is anyone looking at rewriting the scheduler? And bas > ed >> upon what? I was going to try and work on this, but currently, I havent gott > en >> a complete understanding of everything going on, and how to go about it the >> right way. > >At present, we have 32 run queues with 4 (8?) priority levels in each >queue. When the scheduler runs, it picks the first process off the top of >the highest priority queue. Currently, the processes are just taken off the run queues from the idle loops, corrects? Anyway, what guarantees that the idle loops are running on their respective processors? Or perhaps it does not even matter. Im still unclear as to how both cpus run things. (i mean at the lowest possible level, what tells the secondary cpu actually run something?) >Something has to be done here since there seems to be no real way to bias >processes to attempt to give them preference for a single cpu to get some >advantage of the on-cpu cache. Otherwise, the processes seem to bounce >backwards and forwards from one cpu to the other and so on. I have been thinking about this as well.. >I don't know an easy answer offhand.. Me either.. Also, it would be nice to balance the load evenly. I recall there there being a lot of discussion of this in Schimmel's book, but I dont have a copy of that right now. :( Perhaps just having 2 entirely different run queues? Depending on relative cpu idle times, processors may steal processes from the others run queue. So in a relatively stable situation, none would move at all. (ie if no processors are bored, nothing happens:) Chris >If we maintain this strategy, perhaps we'd need to have one set of 32 run >queues for each cpu as well as the common one. The scheduler could look >in the per-cpu queue first and if there's a process available that's "near >enough" to the head of the "real" run queue then choose that. That starts >to get messy though, perhaps a simple list of "recently run processes" to >look in the run queues for may be enough. > >> I dont know.. perhaps I should just stay away from some stuff. :) > >Well, if anybody comes up with a better strategy that fits the kernel >without too much trauma (that's also understandable), it's worth hearing. > >> Chris Csanady > >Cheers, >-Peter > > From owner-freebsd-smp Thu Oct 3 10:56:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA11591 for smp-outgoing; Thu, 3 Oct 1996 10:56:55 -0700 (PDT) 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 KAA11586 for ; Thu, 3 Oct 1996 10:56:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA17256; Thu, 3 Oct 1996 11:56:36 -0600 Message-Id: <199610031756.LAA17256@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@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . In-reply-to: Your message of "Thu, 03 Oct 1996 21:58:34 +0800." <199610031358.VAA06005@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Oct 1996 11:56:35 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > probably better worry about the basics first.. (we've gotta do an EOI > somehow, I need to check the docs) could you be more specific about the EOI problem? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Oct 3 11:26:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13178 for smp-outgoing; Thu, 3 Oct 1996 11:26:43 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13164 for freebsd-smp; Thu, 3 Oct 1996 11:26:42 -0700 (PDT) Date: Thu, 3 Oct 1996 11:26:42 -0700 (PDT) From: Steve Passe Message-Id: <199610031826.LAA13164@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include apic.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/03 11:26:40 Modified: i386/include apic.h Log: missed a macro change Revision Changes Path 1.5 +4 -4 sys/i386/include/apic.h From owner-freebsd-smp Thu Oct 3 11:28:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13579 for smp-outgoing; Thu, 3 Oct 1996 11:28:20 -0700 (PDT) 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 LAA13555 for ; Thu, 3 Oct 1996 11:28:15 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id CAA06666; Fri, 4 Oct 1996 02:27:36 +0800 (WST) Message-Id: <199610031827.CAA06666@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: dg@Root.COM cc: Doug Rabson , freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of "Thu, 03 Oct 1996 07:24:07 MST." <199610031424.HAA12159@root.com> Date: Fri, 04 Oct 1996 02:27:35 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > >Why not use a byte in struct proc for the cpuid of the processor which > >most recently ran the process. If there is a choice of highest-priority > >processes, each cpu could choose a process which it has run before, > >otherwise just pick the highest priority process as normal. > > Right, if the CPU that it ran on last isn't available, but another one is, > you don't want to *not* run it just because of the processor affinity. > > -DG Oh yes, definately.. It's just a question of how much value to put on the cache contents and how much we're prepared to bias things. Suppose we had three runnable processes, it'd be a shame to have two cpu's running them in turn and none of them getting back to the same cpu until the other two have run on it. We recalculate the the process priorities about 10 times per second, right? If we have three processes at equal priority, and hence the same run queue. If we change the selection algorithm from "front of queue" to "if there is a process in this queue with the same cpu id, choose it, otherwise pick the front", then we could have the situation where both cpus could run two of the three processes for 10 quantums and the third would get none until the next reschedule caclulation. Perhaps there would need to be a limit on the number of times a process could jump to the head of it's run queue just because it was last on the cpu? (eg: a limit of between 3 to 5 quantums) I suspect the "ideal" parameters will depend on the per-machine configuration. A couple of pentiums with their small on-chip cache and a single shared large cache would probably place less value on the per-cpu cache than perhaps a pentium-pro system with 256K (or 512K) on-chip with no shared cache would. Cheers, -Peter From owner-freebsd-smp Thu Oct 3 13:58:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA22873 for smp-outgoing; Thu, 3 Oct 1996 13:58:59 -0700 (PDT) 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 NAA22867 for ; Thu, 3 Oct 1996 13:58:56 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06712; Thu, 3 Oct 1996 13:55:15 -0700 From: Terry Lambert Message-Id: <199610032055.NAA06712@phaeton.artisoft.com> Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) To: dg@Root.COM Date: Thu, 3 Oct 1996 13:55:15 -0700 (MST) Cc: dfr@render.com, peter@spinner.dialix.com, ccsanady@friley216.res.iastate.edu, freebsd-smp@freebsd.org In-Reply-To: <199610031424.HAA12159@root.com> from "David Greenman" at Oct 3, 96 07:24:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Why not use a byte in struct proc for the cpuid of the processor which > >most recently ran the process. If there is a choice of highest-priority > >processes, each cpu could choose a process which it has run before, > >otherwise just pick the highest priority process as normal. > > Right, if the CPU that it ran on last isn't available, but another one is, > you don't want to *not* run it just because of the processor affinity. You need three queues (for 2 CPU's). A process that's preempted should be scheduled to run again on the same processor's queue. At the same time, the ready-to-run ordering needs to be global. The trade of moving a process of of one CPU's queue to run it on another CPU, thereby losing the locality which causes the CPU affinity to be real, is a scheduling policy decision. Policy and implementation should remain seperate, as much as is possible, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Thu Oct 3 14:01:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23095 for smp-outgoing; Thu, 3 Oct 1996 14:01:53 -0700 (PDT) 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 OAA23084 for ; Thu, 3 Oct 1996 14:01:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06723; Thu, 3 Oct 1996 13:58:58 -0700 From: Terry Lambert Message-Id: <199610032058.NAA06723@phaeton.artisoft.com> Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . To: peter@spinner.dialix.com (Peter Wemm) Date: Thu, 3 Oct 1996 13:58:58 -0700 (MST) Cc: dg@Root.COM, dfr@render.com, freebsd-smp@FreeBSD.org In-Reply-To: <199610031827.CAA06666@spinner.DIALix.COM> from "Peter Wemm" at Oct 4, 96 02:27:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Oh yes, definately.. It's just a question of how much value to put on the > cache contents and how much we're prepared to bias things. Suppose we had > three runnable processes, it'd be a shame to have two cpu's running them > in turn and none of them getting back to the same cpu until the other two > have run on it. This is a policy decision. Policy should be controllable by the system administrator. The trade between losing cache vs. losing CPU cycles really depnds on how compute intensive the code which will be running is going to be. The best thing that you could do would be to collect meaningful metrics and implement a very simple policy that reacts to them, leaving a more complex policy for when an administrator purposes the machine. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Thu Oct 3 15:10:35 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02085 for smp-outgoing; Thu, 3 Oct 1996 15:10:35 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02073 for freebsd-smp; Thu, 3 Oct 1996 15:10:28 -0700 (PDT) Date: Thu, 3 Oct 1996 15:10:28 -0700 (PDT) From: Steve Passe Message-Id: <199610032210.PAA02073@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/03 15:10:26 Modified: kern init_main.c Log: removed redundant extern (now supplied by smp.h) fixed cpu#1 freeze bug from last round of changes Revision Changes Path 1.25 +2 -4 sys/kern/init_main.c From owner-freebsd-smp Thu Oct 3 15:14:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02517 for smp-outgoing; Thu, 3 Oct 1996 15:14:48 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA02508 for freebsd-smp; Thu, 3 Oct 1996 15:14:44 -0700 (PDT) Date: Thu, 3 Oct 1996 15:14:44 -0700 (PDT) From: Steve Passe Message-Id: <199610032214.PAA02508@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 microtime.s mp_machdep.c mpapic.c pmap.c sys/i386/include apic.h smp.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/03 15:14:43 Modified: i386/i386 microtime.s mp_machdep.c mpapic.c pmap.c Log: added initial support for IO APIC: working symmetric code marked by "SMP_SYMIO" 'in progress' symmetric code marked by "SMP_SYMIOXXX" Revision Changes Path 1.9 +4 -1 sys/i386/i386/microtime.s 1.4 +34 -45 sys/i386/i386/mp_machdep.c 1.4 +220 -1 sys/i386/i386/mpapic.c 1.22 +2 -6 sys/i386/i386/pmap.c Modified: i386/include apic.h smp.h Log: added initial support for IO APIC: working symmetric code marked by "SMP_SYMIO" 'in progress' symmetric code marked by "SMP_SYMIOXXX" moved many extern decls from .c files to here. Revision Changes Path 1.6 +27 -5 sys/i386/include/apic.h 1.10 +11 -1 sys/i386/include/smp.h From owner-freebsd-smp Thu Oct 3 16:38:41 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09780 for smp-outgoing; Thu, 3 Oct 1996 16:38:41 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09773 for freebsd-smp; Thu, 3 Oct 1996 16:38:40 -0700 (PDT) Date: Thu, 3 Oct 1996 16:38:40 -0700 (PDT) From: Steve Passe Message-Id: <199610032338.QAA09773@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa icu.h if_ze.c isa.c npx.c vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/03 16:38:39 Modified: i386/isa icu.h if_ze.c isa.c npx.c vector.s Log: marked areas accessing the 8259 ICU with SMP_SYMIOXXX a few pieces of initial code (VERY raw, don't laugh) Revision Changes Path 1.2 +22 -1 sys/i386/isa/icu.h 1.2 +7 -9 sys/i386/isa/if_ze.c 1.2 +121 -101 sys/i386/isa/isa.c 1.6 +57 -1 sys/i386/isa/npx.c 1.13 +18 -3 sys/i386/isa/vector.s From owner-freebsd-smp Thu Oct 3 22:59:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22791 for smp-outgoing; Thu, 3 Oct 1996 22:59:06 -0700 (PDT) Received: from grunthos.pscwa.psca.com (grunthos.pscwa.psca.com [199.99.162.42]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA22783 for ; Thu, 3 Oct 1996 22:59:02 -0700 (PDT) Received: (from iyengar@localhost) by grunthos.pscwa.psca.com (8.6.12/8.6.12) id XAA17366; Thu, 3 Oct 1996 23:02:34 -0700 Date: Thu, 3 Oct 1996 23:02:34 -0700 From: Manu Iyengar Message-Id: <199610040602.XAA17366@grunthos.pscwa.psca.com> To: freebsd-smp@freebsd.org Subject: Anybody running on a Compaq Proliant? Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I may have a Compaq Proliant 5000 with 4 P6-166 CPUs for a little while. I'd like to see if the smp code will run on one of these beasts. I've been lurking on this list for a while and haven't seen any mention of compaq. Would folks know: a) What kind of chipsets these things have? b) What the SCSI controller is? (I'll try and poke around inside the case, but a cursory glance tells me that I need about two dozen different tools just to get at the motherboard :-) c) Any chance at all for the smp code to run? Compaq's web site is woefully lacking on any of these details. Any suggestions gratefully accepted. Thanks. ^mi From owner-freebsd-smp Thu Oct 3 23:19:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA23751 for smp-outgoing; Thu, 3 Oct 1996 23:19:48 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA23744; Thu, 3 Oct 1996 23:19:44 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id IAA00879; Fri, 4 Oct 1996 08:19:16 +0200 (MET DST) To: Manu Iyengar cc: freebsd-smp@freebsd.org Subject: Re: Anybody running on a Compaq Proliant? In-reply-to: Your message of "Thu, 03 Oct 1996 23:02:34 PDT." <199610040602.XAA17366@grunthos.pscwa.psca.com> Date: Fri, 04 Oct 1996 08:19:14 +0200 Message-ID: <877.844409954@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199610040602.XAA17366@grunthos.pscwa.psca.com>, Manu Iyengar writes : >I may have a Compaq Proliant 5000 with 4 P6-166 CPUs for a little >while. I'd like to see if the smp code will run on one of these >beasts. I've been lurking on this list for a while and haven't seen >any mention of compaq. Would folks know: > >a) What kind of chipsets these things have? Compaq. >b) What the SCSI controller is? Compaq. >c) Any chance at all for the smp code to run? Yes, I'd presume, but on the other hand I wouldn't fall of my chair if Compaq botched that too. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Fri Oct 4 01:07:03 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA29483 for smp-outgoing; Fri, 4 Oct 1996 01:07:03 -0700 (PDT) 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 BAA29478 for ; Fri, 4 Oct 1996 01:06:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id CAA21122; Fri, 4 Oct 1996 02:06:40 -0600 Message-Id: <199610040806.CAA21122@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: Manu Iyengar cc: freebsd-smp@freebsd.org Subject: Re: Anybody running on a Compaq Proliant? In-reply-to: Your message of "Thu, 03 Oct 1996 23:02:34 PDT." <199610040602.XAA17366@grunthos.pscwa.psca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Oct 1996 02:06:39 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I may have a Compaq Proliant 5000 with 4 P6-166 CPUs for a little > while. I'd like to see if the smp code will run on one of these > beasts. I've been lurking on this list for a while and haven't seen > any mention of compaq. Would folks know: > ... > c) Any chance at all for the smp code to run? grap mptable.c from the SMP web page aFrom owner-freebsd-smp Fri Oct 4 06:15:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA17281 for smp-outgoing; Fri, 4 Oct 1996 06:15:44 -0700 (PDT) Received: from Central.KeyWest.MPGN.COM (Central.TanSoft.COM [206.175.4.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA17276 for ; Fri, 4 Oct 1996 06:15:42 -0700 (PDT) Received: from devious.Tansoft.com (Devious.TanSoft.COM [206.175.4.10]) by Central.KeyWest.MPGN.COM (8.6.9/8.6.9) with SMTP id JAA16912 for ; Fri, 4 Oct 1996 09:14:47 -0400 Message-Id: <3.0b24.32.19961004091446.006a680c@central.TanSoft.COM> X-Sender: rwm@central.TanSoft.COM X-Mailer: Windows Eudora Pro Version 3.0b24 (32) Date: Fri, 04 Oct 1996 09:14:47 -0400 To: freebsd-smp@freebsd.org From: Rob Miracle Subject: SMP processor utilization question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are messing with the SMP kernel on a P6/200 Dual board. I am not sure of the board's maker. It has an AMI bios. Any way, since we upgraded the kernel from yesterday's (and again after todays) 8AM EDT fetch of the CVS tree, the new kernel shows (via ps aux) that (cpuidle1) is using 99.4 % of the CPU and (cpuidle0) is using 0% of the CPU. Vmstat shows 0% free CPU and 100% system calls. All process start times are 31Dec69. The load average is 1.92 sustanined. How can I test that both processors are working? Is this normal behavior? I have included the output from my mptable run. Thanks Rob -------------------------------------------------------------------------- Found MP Table in BIOS, physical addr: 0x000fb070 -------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fb070 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x21 mode: Virtual Wire -------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f5320 signature: 'PCMP' base table length: 276 version: 1.1 checksum: 0xc7 OEM ID: 'INTEL ' Product ID: '440FX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 26 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 -------------------------------------------------------------------------- MP Config Base Table Entries: -- Processor apic ID: 1, version: 17 CPU is usable, CPU is the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Processor apic ID: 0, version: 17 CPU is usable, CPU is NOT the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Bus bus ID: 0, bus type: PCI -- Bus bus ID: 1, bus type: ISA -- I/O APIC apic ID: 2, version: 17 APIC is usable apic address: 0xfec00000 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 1 destination APIC ID: 2, INT: 1 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 0 destination APIC ID: 2, INT: 2 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 3 destination APIC ID: 2, INT: 3 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 4 destination APIC ID: 2, INT: 4 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 5 destination APIC ID: 2, INT: 5 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 6 destination APIC ID: 2, INT: 6 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 7 destination APIC ID: 2, INT: 7 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 1, IRQ: 8 destination APIC ID: 2, INT: 8 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 9 destination APIC ID: 2, INT: 9 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 10 destination APIC ID: 2, INT: 10 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 11 destination APIC ID: 2, INT: 11 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 12 destination APIC ID: 2, INT: 12 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 13 destination APIC ID: 2, INT: 13 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 14 destination APIC ID: 2, INT: 14 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 1, IRQ: 15 destination APIC ID: 2, INT: 20 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 0, IRQ: 72 destination APIC ID: 2, INT: 17 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 0, IRQ: 76 destination APIC ID: 2, INT: 18 -- I/O INT INT type: 2, flags: 0x0000 source bus ID: 1, IRQ: 0 destination APIC ID: 2, INT: 23 -- Local INT INT type: 3, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 0 -- Local INT INT type: 1, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 1 -------------------------------------------------------------------------- -- Rob Miracle Tantalus Inc. Be patient or be a patient. -- Anton Devious From owner-freebsd-smp Fri Oct 4 06:54:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19866 for smp-outgoing; Fri, 4 Oct 1996 06:54:38 -0700 (PDT) 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 GAA19860 for ; Fri, 4 Oct 1996 06:54:24 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id VAA12611; Fri, 4 Oct 1996 21:53:37 +0800 (WST) Message-Id: <199610041353.VAA12611@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Rob Miracle cc: freebsd-smp@freebsd.org Subject: Re: SMP processor utilization question In-reply-to: Your message of "Fri, 04 Oct 1996 09:14:47 -0400." <3.0b24.32.19961004091446.006a680c@central.TanSoft.COM> Date: Fri, 04 Oct 1996 21:53:36 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rob Miracle wrote: > We are messing with the SMP kernel on a P6/200 Dual board. I am not sure > of the board's maker. It has an AMI bios. Any way, since we upgraded the > kernel from yesterday's (and again after todays) 8AM EDT fetch of the CVS > tree, the new kernel shows (via ps aux) that (cpuidle1) is using 99.4 % of > the CPU and > (cpuidle0) is using 0% of the CPU. Vmstat shows 0% free CPU and 100% > system calls. All process start times are 31Dec69. The load average is > 1.92 sustanined. > > How can I test that both processors are working? Is this normal behavior? > I have included the output from my mptable run. > > Thanks > Rob It's unexpected, but it's broken on my machine too. The two cpuidle procs should be about evenly allocated cpu time. I'm checking into it, it's most likely something I've broken when I created the variable number of idle procs for the available cpus. We have no easy way of indicating whether both cpus are actually running, or if once has hung. We can implement some of the hacks to help, including creating a P_ONCPU flag, as well as a last-cpu-id field in the proc structure. The top port in the ports collection could have some #ifdef P_ONCPU stuff to enable it to report the cpu id number on the display. One way of seeing it in action is to do a parallel make (such as the one in the NetBSD-current tree, somebody is merging the parallel support into ours too, it's nearly ready.) When you do a "time make -j4", check the %cpu usage. If it's over 100%, you have both cpus running usefully. ie: the processes consumed (say) 15 seconds of cpu time in only 10 seconds of wall-clock time. Cheers, -Peter From owner-freebsd-smp Fri Oct 4 08:34:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24980 for smp-outgoing; Fri, 4 Oct 1996 08:34:16 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24974 for ; Fri, 4 Oct 1996 08:34:12 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id RAA07487; Fri, 4 Oct 1996 17:15:46 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id QAA09495; Fri, 4 Oct 1996 16:01:47 +0200 (MET DST) Date: Fri, 4 Oct 1996 16:01:47 +0200 (MET DST) From: Andreas Klemm To: Peter Wemm cc: Rob Miracle , freebsd-smp@FreeBSD.org Subject: Re: SMP processor utilization question In-Reply-To: <199610041353.VAA12611@spinner.DIALix.COM> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 4 Oct 1996, Peter Wemm wrote: [ I made the same experiences with one heavily working and one idle CPU on a Tyan Tomcat II ] > It's unexpected, but it's broken on my machine too. The two cpuidle procs > should be about evenly allocated cpu time. Aaahh and yestarday evening I began to wonder, why the 2 cpu's are working so sloooww ;-)) Well, then I'll wait for the patches. Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Fri Oct 4 13:51:42 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14845 for smp-outgoing; Fri, 4 Oct 1996 13:51:42 -0700 (PDT) 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 NAA14835 for ; Fri, 4 Oct 1996 13:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA24658; Fri, 4 Oct 1996 14:51:30 -0600 Message-Id: <199610042051.OAA24658@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Rob Miracle cc: freebsd-smp@freebsd.org Subject: Re: SMP processor utilization question In-reply-to: Your message of "Fri, 04 Oct 1996 09:14:47 EDT." <3.0b24.32.19961004091446.006a680c@central.TanSoft.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Oct 1996 14:51:30 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >send. I did get an error when I redirected the output to a file, but did >not get it when piping it to less: > > Warning: EBDA support is BROKEN!! This message is because the variable I need is way down low where the kernel doesn't map memory, so I can't get at it from /dev/kmem in mptable. The kernel itself doesn't have this problem as it can directly read it during boot. This only appears to affect EISA and MCA boards, ie only they use EBDA. As to getting lost, it goes to stderr while the rest goes to stdout. --------------------------------------------------------------------------- Several people have noticed that the output of mptable says the CPU APIC version is 17 (0x11), while the boot probe says its 16 (0x10). I now have info for the case of a P6 from your mailing, specifically: mptable output for your dual P6: ... Processor apic ID: 1, version: 17 dmesg output of your dual P6: ... FreeBSD/SMP: Multiprocessor motherboard BSP APIC ID: 1, version: 0x00040011 AP APIC IDs: 0 IO APIC IDs: 2, version: 0x00170011 # of APs available: 1, # of APs started: 1 In this case (ie P6) THEY MATCH. Also note the fact that the '4' in the 5th (from the right) digit is correct for a P6. --- mptable output for my P5: ... Processor apic ID: 0, version: 17 dmesg output of my dual P5 (text diffs from slightly newer kernel): FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 io0 (APIC): apic id: 2, version: 0x00170011 In this case (ie P5) THEY DON'T MATCH. Note the fact that the '3' in the 5th field is correct for a P5. My conclusion is that the Intel MP BIOS extensions report this wrong, or perhaps it is a "feature" that I haven't decoded out of the spec yet... --- Keep those mptable reports coming, folks, they are useful. If you have the MP kernel running also include the SMP specific dmesg output. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Oct 4 14:17:54 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17448 for smp-outgoing; Fri, 4 Oct 1996 14:17:54 -0700 (PDT) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17427 for freebsd-smp; Fri, 4 Oct 1996 14:17:49 -0700 (PDT) Date: Fri, 4 Oct 1996 14:17:49 -0700 (PDT) From: Steve Passe Message-Id: <199610042117.OAA17427@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include mpapic.h apic.h smp.h sys/i386/i386 machdep.c mp_machdep.c mpapic.c mpboot.s pmap.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/10/04 14:17:48 Modified: i386/i386 machdep.c mp_machdep.c mpapic.c mpboot.s pmap.c i386/include apic.h smp.h Added: i386/include mpapic.h Log: major cleanup of header files: smp.h, apic.h, (new) mpapic.h smp.h for external data and function declarations apic.h for APIC register defines mpapic.h for APIC macros, inlines, etc. modified files as necessary for these header changes. added code for APs to report their version on bootstrap. more 'style' cleanup. Revision Changes Path 1.26 +7 -10 sys/i386/i386/machdep.c 1.5 +58 -32 sys/i386/i386/mp_machdep.c 1.5 +27 -16 sys/i386/i386/mpapic.c 1.5 +2 -0 sys/i386/i386/mpboot.s 1.23 +2 -1 sys/i386/i386/pmap.c 1.7 +32 -197 sys/i386/include/apic.h 1.11 +55 -22 sys/i386/include/smp.h From owner-freebsd-smp Fri Oct 4 17:22:37 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA07129 for smp-outgoing; Fri, 4 Oct 1996 17:22:37 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA07118 for freebsd-smp; Fri, 4 Oct 1996 17:22:35 -0700 (PDT) Date: Fri, 4 Oct 1996 17:22:35 -0700 (PDT) From: Peter Wemm Message-Id: <199610050022.RAA07118@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 genassym.c mpboot.s swtch.s sys/kern init_main.c sys/sys proc.h sys/vm vm_meter.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/04 17:22:35 Modified: i386/i386 genassym.c mpboot.s swtch.s kern init_main.c sys proc.h vm vm_meter.c Log: sync with my current sources. I think the kernel has been pretty broken for a while now, but I don't think this makes things much worse. I'm checkpointing now so I can try some backouts without loosing what I'm working on. In here: - Adds a P_IDLEPROC flag based on a suggestion by: "Chris Csanady" - uses two padding fields in the proc struct for p_oncpu and p_lastcpu to hold the current cpu (when executing) and the last cpu it was on. I've got a modified 'top' that shows this info to try and understand the current problems. - adds a kern.idle_debug sysctl variable for seeing how the idle procs are being executed on both cpus. Revision Changes Path 1.5 +2 -0 sys/i386/i386/genassym.c 1.6 +0 -4 sys/i386/i386/mpboot.s 1.24 +9 -2 sys/i386/i386/swtch.s 1.26 +32 -13 sys/kern/init_main.c 1.13 +6 -1 sys/sys/proc.h 1.2 +12 -10 sys/vm/vm_meter.c From owner-freebsd-smp Fri Oct 4 22:04:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25496 for smp-outgoing; Fri, 4 Oct 1996 22:04:36 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25489 for freebsd-smp; Fri, 4 Oct 1996 22:04:35 -0700 (PDT) Date: Fri, 4 Oct 1996 22:04:35 -0700 (PDT) From: Peter Wemm Message-Id: <199610050504.WAA25489@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/sys kernel.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/04 22:04:34 Modified: sys kernel.h Log: add back placeholder for kthread_idle startup method while I'm hunting for bugs. Revision Changes Path 1.10 +1 -0 sys/sys/kernel.h From owner-freebsd-smp Fri Oct 4 22:06:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25607 for smp-outgoing; Fri, 4 Oct 1996 22:06:58 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25600 for freebsd-smp; Fri, 4 Oct 1996 22:06:56 -0700 (PDT) Date: Fri, 4 Oct 1996 22:06:56 -0700 (PDT) From: Peter Wemm Message-Id: <199610050506.WAA25600@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mpboot.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/04 22:06:56 Modified: i386/i386 mpboot.s Log: back out locking semaphore for sequential N-cpu booting.. Something else is preventing this strategy from working yet. Revision Changes Path 1.7 +12 -2 sys/i386/i386/mpboot.s From owner-freebsd-smp Fri Oct 4 22:14:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25928 for smp-outgoing; Fri, 4 Oct 1996 22:14:00 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25920 for freebsd-smp; Fri, 4 Oct 1996 22:13:58 -0700 (PDT) Date: Fri, 4 Oct 1996 22:13:58 -0700 (PDT) From: Peter Wemm Message-Id: <199610050513.WAA25920@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern kern_clock.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/04 22:13:58 Modified: kern kern_clock.c Log: exclude the P_IDLEPROC processes from the %system stats, use %idle instead. Revision Changes Path 1.2 +27 -25 sys/kern/kern_clock.c From owner-freebsd-smp Fri Oct 4 22:17:40 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26058 for smp-outgoing; Fri, 4 Oct 1996 22:17:40 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA26052 for ; Fri, 4 Oct 1996 22:17:21 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id NAA00374 for ; Sat, 5 Oct 1996 13:16:43 +0800 (WST) Message-Id: <199610050516.NAA00374@spinner.DIALix.COM> To: smp@freebsd.org Subject: bad commit Date: Sat, 05 Oct 1996 13:16:43 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had a finger slip again, and attempted to commit to the wrong tree. The commit is in the right files, but the mail message went to the wrong address. Anyway, the message: ------- Forwarded Message Date: Fri, 04 Oct 1996 22:10:10 -0700 From: Peter Wemm To: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-other@freefall.freebsd.org Subject: cvs commit: /home/smp/sys/kern init_main.c peter 96/10/04 22:10:09 Modified: home/smp/sys/kern init_main.c Log: revive some code I deleted while tracking down the startup bugs. The automatic enabling of smp_active is gone again, this seems to be part of the problem. The smp kernel should be working now without the freezes and lockups. Revision Changes Path 1.27 +58 -17 /home/smp/sys/kern/init_main.c ------- End of Forwarded Message From owner-freebsd-smp Fri Oct 4 22:25:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26405 for smp-outgoing; Fri, 4 Oct 1996 22:25:52 -0700 (PDT) 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 WAA26397 for ; Fri, 4 Oct 1996 22:25:43 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id NAA00432 for ; Sat, 5 Oct 1996 13:25:33 +0800 (WST) Message-Id: <199610050525.NAA00432@spinner.DIALix.COM> To: smp@freebsd.org Subject: top patches for smp.. Date: Sat, 05 Oct 1996 13:25:32 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If anybody's interested, these patches will show some extra info when top is running. I can't remember if I've send this already.. Hope not. :-) With this, instead of "RUN", you will see either "CPU0/1" or "RUN/1". In this case, "CPU0/1" means that the process is currently on cpu 0, and the "1" is meaningless.. It's set at the same time I just realised. :-] The idea was that you could see the current and "last" cpu, so you had a chance of seeing procs bouncing from one cpu to another, maybe later.. "RUN/1" means it is runnable, waiting in the run queue and last ran on cpu#1. If 'ps' is showing "31Dec69" or "1Jan70", your libkvm is out of sync. I don't know what has changed that caused this BTW. I changed the /sys symlink so I could compile libkvm and top/ps/etc. Index: files/m_freebsd2.c =================================================================== RCS file: /home/ncvs/ports/sysutils/top/files/m_freebsd2.c,v retrieving revision 1.8 diff -u -r1.8 m_freebsd2.c --- m_freebsd2.c 1996/09/28 09:55:32 1.8 +++ m_freebsd2.c 1996/10/04 18:12:34 @@ -523,6 +523,7 @@ register long cputime; register double pct; struct handle *hp; + char runbuf[16]; /* find and remember the next proc structure */ hp = (struct handle *)handle; @@ -555,6 +556,25 @@ /* calculate the base for cpu percentages */ pct = pctdouble(PP(pp, p_pctcpu)); + /* generate "STATE" field */ + switch (PP(pp, p_stat)) { + case SRUN: + if (PP(pp, p_oncpu) >= 0) + sprintf(runbuf, "CPU#%d/%d", PP(pp, p_oncpu), PP(pp, p_lastcpu)) + else + sprintf(runbuf, "RUN/%d", PP(pp, p_lastcpu)); + break; + case SSLEEP: + if (PP(pp, p_wmesg) != NULL) { + sprintf(runbuf, "%.6s", EP(pp, e_wmesg)); + break; + } + /* fall through */ + default: + sprintf(runbuf, "%s", state_abbrev[(unsigned char) PP(pp, p_stat)]); + break; + } + /* format this entry */ sprintf(fmt, Proc_format, @@ -564,9 +584,7 @@ PP(pp, p_nice) - NZERO, format_k(pagetok(PROCSIZE(pp))), format_k(pagetok(VP(pp, vm_rssize))), - ( (PP(pp, p_stat) == SSLEEP) && (PP(pp, p_wmesg) != NULL) ) ? - EP(pp, e_wmesg) : - state_abbrev[(unsigned char) PP(pp, p_stat)], + runbuf, format_time(cputime), 10000.0 * weighted_cpu(pct, pp) / hz, 10000.0 * pct / hz, Cheers, -Peter From owner-freebsd-smp Fri Oct 4 22:31:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26638 for smp-outgoing; Fri, 4 Oct 1996 22:31:13 -0700 (PDT) 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 WAA26625 for ; Fri, 4 Oct 1996 22:31:04 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id NAA00477 for ; Sat, 5 Oct 1996 13:30:59 +0800 (WST) Message-Id: <199610050530.NAA00477@spinner.DIALix.COM> To: smp@freebsd.org Subject: gdb -k patches for smp kernels Date: Sat, 05 Oct 1996 13:30:58 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In order to run "gdb -k /kernel /dev/mem" on a smp kernel, you need the following [crude, ugly, bogus, etc] patches: Index: freebsd-nat.c =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/gdb/gdb/freebsd-nat.c,v retrieving revision 1.10 diff -u -r1.10 freebsd-nat.c --- freebsd-nat.c 1996/06/08 11:03:19 1.10 +++ freebsd-nat.c 1996/07/18 19:34:07 @@ -29,6 +29,8 @@ #include #include "defs.h" +#include "symtab.h" +#include "inferior.h" /* this table must line up with REGISTER_NAMES in tm-i386v.h */ /* symbols like 'tEAX' come from */ @@ -351,6 +383,7 @@ struct stat stb; CORE_ADDR addr; int cfd; + struct minimal_symbol *sym; if ((cfd = open(cfile, perm, 0)) < 0) return (cfd); @@ -363,7 +396,12 @@ physrd(cfd, ksym_lookup("IdlePTD") - KERNOFF, (char*)&sbr, sizeof sbr); printf("IdlePTD %x\n", sbr); - curpcb = ksym_lookup("curpcb") - KERNOFF; + + sym = lookup_minimal_symbol("SMPcurpcb", (struct objfile *)NULL); + if (sym != NULL) + curpcb = ksym_lookup("SMPcurpcb") - KERNOFF; + else + curpcb = ksym_lookup("curpcb") - KERNOFF; physrd(cfd, curpcb, (char*)&curpcb, sizeof curpcb); kstack = ksym_lookup("kstack"); Index: kcorelow.c =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/gdb/gdb/kcorelow.c,v retrieving revision 1.4 diff -u -r1.4 kcorelow.c --- kcorelow.c 1995/05/30 04:57:22 1.4 +++ kcorelow.c 1996/07/18 08:44:48 @@ -86,7 +86,14 @@ curProc() { struct proc *p; - CORE_ADDR addr = ksym_lookup("curproc"); + CORE_ADDR addr; + struct minimal_symbol *sym; + + sym = lookup_minimal_symbol("SMPcurproc", (struct objfile *)NULL); + if (sym != NULL) + addr = ksym_lookup("SMPcurproc"); + else + addr = ksym_lookup("curproc"); if (kvread(addr, &p)) error("cannot read proc pointer at %x\n", addr); I've been using these hacks for a while, even though they're not exactly correct, but they work for simple stuff (eg: read/modify data). They adapt to the style of kernel, so these patches will work on both kernels if you are flipping back and forward from smp kernels like I am. -Peter From owner-freebsd-smp Sat Oct 5 01:45:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA03735 for smp-outgoing; Sat, 5 Oct 1996 01:45:36 -0700 (PDT) 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 BAA03730 for ; Sat, 5 Oct 1996 01:45:33 -0700 (PDT) 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 DAA03603; Sat, 5 Oct 1996 03:45:23 -0500 (CDT) Message-Id: <199610050845.DAA03603@friley216.res.iastate.edu> To: Peter Wemm cc: smp@freebsd.org Subject: Re: top patches for smp.. In-reply-to: Your message of Sat, 05 Oct 1996 13:25:32 +0800. <199610050525.NAA00432@spinner.DIALix.COM> Date: Sat, 05 Oct 1996 03:45:22 -0500 From: "Chris Csanady" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >If anybody's interested, these patches will show some extra info when >top is running. I can't remember if I've send this already.. Hope >not. :-) > >With this, instead of "RUN", you will see either "CPU0/1" or "RUN/1". >In this case, "CPU0/1" means that the process is currently on cpu 0, >and the "1" is meaningless.. It's set at the same time I just realised. >:-] The idea was that you could see the current and "last" cpu, so you >had a chance of seeing procs bouncing from one cpu to another, maybe >later.. > >"RUN/1" means it is runnable, waiting in the run queue and last ran on >cpu#1. Hmm.. when I run this, i the states are always either "RUN/0", or "CPU#0/". (no 1 at the end of that.) Am I not using both cpus? I could swear I am since a parallel make is about 70% faster.. :\ Although, i hardly ever see a "CPU#0/". Ive been trying to think why such a thing would occur, but so far have come up with nothing. Something I have been wondering about though.. shouldn't clock interrupts be processed on both cpus? I mean isnt this where the p_cpuest is incremented for the current process? It seems that if only one cpu can be in kernel then only one would handle it, and it would mess with the scheduling priorities. But then, I may just have no clue what im talking about. :) Im not quite sure about how interrupts need to/are handled now.. Anyways, its just so hard to think about some of this stuff.. Another thing i was pondering.. if the recomputation of priorities (among other fixed time interval things) happened to coincide on both cpus, undesireable effects may occur.. Well, i really need to get some sleep.. Chris Csanady From owner-freebsd-smp Sat Oct 5 02:00:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA04281 for smp-outgoing; Sat, 5 Oct 1996 02:00:08 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA04265; Sat, 5 Oct 1996 02:00:02 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id KAA03114; Sat, 5 Oct 1996 10:59:24 +0200 (MET DST) To: "Chris Csanady" cc: Peter Wemm , smp@freebsd.org Subject: Re: top patches for smp.. In-reply-to: Your message of "Sat, 05 Oct 1996 03:45:22 CDT." <199610050845.DAA03603@friley216.res.iastate.edu> Date: Sat, 05 Oct 1996 10:59:23 +0200 Message-ID: <3112.844505963@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199610050845.DAA03603@friley216.res.iastate.edu>, "Chris Csanady" w >Hmm.. when I run this, i the states are always either "RUN/0", or "CPU#0/". >(no 1 at the end of that.) Am I not using both cpus? I could swear I am >since a parallel make is about 70% faster.. :\ Although, i hardly ever >see a "CPU#0/". a parallel make is faster on uniprocessor too. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Sat Oct 5 09:18:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24108 for smp-outgoing; Sat, 5 Oct 1996 09:18:46 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24098 for freebsd-smp; Sat, 5 Oct 1996 09:18:45 -0700 (PDT) Date: Sat, 5 Oct 1996 09:18:45 -0700 (PDT) From: Peter Wemm Message-Id: <199610051618.JAA24098@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 swtch.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/05 09:18:44 Modified: i386/i386 swtch.s Log: Fix the p_lastcpu recording. Revision Changes Path 1.25 +2 -1 sys/i386/i386/swtch.s From owner-freebsd-smp Sat Oct 5 12:51:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA04626 for smp-outgoing; Sat, 5 Oct 1996 12:51:56 -0700 (PDT) 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 MAA04621 for ; Sat, 5 Oct 1996 12:51:53 -0700 (PDT) Received: (from smp@localhost) by bluenose.na.tuns.ca (8.7.6/8.7.3) id QAA25572 for freebsd-smp@freefall.cdrom.com; Sat, 5 Oct 1996 16:29:13 -0300 (ADT) From: "J.M. Chuang" Message-Id: <199610051929.QAA25572@bluenose.na.tuns.ca> Subject: Help To: freebsd-smp@freefall.freebsd.org Date: Sat, 5 Oct 1996 16:29:12 -0300 (ADT) 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 Hi: The kernel built with sys-smp supped yesterday stops at APPLICATION CPU #1 LUNCHED !! when system boots up. I believed that it is related to `cpu_switch(curproc)' in /sys/kern/init_main.c with Tyan Titan Pro motherboard. Thanks in advance for help! Jim From owner-freebsd-smp Sat Oct 5 13:04:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05060 for smp-outgoing; Sat, 5 Oct 1996 13:04:58 -0700 (PDT) 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 NAA05054 for ; Sat, 5 Oct 1996 13:04:31 -0700 (PDT) Received: (from ccsanady@localhost) by friley216.res.iastate.edu (8.7.6/8.7.3) id PAA00209 for freebsd-smp@freebsd.org; Sat, 5 Oct 1996 15:04:22 -0500 (CDT) Date: Sat, 5 Oct 1996 15:04:22 -0500 (CDT) From: Chris Csanady Message-Id: <199610052004.PAA00209@friley216.res.iastate.edu> To: freebsd-smp@freebsd.org Subject: Second processor does nothin?! Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After applying Peters diffs for top, I noticed that nothing seems to be running on the second cpu, ever. I thought that maybe somehow top wasnt reporting it correctly, so i added the following in init_main.c: if ((whichqs || whichrtqs || whichidqs) && cpunumber() == idle_debug){ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which would essentially mean things would only run on idle_debug cpu. (i got rid of the other stuff it did, just uding the variable.) When it boots up, and this is 0, there are no problems. However if I change it to 1, the machine freezes. Am I missing something, or is this just broken? Chris Csanady From owner-freebsd-smp Sat Oct 5 13:09:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05253 for smp-outgoing; Sat, 5 Oct 1996 13:09:58 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA05248; Sat, 5 Oct 1996 13:09:53 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id WAA04011; Sat, 5 Oct 1996 22:09:17 +0200 (MET DST) To: "J.M. Chuang" cc: freebsd-smp@freefall.freebsd.org Subject: Re: Help In-reply-to: Your message of "Sat, 05 Oct 1996 16:29:12 -0300." <199610051929.QAA25572@bluenose.na.tuns.ca> Date: Sat, 05 Oct 1996 22:09:16 +0200 Message-ID: <4009.844546156@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199610051929.QAA25572@bluenose.na.tuns.ca>, "J.M. Chuang" writes: >Hi: > >The kernel built with sys-smp supped yesterday stops at > >APPLICATION CPU #1 LUNCHED !! well, what do you expect ? It's the modern day equvivalent of the good ol' fashioned "Out to Lunch, back at 1 1/2 pm" signs you used to find on any door you tried to go through. :-) Sorry, I couldn't resist :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Sat Oct 5 13:13:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05440 for smp-outgoing; Sat, 5 Oct 1996 13:13:10 -0700 (PDT) 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 NAA05433 for ; Sat, 5 Oct 1996 13:13:05 -0700 (PDT) Received: (from ccsanady@localhost) by friley216.res.iastate.edu (8.7.6/8.7.3) id PAA00251 for freebsd-smp@freebsd.org; Sat, 5 Oct 1996 15:12:51 -0500 (CDT) Date: Sat, 5 Oct 1996 15:12:51 -0500 (CDT) From: Chris Csanady Message-Id: <199610052012.PAA00251@friley216.res.iastate.edu> To: freebsd-smp@freebsd.org Subject: Re: Second processor does nothin?! Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Oops... my bad. I didnt notice that the second processor is not being started automatically anymore. After I turn it on, and switch set things to run on the other cpu, things work fine. Top shows that they are always running on CPU1.. :( Id say something is Not Quite Right with the scheduling. I will ponder it more I guess. One thing I did notice was that the idle loops were both running on CPU0.. perhaps this is the problem. Laters, Chris Csanady From owner-freebsd-smp Sat Oct 5 13:38:37 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07004 for smp-outgoing; Sat, 5 Oct 1996 13:38:37 -0700 (PDT) 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 NAA06989 for ; Sat, 5 Oct 1996 13:38:29 -0700 (PDT) Received: (from ccsanady@localhost) by friley216.res.iastate.edu (8.7.6/8.7.3) id PAA00290 for freebsd-smp@freebsd.org; Sat, 5 Oct 1996 15:37:54 -0500 (CDT) Date: Sat, 5 Oct 1996 15:37:54 -0500 (CDT) From: Chris Csanady Message-Id: <199610052037.PAA00290@friley216.res.iastate.edu> To: freebsd-smp@freebsd.org Subject: Ignore my last 2 messages please.. Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think ive been staring at this for too long, or im just stupid today. Im not sure what exactly i did, but I shouldnt have sent any mail. Next time I suppose I will think I little more.. Sorry, Chris From owner-freebsd-smp Sat Oct 5 13:44:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07266 for smp-outgoing; Sat, 5 Oct 1996 13:44:30 -0700 (PDT) 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 NAA07248 for ; Sat, 5 Oct 1996 13:44:23 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id EAA01848; Sun, 6 Oct 1996 04:43:20 +0800 (WST) Message-Id: <199610052043.EAA01848@spinner.DIALix.COM> To: Chris Csanady cc: freebsd-smp@freebsd.org Subject: Re: Second processor does nothin?! In-reply-to: Your message of "Sat, 05 Oct 1996 15:12:51 EST." <199610052012.PAA00251@friley216.res.iastate.edu> Date: Sun, 06 Oct 1996 04:43:20 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > Oops... my bad. I didnt notice that the second processor is not being starte d > automatically anymore. After I turn it on, and switch set things to run on > the other cpu, things work fine. Top shows that they are always running on > CPU1.. :( Id say something is Not Quite Right with the scheduling. I will > ponder it more I guess. One thing I did notice was that the idle loops were > both running on CPU0.. perhaps this is the problem. > > Laters, > Chris Csanady I've tweaked it a bit more since I committed the top changes to the ports collection: Index: files/m_freebsd2.c =================================================================== RCS file: /home/ncvs/ports/sysutils/top/files/m_freebsd2.c,v retrieving revision 1.9 diff -u -r1.9 m_freebsd2.c --- m_freebsd2.c 1996/10/05 13:42:31 1.9 +++ m_freebsd2.c 1996/10/05 16:22:48 @@ -20,8 +20,6 @@ * $Id: m_freebsd2.c,v 1.9 1996/10/05 13:42:31 peter Exp $ */ - - #define LASTPID /**/ /* use last pid, compiler depended */ #define VM_REAL /**/ /* use the same values as vmstat -s */ #define USE_SWAP /**/ /* use swap usage (pstat -s), @@ -128,12 +126,12 @@ */ static char header[] = - " PID X PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; + " PID X PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND"; /* 0123456 -- field to fill in starts at header+6 */ #define UNAME_START 6 #define Proc_format \ - "%5d %-8.8s %3d %4d%6s %5s %-6.6s%7s %5.2f%% %5.2f%% %.14s" + "%5d %-8.8s %3d%4d%6s %5s %-7.7s%7s %5.2f%% %5.2f%% %.14s" /* process state names for the "STATE" column of the display */ @@ -561,23 +559,28 @@ case SRUN: #ifdef P_IDLEPROC /* FreeBSD SMP kernel */ if (PP(pp, p_oncpu) >= 0) - sprintf(status, "CPU%d/%d", PP(pp, p_oncpu), PP(pp, p_lastcpu)); + sprintf(status, " CPU%d", PP(pp, p_oncpu)); else - sprintf(status, "RUN/%d", PP(pp, p_lastcpu)); -#else - strcpy(status, "RUN"); #endif + strcpy(status, " RUN"); break; case SSLEEP: if (PP(pp, p_wmesg) != NULL) { - sprintf(status, "%.6s", EP(pp, e_wmesg)); + sprintf(status, " %.6s", EP(pp, e_wmesg)); break; } /* fall through */ default: - sprintf(status, "%.6s", state_abbrev[(unsigned char) PP(pp, p_stat)]); + sprintf(status, " %.6s", state_abbrev[(unsigned char) PP(pp, p_stat)]); break; } +#ifdef P_IDLEPROC /* FreeBSD SMP kernel */ + status[0] = PP(pp, p_lastcpu); + if (status[0] > 9) + status[0] += 'A'; + else + status[0] += '0'; +#endif /* format this entry */ sprintf(fmt, This moves the columns a little to make room for the "lastcpu" field always. It will show you a lot more about the scheduling habits, since you'll see where the sleeping processes last ran. There is quite a spread: load averages: 0.81, 0.55, 0.58 04:35:14 65 processes: 4 running, 61 sleeping Mem: 23M Active, 6756K Inact, 11M Wired, 5024K Cache, 3136K Buf, 704K Free Swap: 160M Total, 14M Used, 146M Free, 9% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 6 root -6 0 0K 12K 1RUN 0:00 37.23% 37.23% cpuidle1 5 root -6 0 0K 12K 1RUN 0:00 34.45% 34.45% cpuidle0 341 root 92 0 1080K 1488K 1CPU1 0:29 16.15% 14.95% perl 1382 peter 33 0 312K 988K 0CPU0 0:00 0.00% 0.00% top 4 root 28 0 0K 12K 1update 0:06 0.00% 0.00% update 3 root 28 0 0K 12K 0psleep 0:00 0.00% 0.00% vmdaemon 212 peter 18 0 852K 908K 0pause 0:05 0.00% 0.00% tcsh 213 peter 18 0 796K 820K 1pause 0:03 0.00% 0.00% tcsh 211 root 18 0 860K 488K 1pause 0:05 0.00% 0.00% tcsh 145 root 18 0 268K 356K 0pause 0:01 0.00% 0.00% cron 22 root 10 0 20M 940K 1mfsidl 0:00 0.00% 0.00% mount_mfs 29339 peter 10 0 312K 780K 0wait 0:00 0.00% 0.00% repl 340 root 10 0 320K 688K 1wait 0:00 0.00% 0.00% make 1353 root 10 0 384K 460K 1wait 0:00 0.00% 0.00% make 339 root 10 0 576K 228K 0wait 0:00 0.00% 0.00% sh 21776 root 10 0 576K 216K 0wait 0:00 0.00% 0.00% sh 21789 root 10 0 576K 216K 0wait 0:00 0.00% 0.00% sh 21780 root 10 0 576K 216K 0wait 0:00 0.00% 0.00% sh 1 root 10 0 448K 76K 1wait 0:00 0.00% 0.00% init 123 root 10 0 208K 12K 0nfsidl 0:00 0.00% 0.00% nfsiod And, as you can see from this sample, top happened to be running on cpu0 while taking the snapshot, and both idleprocs had been on #1 last. Both cpus were actually running things during the snapshot. I suspect that the reason things tend to run on cpu#1 first is because cpu1 is never interrupted, except for traps generated by the process it is currently executing. This probably biases things somewhat, since when a user-mode process starts up, if it begins on cpu0 it won't be long before it's quantum expires on #0, and cpu#1 grabs it.. And it'll stay there as long as it pleases. This is probably enough to explain the bias. Cheers, -Peter From owner-freebsd-smp Sat Oct 5 14:47:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA10411 for smp-outgoing; Sat, 5 Oct 1996 14:47:44 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA10400; Sat, 5 Oct 1996 14:47:32 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id XAA04190; Sat, 5 Oct 1996 23:47:02 +0200 (MET DST) To: Peter Wemm cc: Chris Csanady , freebsd-smp@freebsd.org Subject: Re: Second processor does nothin?! In-reply-to: Your message of "Sun, 06 Oct 1996 04:43:20 +0800." <199610052043.EAA01848@spinner.DIALix.COM> Date: Sat, 05 Oct 1996 23:47:02 +0200 Message-ID: <4188.844552022@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I suspect that the reason things tend to run on cpu#1 first is because >cpu1 is never interrupted, except for traps generated by the process it >is currently executing. This probably biases things somewhat, since when >a user-mode process starts up, if it begins on cpu0 it won't be long before >it's quantum expires on #0, and cpu#1 grabs it.. And it'll stay there as >long as it pleases. This is probably enough to explain the bias. Actually I talked with a Very Old Man some time ago, and he said that we might not really want to change that habit. His argumentation was derived from computers I've never had to work with, but he sure knew where all his towele were. Basically what he told me was that with some number of CPUs you will want to dedicate some of them for "batch" kind of applications and some for interactive. Letting the batch cpus have larger, potentially infinite quantums will improve the benefit we get from caches and so on, not just because they concentrate on those jobs, but also because your heavy duty i/o interrupts end up in cache on the cpu they hit. The point is that interactive jobs that end up on a "batch" cpu don't really suffer, they will so something that deschedules them anyway, the one case where you suffer is when a low priority batch process gets on the CPU and a high-priority interactive job cannot get it, but according to him, that would be a rare thing indeed, since even "batch" jobs do a lot of I/O and generally deschedule at least several times per second because of that. He suggested keeping track of each processes "mean time between voluntary deschedule" and assign it to a cpu based on that. It's certainly not an uninteresting idea. He said that if he was involved (something I'm not very lucky at making happen) "he would make sure that he could tie each irq to a particular (group of) CPU(s) and that the quantum timers for all cpu's would be tweakable." Which I think is common sense :-) Even though the apic timer is quite junky from various points of view, it could be used for quantum counter, and thus be per cpu. Maybe we need to start measuring the rate of volutary vs. involuntary deschedules in FreeBSD. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Sat Oct 5 15:10:54 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11463 for smp-outgoing; Sat, 5 Oct 1996 15:10:54 -0700 (PDT) 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 PAA11370 for ; Sat, 5 Oct 1996 15:09:58 -0700 (PDT) Received: (from smp@localhost) by bluenose.na.tuns.ca (8.7.6/8.7.3) id SAA26003 for freebsd-smp@freefall.cdrom.com; Sat, 5 Oct 1996 18:48:50 -0300 (ADT) From: "J.M. Chuang" Message-Id: <199610052148.SAA26003@bluenose.na.tuns.ca> Subject: Spelling Error To: freebsd-smp@freefall.freebsd.org Date: Sat, 5 Oct 1996 18:48:49 -0300 (ADT) 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 Sorry for the spelling error in the last mail! The kernel built with sys-smp suped yesterday stops at APPLICATION CPU #1 'LAUNCHED' !! when system boots up. I believed that it is related to `cpu_switch(curproc)' in init_main with Tyan Titan Pro motherboard. Thanks in advance for help! Jim From owner-freebsd-smp Sat Oct 5 16:20:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17114 for smp-outgoing; Sat, 5 Oct 1996 16:20:32 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA17040 for ; Sat, 5 Oct 1996 16:20:11 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id BAA10365; Sun, 6 Oct 1996 01:01:36 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id AAA09763; Sun, 6 Oct 1996 00:47:37 +0200 (MET DST) Date: Sun, 6 Oct 1996 00:47:36 +0200 (MET DST) From: Andreas Klemm To: Peter Wemm cc: Chris Csanady , freebsd-smp@FreeBSD.ORG Subject: Re: Second processor does nothin?! In-Reply-To: <199610052043.EAA01848@spinner.DIALix.COM> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Oct 1996, Peter Wemm wrote: > Index: files/m_freebsd2.c > =================================================================== > RCS file: /home/ncvs/ports/sysutils/top/files/m_freebsd2.c,v > retrieving revision 1.9 could you please send me the whole m_freebsd2.c file ?! Something went wrong when trying to patch the file from the -current ports collection ... hunk #3 failed ... Thanks Andreas /// __ andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Sat Oct 5 19:46:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01103 for smp-outgoing; Sat, 5 Oct 1996 19:46:15 -0700 (PDT) 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 TAA01097 for ; Sat, 5 Oct 1996 19:46:13 -0700 (PDT) Received: (from smp@localhost) by bluenose.na.tuns.ca (8.7.6/8.7.3) id XAA26778; Sat, 5 Oct 1996 23:25:16 -0300 (ADT) From: "J.M. Chuang" Message-Id: <199610060225.XAA26778@bluenose.na.tuns.ca> Subject: Re: Help To: smp@csn.net (Steve Passe) Date: Sat, 5 Oct 1996 23:25:16 -0300 (ADT) Cc: freebsd-smp@freefall.freebsd.org In-Reply-To: <199610052323.RAA03972@clem.systemsix.com> from Steve Passe at "Oct 5, 96 05:23:21 pm" 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 > > there has been a lot of changes the last couple days, try re-supping > to see if this fixes the problem, youre probably just out of sync. > Thanks. It works! Jim From owner-freebsd-smp Sat Oct 5 23:58:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA19881 for smp-outgoing; Sat, 5 Oct 1996 23:58:57 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA19876 for ; Sat, 5 Oct 1996 23:58:54 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA23493; Sun, 6 Oct 1996 08:45:20 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id IAA12470; Sun, 6 Oct 1996 08:43:19 +0200 (MET DST) Date: Sun, 6 Oct 1996 08:43:18 +0200 (MET DST) From: Andreas Klemm To: Peter Wemm cc: freebsd-smp@FreeBSD.ORG Subject: top 3.4 with new smp changes looks smart In-Reply-To: <199610052328.HAA02775@spinner.DIALix.COM> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Here my top's output ... The only things, that I need to test is, if the overall system performance increased or decreased ... Doing a make depend in the smp kernel area shows slightly increasing values with 2 cpu's turned on ... First make depend one cpu Sun Oct 6 07:53:33 MET DST 1996 Sun Oct 6 07:54:16 MET DST 1996 -> 43 sec. 2nd make depend two cpu's Sun Oct 6 07:54:17 MET DST 1996 Sun Oct 6 07:55:08 MET DST 1996 -> 52 sec. Of course I did that without running X ;-) the top output comes later ;-) Is such a make depend suited to make statements about first (early) smp performance ?! The system behaves well with a good response time ... But this make depend doesn't show any real "WoW" increase ... Since I do the make depend with -pipe turned on I thought things would have to go faster with 2 cpus ... ?! Any comments ?! BTW, don't get me wrong, I'm very satisfied, that the smp kernel still is so stable !!! And that it's useable ! Really thanks for the work ! Andreas /// load averages: 0.80, 0.48, 0.35 08:32:01 45 processes: 1 running, 43 sleeping, 1 zombie CPU states: 1.7% user, 0.0% nice, 3.0% system, 0.5% interrupt, 94.9% idle Mem: 33M Active, 3220K Inact, 11M Wired, 208K Cache, 2073K Buf, 14M Free Swap: 66M Total, 64K Used, 66M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 1350 reny 2 0 3120K 3216K select1 1:29 3.05% 3.05% XF86_S3 1768 reny 2 0 600K 1896K select1 0:23 1.18% 1.18% xperfmon++ 1800 root 2 0 672K 1088K sbwait1 0:18 0.99% 0.99% cvs 1360 reny 18 0 196K 980K pause 1 0:08 0.04% 0.04% asclock 1367 root 18 0 788K 1220K pause 1 0:00 0.00% 0.00% tcsh 1785 root 18 0 744K 1176K pause 1 0:00 0.00% 0.00% tcsh 1366 reny 18 0 684K 1104K pause 0 0:00 0.00% 0.00% tcsh 1133 reny 18 0 664K 1084K pause 0 0:00 0.00% 0.00% tcsh 1784 reny 18 0 644K 1056K pause 1 0:00 0.00% 0.00% tcsh 106 root 18 0 236K 596K pause 0 0:00 0.00% 0.00% cron 2219 reny 18 0 200K 588K pause 1 0:00 0.00% 0.00% pland 25 root 18 0 200K 72K pause 0 0:00 0.00% 0.00% adjkerntz 1349 reny 10 0 176K 1092K wait 0 0:00 0.00% 0.00% xinit 1352 reny 10 0 476K 204K wait 1 0:00 0.00% 0.00% sh 1 root 10 0 444K 184K wait 1 0:00 0.00% 0.00% init 85 root 10 0 208K 64K nfsidl1 0:00 0.00% 0.00% nfsiod 88 root 10 0 208K 64K nfsidl0 0:00 0.00% 0.00% nfsiod 87 root 10 0 208K 64K nfsidl1 0:00 0.00% 0.00% nfsiod 86 root 10 0 208K 64K nfsidl0 0:00 0.00% 0.00% nfsiod 1381 reny 3 0 176K 560K ttyin 1 0:00 0.00% 0.00% rlogin 156 root 3 0 164K 548K ttyin 0 0:00 0.00% 0.00% getty 1244 root 3 0 164K 548K ttyin 0 0:00 0.00% 0.00% getty 2209 reny 2 0 1768K 2592K select0 0:00 0.00% 0.00% plan 2062 reny 2 0 972K 2188K select0 0:00 0.00% 0.00% knews __ andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Sat Oct 5 23:59:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA19890 for smp-outgoing; Sat, 5 Oct 1996 23:59:22 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA19885 for ; Sat, 5 Oct 1996 23:59:19 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA23481; Sun, 6 Oct 1996 08:45:12 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id IAA12388; Sun, 6 Oct 1996 08:23:54 +0200 (MET DST) Date: Sun, 6 Oct 1996 08:23:54 +0200 (MET DST) From: Andreas Klemm To: Peter Wemm cc: Chris Csanady , freebsd-smp@FreeBSD.ORG Subject: Re: Second processor does nothin?! In-Reply-To: <199610052328.HAA02775@spinner.DIALix.COM> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Oct 1996, Peter Wemm wrote: > Andreas Klemm wrote: > > On Sun, 6 Oct 1996, Peter Wemm wrote: > > > > > Index: files/m_freebsd2.c > > > =================================================================== > > > RCS file: /home/ncvs/ports/sysutils/top/files/m_freebsd2.c,v > > > retrieving revision 1.9 > > > > could you please send me the whole m_freebsd2.c file ?! > > Something went wrong when trying to patch the file from the -current > > ports collection ... hunk #3 failed ... > > I just committed a (slightly tweaked) version to -current if you want to > grab that.. > > Anyway, I've attached it in case.. That's nice. Thanks. Well, it looks really cool ! Andreas /// __ andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<<