From owner-freebsd-sparc64@FreeBSD.ORG Sun Aug 10 05:28:12 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A52A137B401; Sun, 10 Aug 2003 05:28:12 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C593D43F85; Sun, 10 Aug 2003 05:28:11 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h7ACSA4r058760; Sun, 10 Aug 2003 08:28:11 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h7ACSAr3058759; Sun, 10 Aug 2003 08:28:10 -0400 (EDT) Date: Sun, 10 Aug 2003 08:28:10 -0400 (EDT) Message-Id: <200308101228.h7ACSAr3058759@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2003 12:28:13 -0000 TB --- 2003-08-10 11:12:24 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-08-10 11:12:24 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-10 11:14:21 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-08-10 12:10:39 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 10 12:10:39 GMT 2003 >>> Kernel build for GENERIC completed on Sun Aug 10 12:19:33 GMT 2003 TB --- 2003-08-10 12:19:33 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-10 12:19:33 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 10 12:19:33 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/in_cksum.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/intr_machdep.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/iommu.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `sigreturn': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: `tf' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-08-10 12:28:10 - /usr/bin/make returned exit code 1 TB --- 2003-08-10 12:28:10 - ERROR: failed to build lint kernel TB --- 2003-08-10 12:28:10 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sun Aug 10 11:11:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45BA837B405; Sun, 10 Aug 2003 11:11:19 -0700 (PDT) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2697143F85; Sun, 10 Aug 2003 11:11:18 -0700 (PDT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 1001) id 26D0B73; Sun, 10 Aug 2003 14:11:18 -0400 (EDT) Date: Sun, 10 Aug 2003 14:11:18 -0400 From: Adam McDougall To: David O'Brien Message-ID: <20030810181117.GG85229@egr.msu.edu> References: <20030807062536.GA68747@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030807062536.GA68747@dragon.nuxi.com> User-Agent: Mutt/1.5.4i cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2003 18:11:19 -0000 On Wed, Aug 06, 2003 at 11:25:36PM -0700, David O'Brien wrote: Am I the only one that saw 'make world' go from almost 3 hours with GCC 3.2 to: -------------------------------------------------------------- >>> make world completed on Wed Aug 6 20:49:47 PDT 2003 (started Wed Aug 6 09:49:30 PDT 2003) -------------------------------------------------------------- 11h17.00s real 9h29m42.85s user 1h15m22.05s sys post GCC 3.3? This is a 500mhz Blade 100 with a GENERIC minus WITNESS* kernel. -- -- David (obrien@FreeBSD.org) I have been rebuilding my dual cpu Ultra 60 occasionally, including several times after the gcc upgrade, and have not noticed a large slowdown. Here are some datapoints, maybe it will help discover where the problem lies if someone can try at least a similar build configuration. Notables in config and build are NOPROFILE=yes, no DEBUG=-g, no INVARIENTS*, no WITNESS*, SCHED_4BSD (sometimes I use ULE, but not in the past month), SMP, /etc/malloc.conf -> aj, make -j2 MAKE="make -j2" buildworld. I always cvsup before building if it is a new day. I can return more information or tests if anyone wants. Infact, I occasionally compile the samba port as a dirty benchmark, and the compile time dropped from ~9.5 minutes to 8 minutes between may and july 18. bw1.log:Script started on Sun Jun 8 17:16:52 2003 bw1.log:Script done on Sun Jun 8 19:36:52 2003 bw2.log:Script started on Wed Jun 11 22:51:51 2003 bw2.log:Script done on Thu Jun 12 00:54:38 2003 bw3.log:Script started on Fri Jun 13 18:26:45 2003 bw3.log:Script done on Fri Jun 13 20:18:21 2003 bw4.log:Script started on Tue Jun 17 18:45:08 2003 bw4.log:Script done on Tue Jun 17 20:34:12 2003 bw5.log:Script started on Wed Jun 18 17:44:28 2003 bw5.log:Script done on Wed Jun 18 19:33:28 2003 bw6.log:Script started on Tue Jun 24 18:28:54 2003 bw6.log:Script done on Tue Jun 24 20:17:47 2003 bw7.log:Script started on Tue Jul 1 18:25:01 2003 bw7.log:Script done on Tue Jul 1 20:57:22 2003 bw8.log:Script started on Wed Jul 2 19:59:14 2003 bw8.log:Script done on Wed Jul 2 22:46:29 2003 bw9.log:Script started on Fri Jul 4 10:15:08 2003 bw9.log:Script done on Fri Jul 4 13:04:01 2003 bw10.log:Script started on Wed Jul 16 19:24:34 2003 bw10.log:Script done on Wed Jul 16 21:02:10 2003 bw11.log:Script started on Thu Jul 17 17:23:07 2003 bw11.log:Script done on Thu Jul 17 19:00:30 2003 bw12.log:Script started on Thu Jul 17 19:35:37 2003 bw12.log:Script done on Thu Jul 17 21:13:46 2003 bw13.log:Script started on Thu Jul 17 23:53:55 2003 bw13.log:Script done on Fri Jul 18 03:10:21 2003 bw14.log:Script started on Sun Jul 27 12:03:38 2003 bw14.log:Script done on Sun Jul 27 14:03:42 2003 bw15.log:Script started on Sun Aug 10 10:53:46 2003 bw15.log:Script done on Sun Aug 10 12:53:04 2003 build options from make.conf: CFLAGS=-pipe -O WITH_LIBMAP=YES NOPROFILE=yes Non-commented kernel config options: machine sparc64 cpu SUN4U ident U60 maxusers 0 options OFW_NEWPCI options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Keep this for a while options SCSI_DELAY=3000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options SMP # Symmetric MultiProcessor Kernel device apb # Sun APB PCI-PCI bridge device ebus device isa device pci device sbus device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device ahc # AHA2940 and onboard AIC7xxx devices device isp # Qlogic family device ispfw # Firmware module for Qlogic host adapters device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device ofw_console # OpenBoot firmware console device device genclock # Generic clock interface device eeprom # eeprom (really an ebus driver for the MK48Txx) device "mk48txx" # Mostek MK48T02, MK48T08, MK48T59 clock device sab # Siemens SAB82532 based serial ports device miibus # MII bus support device gem # Sun GEM/Sun ERI/Apple GMAC device hme # Sun HME (Happy Meal Ethernet) device rl # RealTek 8129/8139 device random # Entropy device device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device bpf #Berkeley packet filter options OFW_PCI_DEBUG Hardware: real memory = 805306368 (768 MB) cpu0: Sun Microsystems UltraSparc-II Processor (360.03 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (360.03 MHz CPU) da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C) From owner-freebsd-sparc64@FreeBSD.ORG Sun Aug 10 21:15:34 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C517B37B409; Sun, 10 Aug 2003 21:15:21 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5188D4451A; Sun, 10 Aug 2003 17:23:47 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h7B0Nk4r065940; Sun, 10 Aug 2003 20:23:46 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h7B0NkiF065939; Sun, 10 Aug 2003 20:23:46 -0400 (EDT) Date: Sun, 10 Aug 2003 20:23:46 -0400 (EDT) Message-Id: <200308110023.h7B0NkiF065939@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2003 04:15:36 -0000 TB --- 2003-08-10 23:07:20 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-08-10 23:07:20 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-10 23:10:05 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-08-11 00:06:18 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 11 00:06:18 GMT 2003 >>> Kernel build for GENERIC completed on Mon Aug 11 00:15:11 GMT 2003 TB --- 2003-08-11 00:15:11 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-11 00:15:11 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 11 00:15:11 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/in_cksum.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/intr_machdep.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/iommu.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c: In function `sigreturn': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: `tf' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sparc64/machdep.c:550: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-08-11 00:23:46 - /usr/bin/make returned exit code 1 TB --- 2003-08-11 00:23:46 - ERROR: failed to build lint kernel TB --- 2003-08-11 00:23:46 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 11 08:51:05 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31FEA37B401; Mon, 11 Aug 2003 08:51:05 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E7C443F93; Mon, 11 Aug 2003 08:51:04 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h7BFp2Cx027913; Mon, 11 Aug 2003 11:51:02 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030809084019.GA4704@rot13.obsecurity.org> References: <20030807062536.GA68747@dragon.nuxi.com> <20030809084019.GA4704@rot13.obsecurity.org> Date: Mon, 11 Aug 2003 11:51:00 -0400 To: Kris Kennaway From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2003 15:51:05 -0000 At 1:40 AM -0700 8/9/03, Kris Kennaway wrote: >On Sat, Aug 09, 2003, Garance A Drosihn wrote: > >> So, apparently the problem is something a bit more subtle than >> just gcc 3.3 being slower to compile than gcc 3.2. Apparently >> the August 9th system is a lot slower at *running* than the >> early system. Do we have some other benchmarks we could run? > >This suggests that something might have been pessimized with >the gcc 3.3 code generation on sparc. Well, I'm thinking that maybe we're blaming the wrong thing for this slowdown. I have the results for a few more builds: realtime user sys ---------- ------------- ------------ build 1: 347m 33.407s 283m 0.162s 53m 45.805s build 2: 387m 4.205s 315m 25.441s 59m 44.648s build 3: 1238m 11.386s 1064m 31.148s 136m 54.366s build 4: 384m 30.479s 312m 54.407s 59m 7.338s build 1 is the cvsup'ed from July 6th, being built on top of a world from June 6th. build 2 is the cvsup'ed source from August 7th, built on top of the world from June 6th (apparently I never installed the buildworld from July 6th). build 3 is the exact same source as build #2, built on the world that was installed by build 2. build 4 is where I took the kernel from build #1 (which was sitting in /boot/kernel.old), and booted off of that. So, the system is running the kernel from June 6th, but the entire userland is from August 7th. This means it starts out with gcc (GCC) 3.3.1 [FreeBSD] 20030711 (prerelease). So, the slowdown is completely in the kernel. Either there was some change made to the kernel-sources which has caused the slowdown, or there is something about gcc 3.3.1's code generation such that we end up with a horrendously slower kernel. But it isn't gcc 3.3.1 *itself* which is that much slower at compiling. I don't know where the slowdown is occurring. Obviously it is something which clobbers a buildworld, so maybe disk access or something like that (I have enough real memory that my system never pages). That's why I was wondering if there were some other benchmarks we could run. The only thing that I really do with my freebsd/sparc machine is buildworld's of freebsd/sparc, so there is nothing else where I would notice a major slowdown (even if it were occurring). On build #3 I noticed that 'top' constantly reported the CPU was 0.0% idle. Unfortunately I couldn't check that for build #4, because I didn't have a 'top' which matched the running kernel... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 11 08:58:20 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FB5237B401 for ; Mon, 11 Aug 2003 08:58:20 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4E7A43F75 for ; Mon, 11 Aug 2003 08:58:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h7BFwIkM026200 for ; Mon, 11 Aug 2003 11:58:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20030807062536.GA68747@dragon.nuxi.com> <20030809084019.GA4704@rot13.obsecurity.org> Date: Mon, 11 Aug 2003 11:58:17 -0400 To: sparc64@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2003 15:58:20 -0000 At 11:51 AM -0400 8/11/03, Garance A Drosihn wrote: > > realtime user sys > ---------- ------------- ------------ > build 1: 347m 33.407s 283m 0.162s 53m 45.805s > build 2: 387m 4.205s 315m 25.441s 59m 44.648s > build 3: 1238m 11.386s 1064m 31.148s 136m 54.366s > build 4: 384m 30.479s 312m 54.407s 59m 7.338s > >build 1 is the cvsup'ed from July 6th, being built on > top of a world from June 6th. >build 2 is the cvsup'ed source from August 7th, built > on top of the world from June 6th (apparently I > never installed the buildworld from July 6th). >build 3 is the exact same source as build #2, built on > the world that was installed by build 2. >build 4 is where I took the kernel from build #1 (which > was sitting in /boot/kernel.old), and booted off > of that. So, the system is running the kernel > from June 6th, but the entire userland is from > August 7th. This means it starts out with > gcc (GCC) 3.3.1 [FreeBSD] 20030711 (prerelease). Oh, and build #4 is using the exact same /usr/src tree as builds #2 and #3. And for all three, I started out by removing all the /usr/obj/usr/src/* directories. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 11 11:01:30 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79AFE37B401 for ; Mon, 11 Aug 2003 11:01:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B82CE43F85 for ; Mon, 11 Aug 2003 11:01:19 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7BI1IUp080846 for ; Mon, 11 Aug 2003 11:01:18 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7BI1IpD080840 for freebsd-sparc64@freebsd.org; Mon, 11 Aug 2003 11:01:18 -0700 (PDT) Date: Mon, 11 Aug 2003 11:01:18 -0700 (PDT) Message-Id: <200308111801.h7BI1IpD080840@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2003 18:01:32 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/24] sparc64/53670sparc64 pthreads implementation on 5.1-Release sp 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/02/03] sparc64/47845sparc64 4 second daily clock drift 1 problem total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Aug 12 20:33:58 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C3F37B404 for ; Tue, 12 Aug 2003 20:33:58 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832F443F85 for ; Tue, 12 Aug 2003 20:33:56 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id AD1E444 for ; Tue, 12 Aug 2003 21:33:55 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7D3XtX05750 for sparc64@freebsd.org; Tue, 12 Aug 2003 21:33:55 -0600 Date: Tue, 12 Aug 2003 21:33:55 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030812213355.M22214@seekingfire.com> References: <20030807062536.GA68747@dragon.nuxi.com> <20030809084019.GA4704@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from drosih@rpi.edu on Mon, Aug 11, 2003 at 11:51:00AM -0400 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 03:33:58 -0000 On Mon, Aug 11, 2003 at 11:51:00AM -0400, Garance A Drosihn wrote: > At 1:40 AM -0700 8/9/03, Kris Kennaway wrote: > >On Sat, Aug 09, 2003, Garance A Drosihn wrote: > > > >> So, apparently the problem is something a bit more subtle than > >> just gcc 3.3 being slower to compile than gcc 3.2. Apparently > >> the August 9th system is a lot slower at *running* than the > >> early system. Do we have some other benchmarks we could run? > > > >This suggests that something might have been pessimized with > >the gcc 3.3 code generation on sparc. > > Well, I'm thinking that maybe we're blaming the wrong thing > for this slowdown. I have the results for a few more builds: > > realtime user sys > ---------- ------------- ------------ > build 1: 347m 33.407s 283m 0.162s 53m 45.805s > build 2: 387m 4.205s 315m 25.441s 59m 44.648s > build 3: 1238m 11.386s 1064m 31.148s 136m 54.366s > build 4: 384m 30.479s 312m 54.407s 59m 7.338s > I don't know where the slowdown is occurring. Obviously it is > something which clobbers a buildworld, so maybe disk access or > something like that (I have enough real memory that my system > never pages). That's why I was wondering if there were some > other benchmarks we could run. The only thing that I really do > with my freebsd/sparc machine is buildworld's of freebsd/sparc, > so there is nothing else where I would notice a major slowdown > (even if it were occurring). Disk access could indeed be a problem. Here's the build times and bonnie++ results on the original EIDE drive in my Ultra 5: time make buildworld: real 1485m0.214s user 915m40.322s sys 98m56.775s time make buildkernel: real 487m44.136s user 400m55.723s sys 24m34.634s bonnie++: # bonnie++ -d /usr/scratch/ -m caliban -u 0 Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP caliban 300M 8 92 1999 10 924 5 15 92 1887 6 72.4 21 Latency 2260ms 519ms 2964ms 1117ms 161ms 3688ms Version 1.93c ------Sequential Create------ --------Random Create-------- caliban -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 856 68 2968 89 2478 94 811 60 2817 84 2770 94 Latency 1589ms 250ms 3365us 1674ms 477ms 10394us 1.93c,1.93c,caliban,1,1060744776,300M,,8,92,1999,10,924,5,15,92,1887,6,72.4,21,16,,,,,856,68,2968,89,2478,94,811,60,2817,84,2770,94,2260ms,519ms,2964ms,1117ms,161ms,3688ms,1589ms,250ms,3365us,1674ms,477ms,10394us That's a slow disk. I have a 25Mhz decstation that outperforms the Ultra 5 on disk I/O. Unfortunately, I don't have drive timings from when the buildworlds where faster to compare, so this could be a red herring :-( Drive details: # dmesg | grep ad0 ad0: 8223MB [16708/16/63] at ata2-master WDMA2 > On build #3 I noticed that 'top' constantly reported the CPU > was 0.0% idle. Unfortunately I couldn't check that for build #4, > because I didn't have a 'top' which matched the running kernel... I also have the the 0% idle top during buildworld, even though I'm not using -jX. It seems odd to me - with disk I/O that slow, I would think that the CPU should be partially/occasionally idle during a buildworld. -T -- 1. Get enough food to eat, and eat it. 2. Find a place to sleep where it is quiet, and sleep there. 3. Reduce intellectual and emotional noise until you arrive at the silence of yourself, and listen to it. 4. - Richard Brautigan From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 03:49:08 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FA6337B4DF for ; Wed, 13 Aug 2003 03:49:07 -0700 (PDT) Received: from tts.orel.ru (tts.orel.ru [213.59.64.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6465143FCB for ; Wed, 13 Aug 2003 03:49:04 -0700 (PDT) (envelope-from bel@orel.ru) Received: from orel.ru (lg.orel.ru [195.90.189.89]) by tts.orel.ru (8.12.6/8.12.6/bel) with ESMTP id h7DAmwt7003719 for ; Wed, 13 Aug 2003 14:48:59 +0400 Message-ID: <3F3A179C.3020104@orel.ru> Date: Wed, 13 Aug 2003 14:49:00 +0400 From: Andrew Belashov Organization: ORIS User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030411 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Kernel panic in cpu_ipi_send() X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 10:49:08 -0000 Hello, All! Any ideas about this panic: panic: ipi_send: couldn't send ipi cpuid = 1; Debugger("panic") Stopped at Debugger+0x1c: ta %xcc, 1 db> trace panic() at panic+0x134 cpu_ipi_send() at cpu_ipi_send+0xb0 cpu_ipi_selected() at cpu_ipi_selected+0x38 tlb_page_demap() at tlb_page_demap+0x74 pmap_zero_page_idle() at pmap_zero_page_idle+0xe4 vm_page_zero_idle() at vm_page_zero_idle+0x74 vm_pagezero() at vm_pagezero+0xb4 fork_exit() at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 Hardware: Sun Ultra 60 (2xUltraSparc-II, 450 MHz, 1 Gb) uname: FreeBSD trash 5.1-RELEASE FreeBSD 5.1-RELEASE #1: Thu Aug 7 13:49:03 MSD 2003 bel at trash:/usr/obj/usr/src/sys/WHITE sparc64 System is 5.1-RELEASE/sparc64 with one patch: --------------------------------------------------------------------- Index: sys/sparc64/sparc64/pmap.c =================================================================== RCS file: /vol/ncvs/src/sys/sparc64/sparc64/pmap.c,v retrieving revision 1.118 diff -u -r1.118 pmap.c --- sys/sparc64/sparc64/pmap.c 6 Jul 2003 20:32:42 -0000 1.118 +++ sys/sparc64/sparc64/pmap.c 30 Jul 2003 16:08:09 -0000 @@ -1161,7 +1161,7 @@ if ((data & TD_W) != 0 && pmap_track_modified(pm, va)) vm_page_dirty(m); } - return (0); + return (1); } /* --------------------------------------------------------------------- dmesg: --------------------------------------------------------------------- Costray vector interrupt 2029 pyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #1: Thu Aug 7 13:49:03 MSD 2003 bel at trash:/usr/obj/usr/src/sys/WHITE Preloaded elf kernel "/boot/kernel/kernel" at 0xc0334000. Timecounter "tick" frequency 450034203 Hz real memory = 1051934720 (1003 MB) avail memory = 1023279104 (975 MB) cpu0: Sun Microsystems UltraSparc-II Processor (450.03 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (450.03 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs nexus0: pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 0x7c0, bus B initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfc000000 to 0xffffffff pci0: on pcib0 ebus0: revision 0x01 ebus0: mem 0x71000000-0x717fffff,0x70000000-0x70ffffff at device 1.0 on pci0 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) sab0: addr 0x1400400000-0x140040007f irq 43 on ebus0 sabtty0: on sab0 sabtty0: console 9600,8,n,1,- sabtty1: on sab0 ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x1400300398-0x1400300399,0x14003043bc-0x14003043cb irq 34 (no driver attached) ebus0: addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003023f0-0x14003023f7 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 83011487 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400722000-0x1400722003,0x1400704000-0x140070400f,0x1400702000-0x140070200f,0x1400200000-0x14002000ff irq 36,35 (no driver attached) hme0: mem 0x100000-0x107fff irq 33 at device 1.1 on pci0 hme0: Ethernet address: 00:03:ba:01:14:87 miibus0: on hme0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: port 0x1800-0x18ff mem 0x110000-0x1100ff irq 16 at device 2.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:80:48:1c:b6:c1 miibus1: on rl0 rlphy0: on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <875> port 0x1000-0x10ff mem 0x10a000-0x10afff,0x108000-0x1080ff irq 32 at device 3.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x1400-0x14ff mem 0x10e000-0x10efff,0x10c000-0x10c0ff irq 38 at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pcib1: on nexus0 pcib1: Psycho, impl 0, version 4, ign 0x7c0, bus A pci1: on pcib1 nexus0: , type display (no driver attached) Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging unlimited DUMMYNET initialized (011031) Waiting 15 seconds for SCSI devices to settle da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) SMP: AP CPU #1 Launched! da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/da0a --------------------------------------------------------------------- Kernel config (WHITE): --------------------------------------------------------------------- machine sparc64 cpu SUN4U ident WHITE makeoptions DEBUG=-g options SCHED_4BSD options INET #options INET6 options FFS options SOFTUPDATES options UFS_ACL options UFS_DIRHASH options MD_ROOT options NFSCLIENT options NFSSERVER options NFS_ROOT #options MSDOSFS options CD9660 options PROCFS options PSEUDOFS options COMPAT_43 options COMPAT_FREEBSD4 options SCSI_DELAY=15000SCSI options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM #options _KPOSIX_PRIORITY_SCHEDULING options DDB #options INVARIANTS options INVARIANT_SUPPORT #options WITNESS #options WITNESS_SKIPSPIN # To make an SMP kernel, the next line is needed options SMP # Standard busses device apb device ebus device isa device pci device sbus device central device fhc # ATA and ATAPI devices device ata device atadisk device atapicd #device atapifd #device atapist # SCSI Controllers device sym # SCSI peripherals device scbus device ch device da device sa device cd device pass device ses device ofw_console # Builtin hardware device genclock device eeprom device "mk48txx" # Serial (COM) ports #device sio device sab device zs # PCI Ethernet NICs that use the common MII bus controller code. device miibus device hme # Sun HME (Happy Meal Ethernet) device rl # RealTek 8129/8139 # Pseudo devices - the number indicates how many units to allocated. device random device loop device ether #device sl #device ppp #device tun device pty device md device gif device faith device bpf # FireWire support device firewire device sbp device fwe options IPFIREWALL options IPFIREWALL_VERBOSE #options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options IPSTEALTH options QUOTA options PANIC_REBOOT_WAIT_TIME=60 options ALT_BREAK_TO_DEBUGGER --------------------------------------------------------------------- Thanks! From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 08:23:59 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D3A037B401 for ; Wed, 13 Aug 2003 08:23:59 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB7B943FAF for ; Wed, 13 Aug 2003 08:23:57 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7DFNuv11771 for ; Wed, 13 Aug 2003 17:23:56 +0200 (MEST) Date: Wed, 13 Aug 2003 17:23:56 +0200 (CEST) From: Harti Brandt In-Reply-To: <20030812213355.M22214@seekingfire.com> Message-ID: <20030813171438.I97608@beagle.fokus.fraunhofer.de> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 15:23:59 -0000 T>On Mon, Aug 11, 2003 at 11:51:00AM -0400, Garance A Drosihn wrote: T>> At 1:40 AM -0700 8/9/03, Kris Kennaway wrote: T>> >On Sat, Aug 09, 2003, Garance A Drosihn wrote: T>> > T>> >> So, apparently the problem is something a bit more subtle than T>> >> just gcc 3.3 being slower to compile than gcc 3.2. Apparently T>> >> the August 9th system is a lot slower at *running* than the T>> >> early system. Do we have some other benchmarks we could run? T>> > T>> >This suggests that something might have been pessimized with T>> >the gcc 3.3 code generation on sparc. The problem seems to be in the kernel, not the compiler. I have rebuilt a gcc 3.2.2. The actual kernel (from yesterday) is slightly faster when built with 3.3.1 as opposed to 3.2.2 (in the order of 3-4%), but VERY slow. A kernel from June 1st built with 3.2.2 has its 'normal' speed. I'm trying now I binary search to find the victim. One difference between the kernels is, that a /usr/bin/time -l make something reports twice as much involuntary context switches with the new kernel. I don't know, however, exactly what this means. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 08:48:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 772C237B401; Wed, 13 Aug 2003 08:48:28 -0700 (PDT) Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A85BB43FBF; Wed, 13 Aug 2003 08:48:26 -0700 (PDT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost [127.0.0.1]) by energistic.com (8.12.9/8.12.9) with ESMTP id h7DFmNCF051653; Wed, 13 Aug 2003 10:48:24 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.12.9/8.12.9/Submit) id h7DFmNOU049869; Wed, 13 Aug 2003 10:48:23 -0500 (EST) (envelope-from steve) Date: Wed, 13 Aug 2003 10:48:23 -0500 From: Steve Ames To: harti@freebsd.org Message-ID: <20030813154823.GA99828@energistic.com> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813171438.I97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813171438.I97608@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 15:48:28 -0000 On Wed, Aug 13, 2003 at 05:23:56PM +0200, Harti Brandt wrote: > The problem seems to be in the kernel, not the compiler. I have rebuilt a > gcc 3.2.2. The actual kernel (from yesterday) is slightly faster when > built with 3.3.1 as opposed to 3.2.2 (in the order of 3-4%), but VERY > slow. A kernel from June 1st built with 3.2.2 has its 'normal' speed. I'm > trying now I binary search to find the victim. This may be a red herring... My first post gcc 3.3 kernel took 12 hours to build on my U5. This was a GENERIC kernel since I hadn't recompiled since January (long story). The following two kernels also took 12 hours. Then I cleaned up the kernel config and its back down to around 4.5 hours... It could be a kernel debugging option maybe? Could be that a bit of hit/miss experimenting could find it. Here's my current config (4.5 hour 'make world'). -Steve /sys/sparc64/conf/SPARC ----------------------------------------- machine sparc64 cpu SUN4U ident GENERIC options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Keep this for a while options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores device apb # Sun APB PCI-PCI bridge device ebus device isa device pci device sbus device central device fhc options OFW_NEWPCI device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device ofw_console # OpenBoot firmware console device device genclock # Generic clock interface device eeprom # eeprom (really an ebus driver for the MK48Txx) device "mk48txx" # Mostek MK48T02, MK48T08, MK48T59 clock device miibus # MII bus support device hme # Sun HME (Happy Meal Ethernet) device random # Entropy device device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying/(translation) From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 08:52:00 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DEDA37B401 for ; Wed, 13 Aug 2003 08:52:00 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA0243F93 for ; Wed, 13 Aug 2003 08:51:58 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7DFpnv14976; Wed, 13 Aug 2003 17:51:49 +0200 (MEST) Date: Wed, 13 Aug 2003 17:51:49 +0200 (CEST) From: Harti Brandt To: Steve Ames In-Reply-To: <20030813154823.GA99828@energistic.com> Message-ID: <20030813175022.X97608@beagle.fokus.fraunhofer.de> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 15:52:00 -0000 On Wed, 13 Aug 2003, Steve Ames wrote: SA>On Wed, Aug 13, 2003 at 05:23:56PM +0200, Harti Brandt wrote: SA>> The problem seems to be in the kernel, not the compiler. I have rebuilt a SA>> gcc 3.2.2. The actual kernel (from yesterday) is slightly faster when SA>> built with 3.3.1 as opposed to 3.2.2 (in the order of 3-4%), but VERY SA>> slow. A kernel from June 1st built with 3.2.2 has its 'normal' speed. I'm SA>> trying now I binary search to find the victim. SA> SA>This may be a red herring... SA> SA>My first post gcc 3.3 kernel took 12 hours to build on my U5. This was a SA>GENERIC kernel since I hadn't recompiled since January (long story). The SA>following two kernels also took 12 hours. Then I cleaned up the kernel SA>config and its back down to around 4.5 hours... It could be a kernel SA>debugging option maybe? Could be that a bit of hit/miss experimenting SA>could find it. Here's my current config (4.5 hour 'make world'). The problem is, that compiling just anything takes 3 time longer on an actual kernel, than on one from June 1st. Same world, same kernel config, same compiler (3.2.2). harti SA> SA>-Steve SA> SA>/sys/sparc64/conf/SPARC SA>----------------------------------------- SA>machine sparc64 SA>cpu SUN4U SA>ident GENERIC SA> SA>options SCHED_4BSD #4BSD scheduler SA>options INET #InterNETworking SA>options INET6 #IPv6 communications protocols SA>options FFS #Berkeley Fast Filesystem SA>options SOFTUPDATES #Enable FFS soft updates support SA>options UFS_ACL #Support for access control lists SA>options UFS_DIRHASH #Improve performance on big directories SA>options NFSCLIENT #Network Filesystem Client SA>options CD9660 #ISO 9660 Filesystem SA>options PROCFS #Process filesystem (requires PSEUDOFS) SA>options PSEUDOFS #Pseudo-filesystem framework SA>options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] SA>options COMPAT_FREEBSD4 #Keep this for a while SA>options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI SA>options SYSVSHM #SYSV-style shared memory SA>options SYSVMSG #SYSV-style message queues SA>options SYSVSEM #SYSV-style semaphores SA> SA>device apb # Sun APB PCI-PCI bridge SA>device ebus SA>device isa SA>device pci SA>device sbus SA>device central SA>device fhc SA> SA>options OFW_NEWPCI SA> SA>device ata SA>device atadisk # ATA disk drives SA>device atapicd # ATAPI CDROM drives SA> SA>device ofw_console # OpenBoot firmware console device SA> SA>device genclock # Generic clock interface SA>device eeprom # eeprom (really an ebus driver for the MK48Txx) SA>device "mk48txx" # Mostek MK48T02, MK48T08, MK48T59 clock SA> SA> SA> SA>device miibus # MII bus support SA>device hme # Sun HME (Happy Meal Ethernet) SA> SA>device random # Entropy device SA>device loop # Network loopback SA>device ether # Ethernet support SA>device pty # Pseudo-ttys (telnet etc) SA>device gif # IPv6 and IPv4 tunneling SA>device faith # IPv6-to-IPv4 relaying/(translation) SA> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 08:55:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 416B837B401; Wed, 13 Aug 2003 08:55:28 -0700 (PDT) Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1EFE43F93; Wed, 13 Aug 2003 08:55:26 -0700 (PDT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost [127.0.0.1]) by energistic.com (8.12.9/8.12.9) with ESMTP id h7DFtOCF002782; Wed, 13 Aug 2003 10:55:25 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.12.9/8.12.9/Submit) id h7DFtN1x099764; Wed, 13 Aug 2003 10:55:23 -0500 (EST) (envelope-from steve) Date: Wed, 13 Aug 2003 10:55:23 -0500 From: Steve Ames To: harti@freebsd.org Message-ID: <20030813155523.GB99828@energistic.com> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813171438.I97608@beagle.fokus.fraunhofer.de> <20030813154823.GA99828@energistic.com> <20030813175022.X97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813175022.X97608@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.4i cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 15:55:28 -0000 On Wed, Aug 13, 2003 at 05:51:49PM +0200, Harti Brandt wrote: > The problem is, that compiling just anything takes 3 time longer on an > actual kernel, than on one from June 1st. Same world, same kernel config, > same compiler (3.2.2). Not arguing that. I'm suggesting that perhaps one of the kernel debug options is pessimizing compiles across the board. It took me 12 hours to do a 'make world' when I had debugging options enabled in my kernel. I took them out and now I can 'make world' in 4.5 hours. I would expect that ratio to hold for all compiles and not just 'make world'. so.. running with a kernel with debug options causes my compiles to be almost 3 times as long. That's all I'm saying. What does your kernel config look like? Do you have all of the debug stuff turned on? -Steve From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 08:59:59 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A8637B401 for ; Wed, 13 Aug 2003 08:59:59 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7281043F85 for ; Wed, 13 Aug 2003 08:59:58 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7DFxtv16067; Wed, 13 Aug 2003 17:59:55 +0200 (MEST) Date: Wed, 13 Aug 2003 17:59:55 +0200 (CEST) From: Harti Brandt To: Steve Ames In-Reply-To: <20030813155523.GB99828@energistic.com> Message-ID: <20030813175634.P97608@beagle.fokus.fraunhofer.de> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> <20030813155523.GB99828@energistic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 16:00:00 -0000 On Wed, 13 Aug 2003, Steve Ames wrote: SA>On Wed, Aug 13, 2003 at 05:51:49PM +0200, Harti Brandt wrote: SA>> The problem is, that compiling just anything takes 3 time longer on an SA>> actual kernel, than on one from June 1st. Same world, same kernel config, SA>> same compiler (3.2.2). SA> SA>Not arguing that. I'm suggesting that perhaps one of the kernel debug SA>options is pessimizing compiles across the board. It took me 12 hours SA>to do a 'make world' when I had debugging options enabled in my kernel. SA>I took them out and now I can 'make world' in 4.5 hours. I would expect SA>that ratio to hold for all compiles and not just 'make world'. SA> SA>so.. running with a kernel with debug options causes my compiles to SA>be almost 3 times as long. That's all I'm saying. What does your SA>kernel config look like? Do you have all of the debug stuff turned SA>on? I have actually two machines and two kernels: one machine runs with WITNESS and DIAGNOSTICS and the other without that. On both machines the current kernel is three times slower than the old kernel. Of course the debugging kernels are even slower than the non-debugging ones. But, the three times ratio between old and new kernels is the same on both machines. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 09:07:23 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1685837B401; Wed, 13 Aug 2003 09:07:23 -0700 (PDT) Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E70BB43F85; Wed, 13 Aug 2003 09:07:20 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: from inlafsteve (bdsl.66.12.217.43.gte.net [66.12.217.43]) (authenticated bits=0) by energistic.com (8.12.9/8.12.9) with ESMTP id h7DG7ECF083733; Wed, 13 Aug 2003 11:07:17 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <001501c361b4$f84e6280$2bd90c42@officescape.net> From: "Steve Ames" To: , "Steve Ames" References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813171438.I97608@beagle.fokus.fraunhofer.de> <20030813154823.GA99828@energistic.com> <20030813175022.X97608@beagle.fokus.fraunhofer.de> <20030813155523.GB99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> Date: Wed, 13 Aug 2003 11:07:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 16:07:23 -0000 ----- Original Message ----- From: "Harti Brandt" > I have actually two machines and two kernels: one machine runs with > WITNESS and DIAGNOSTICS and the other without that. On both machines > the current kernel is three times slower than the old kernel. Of course > the debugging kernels are even slower than the non-debugging ones. But, > the three times ratio between old and new kernels is the same on both > machines. Ah. Well that blows my theory :) However... in January my system took around 4 hours to do 'make world' and it still does with today's code (if I don't have debug options turned on). So I'm not sure there is a global 3x increase. -Steve From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 09:12:23 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DA637B401 for ; Wed, 13 Aug 2003 09:12:23 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2980D43FA3 for ; Wed, 13 Aug 2003 09:12:22 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7DGC9v17573; Wed, 13 Aug 2003 18:12:10 +0200 (MEST) Date: Wed, 13 Aug 2003 18:12:09 +0200 (CEST) From: Harti Brandt To: Steve Ames In-Reply-To: <001501c361b4$f84e6280$2bd90c42@officescape.net> Message-ID: <20030813180823.W97608@beagle.fokus.fraunhofer.de> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> <20030813155523.GB99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> <001501c361b4$f84e6280$2bd90c42@officescape.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 16:12:23 -0000 On Wed, 13 Aug 2003, Steve Ames wrote: SA> SA>----- Original Message ----- SA>From: "Harti Brandt" SA>> I have actually two machines and two kernels: one machine runs with SA>> WITNESS and DIAGNOSTICS and the other without that. On both machines SA>> the current kernel is three times slower than the old kernel. Of course SA>> the debugging kernels are even slower than the non-debugging ones. But, SA>> the three times ratio between old and new kernels is the same on both SA>> machines. SA> SA>Ah. Well that blows my theory :) However... in January my system took around SA>4 hours to do 'make world' and it still does with today's code (if I don't SA>have SA>debug options turned on). So I'm not sure there is a global 3x increase. Well, you're the 2nd one who reports that nothing has changed. Several people however report, that they see the 3x increase. And I see it myself, no matter how often I look at this. Today I tried to build the vinum module: gcc-3.3.1 yesterday's kernel 132 + 85 + 20 gcc-3.2.2 yesterday's kernel 131 + 85 + 22 gcc-3.2.2 kernel from June 1st 52 + 27 + 7 Exactly the same config and the same world (except for gcc). This is an Ultra10. Perhaps it depends on the sparc model? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 09:38:30 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CF1837B401 for ; Wed, 13 Aug 2003 09:38:30 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B429443F75 for ; Wed, 13 Aug 2003 09:38:28 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 31959 invoked by uid 65534); 13 Aug 2003 16:38:27 -0000 Received: from p508E7660.dip.t-dialin.net (EHLO galatea.local) (80.142.118.96) by mail.gmx.net (mp022) with SMTP; 13 Aug 2003 18:38:27 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19mydt-000HBd-8D; Wed, 13 Aug 2003 18:38:33 +0200 Date: Wed, 13 Aug 2003 18:38:32 +0200 From: Thomas Moestl To: harti@freebsd.org Message-ID: <20030813163832.GA779@crow.dom2ip.de> Mail-Followup-To: harti@freebsd.org, Steve Ames , sparc64@freebsd.org References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> <20030813155523.GB99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> <001501c361b4$f84e6280$2bd90c42@officescape.net> <20030813180823.W97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030813180823.W97608@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: Steve Ames cc: sparc64@freebsd.org Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 16:38:30 -0000 On Wed, 2003/08/13 at 18:12:09 +0200, Harti Brandt wrote: > On Wed, 13 Aug 2003, Steve Ames wrote: > > SA> > SA>----- Original Message ----- > SA>From: "Harti Brandt" > SA>> I have actually two machines and two kernels: one machine runs with > SA>> WITNESS and DIAGNOSTICS and the other without that. On both machines > SA>> the current kernel is three times slower than the old kernel. Of course > SA>> the debugging kernels are even slower than the non-debugging ones. But, > SA>> the three times ratio between old and new kernels is the same on both > SA>> machines. > SA> > SA>Ah. Well that blows my theory :) However... in January my system took around > SA>4 hours to do 'make world' and it still does with today's code (if I don't > SA>have > SA>debug options turned on). So I'm not sure there is a global 3x increase. > > Well, you're the 2nd one who reports that nothing has changed. Several > people however report, that they see the 3x increase. And I see it myself, > no matter how often I look at this. Today I tried to build the vinum > module: > > gcc-3.3.1 yesterday's kernel 132 + 85 + 20 > gcc-3.2.2 yesterday's kernel 131 + 85 + 22 > gcc-3.2.2 kernel from June 1st 52 + 27 + 7 > > Exactly the same config and the same world (except for gcc). > > This is an Ultra10. Perhaps it depends on the sparc model? FWIW, I'm not seeing this either on my Blade 100; with kernels from Jun 1 and Aug 11, both built with gcc 3.3.1, a complete kernel build takes the same time down to a few seconds. I'm running world builds right now. It would be very interesting if you could narrow the change down to a shorter time span by binary search. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 11:46:25 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4C037B404 for ; Wed, 13 Aug 2003 11:46:25 -0700 (PDT) Received: from 12-222-90-48.client.insightbb.com (12-222-90-48.client.insightBB.com [12.222.90.48]) by mx1.FreeBSD.org (Postfix) with SMTP id 9659043FDF for ; Wed, 13 Aug 2003 11:46:23 -0700 (PDT) (envelope-from chris@manual-override.net) Received: (qmail 7784 invoked from network); 13 Aug 2003 18:42:27 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost with SMTP; 13 Aug 2003 18:42:27 -0000 Date: Wed, 13 Aug 2003 13:42:23 -0500 (EST) From: Chris Orr X-X-Sender: chris@compaq-sucks.net To: sparc64@freebsd.org In-Reply-To: <20030813163832.GA779@crow.dom2ip.de> Message-ID: <20030813133649.P85246@compaq-sucks.net> References: <20030807062536.GA68747@dragon.nuxi.com> <20030813154823.GA99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> <20030813180823.W97608@beagle.fokus.fraunhofer.de> <20030813163832.GA779@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 18:46:25 -0000 Hey all, Im noticing the same thing on my Netra t1. I built world and kernel. The first time I built it, I left my ethernet card out of the config, and noticed after I rebooted, so I booted with the old kernel, but newer world. Im getting the slowness with the older kernel, as well as with the newer kernel. I have no debug options in my kern config. I hope this info helps some. thanks! -chris From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 13:12:39 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BDF737B401 for ; Wed, 13 Aug 2003 13:12:39 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 717B143FD7 for ; Wed, 13 Aug 2003 13:12:36 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id E70832A8 for ; Wed, 13 Aug 2003 14:12:35 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7DKCZI07910 for sparc64@freebsd.org; Wed, 13 Aug 2003 14:12:35 -0600 Date: Wed, 13 Aug 2003 14:12:35 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030813141235.Z22214@seekingfire.com> References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> <20030813155523.GB99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> <001501c361b4$f84e6280$2bd90c42@officescape.net> <20030813180823.W97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030813180823.W97608@beagle.fokus.fraunhofer.de>; from brandt@fokus.fraunhofer.de on Wed, Aug 13, 2003 at 06:12:09PM +0200 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 20:12:39 -0000 On Wed, Aug 13, 2003 at 06:12:09PM +0200, Harti Brandt wrote: > Well, you're the 2nd one who reports that nothing has changed. Several > people however report, that they see the 3x increase. And I see it myself, > no matter how often I look at this. Today I tried to build the vinum > module: > > gcc-3.3.1 yesterday's kernel 132 + 85 + 20 > gcc-3.2.2 yesterday's kernel 131 + 85 + 22 > gcc-3.2.2 kernel from June 1st 52 + 27 + 7 > > Exactly the same config and the same world (except for gcc). > > This is an Ultra10. Perhaps it depends on the sparc model? Yours is an Ultra 10, right? Mine is an Ultra 5 ... both are IDE models, I believe. Perhaps something along those lines? -T -- Talking about Zen all the time is like looking for fish tracks in a dry river bed. Wu-Tzu From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 13 13:17:59 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40EA237B401 for ; Wed, 13 Aug 2003 13:17:59 -0700 (PDT) Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C89543F93 for ; Wed, 13 Aug 2003 13:17:54 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: from inlafsteve (bdsl.66.12.217.43.gte.net [66.12.217.43]) (authenticated bits=0) by energistic.com (8.12.9/8.12.9) with ESMTP id h7DKHlCF060710; Wed, 13 Aug 2003 15:17:49 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <01dd01c361d7$f7a03340$2bd90c42@officescape.net> From: "Steve Ames" To: "Tillman" , References: <20030807062536.GA68747@dragon.nuxi.com><20030812213355.M22214@seekingfire.com><20030813154823.GA99828@energistic.com><20030813155523.GB99828@energistic.com><20030813175634.P97608@beagle.fokus.fraunhofer.de><001501c361b4$f84e6280$2bd90c42@officescape.net><20030813180823.W97608@beagle.fokus.fraunhofer.de> <20030813141235.Z22214@seekingfire.com> Date: Wed, 13 Aug 2003 15:17:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 20:17:59 -0000 ----- Original Message ----- From: "Tillman" > > gcc-3.3.1 yesterday's kernel 132 + 85 + 20 > > gcc-3.2.2 yesterday's kernel 131 + 85 + 22 > > gcc-3.2.2 kernel from June 1st 52 + 27 + 7 > > > > Exactly the same config and the same world (except for gcc). > > > > This is an Ultra10. Perhaps it depends on the sparc model? > > Yours is an Ultra 10, right? Mine is an Ultra 5 ... both are IDE models, > I believe. Perhaps something along those lines? Mines an ultra 5, IDE and 128M RAM. It still goes pretty fast. I've been running time building the vinum module also with various kernels (adding and removing debug options)... so far I can't get mine to go anywhere near as slow as the times Mr. Brandt posted: CLEAN: 41.88 real 35.96 user 2.30 sys DDB: 43.88 real 35.75 user 1.87 sys DDB/-g: 43.73 real 35.88 user 1.96 sys DDB/-g/INVARIENTS: 44.35 real 35.95 user 2.29 sys I'm waiting now on my kernel that has WITNESS enabled to give that a whirl. I know with a GENERIC kernel a 'make world' takes about 12 hours. With my current kernel conf it takes 4.5 hours. If you have an ultra 5 could you give my kernel configuration a try and see how it works for you? I posted it earlier... -Steve From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 03:04:06 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01DCA37B401 for ; Fri, 15 Aug 2003 03:04:06 -0700 (PDT) Received: from ferengi.skynet.be (ferengi.skynet.be [195.238.2.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BAD943F93 for ; Fri, 15 Aug 2003 03:04:04 -0700 (PDT) (envelope-from trollet@skynet.be) Received: from skynet.be (49.187-201-80.adsl.skynet.be [80.201.187.49]) ESMTP id h7FA3p6t029390 for ; Fri, 15 Aug 2003 12:03:51 +0200 (envelope-from ) Sender: atle@ferengi.skynet.be Message-ID: <3F3CAAB6.A603924B@skynet.be> Date: Fri, 15 Aug 2003 11:41:10 +0200 From: Atle X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: no, en MIME-Version: 1.0 To: sparc64@freebsd.org References: <20030807062536.GA68747@dragon.nuxi.com> <20030812213355.M22214@seekingfire.com> <20030813154823.GA99828@energistic.com> <20030813155523.GB99828@energistic.com> <20030813175634.P97608@beagle.fokus.fraunhofer.de> <001501c361b4$f84e6280$2bd90c42@officescape.net> <20030813141235.Z22214@seekingfire.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: ponderous 'make world' times post GCC 3.3... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 10:04:06 -0000 Tillman wrote: > > On Wed, Aug 13, 2003 at 06:12:09PM +0200, Harti Brandt wrote: > > Well, you're the 2nd one who reports that nothing has changed. Several > > people however report, that they see the 3x increase. And I see it myself, > > no matter how often I look at this. Today I tried to build the vinum > > module: > > > > gcc-3.3.1 yesterday's kernel 132 + 85 + 20 > > gcc-3.2.2 yesterday's kernel 131 + 85 + 22 > > gcc-3.2.2 kernel from June 1st 52 + 27 + 7 > > > > Exactly the same config and the same world (except for gcc). > > > > This is an Ultra10. Perhaps it depends on the sparc model? > > Yours is an Ultra 10, right? Mine is an Ultra 5 ... both are IDE models, > I believe. Perhaps something along those lines? Same software, same machines, different results=can_not_be. Something has to be different. Options? Creator? Network? Is some perfipheral card sending spurious interrupts to a bogus handler, or an inefficient handler? Atle From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 03:20:46 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3967E37B401; Fri, 15 Aug 2003 03:20:46 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B40DB43F93; Fri, 15 Aug 2003 03:20:44 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7FAKdv12612; Fri, 15 Aug 2003 12:20:39 +0200 (MEST) Date: Fri, 15 Aug 2003 12:20:39 +0200 (CEST) From: Harti Brandt To: sparc64@freebsd.org Message-ID: <20030815121010.I97608@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jmg@freebsd.org Subject: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 10:20:46 -0000 Hi all, it seems I have identified which commit causes the slow down on some sparcs. The kernel from just before that commit works just fine, the kernel from just after it is 3x slower on my Ultra-10 (as was also reported by others). I have no idea why that happens. The only difference in the time -l report is user and system time going up by a factor of three and the involuntary context switches doubling. It is also not (easily) possible to revert that commit, because of other changes (for example, pci.c:1.220). When I simply revert the change, the machine gets a missed data trap when accessing register 14 on non-existing slots, when I add register 14 in the if() at the start of psycho_read_config, the machine freezes after finding pci1. Could please someone of the low-level sparc experts look at the problem? While doing my binary search I also noted a gradual shift in performace with time in the order of 5% (performance getting worse) in two month. Wouldn't it be feasable to, let's say, run once or twice a week two simple benchmarks (one disk bound, the other cpu bound) on a fresh kernel and have the results available on a web-site, so that we can note such performance shifts? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org ---------- Forwarded message ---------- Date: Sat, 21 Jun 2003 18:26:08 -0700 (PDT) From: John-Mark Gurney To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sparc64/include bus.h cpufunc.h src/sys/sparc64/pci psycho.c src/sys/sparc64/sparc64 support.S trap.c jmg 2003/06/21 18:26:08 PDT FreeBSD src repository Modified files: sys/sparc64/include bus.h cpufunc.h sys/sparc64/pci psycho.c sys/sparc64/sparc64 support.S trap.c Log: add support for peeking at pci busses on UltraSparc systems. This prevents data access errors when trying to read/write to non-existant PCI devices. fix the psycho bridge to use peek for probing devices. This no longer fakes it if the OFW node doesn't exist (and the reg == 0). Reviewed by: jake, tmm Revision Changes Path 1.28 +27 -0 src/sys/sparc64/include/bus.h 1.17 +9 -0 src/sys/sparc64/include/cpufunc.h 1.39 +19 -12 src/sys/sparc64/pci/psycho.c 1.27 +52 -0 src/sys/sparc64/sparc64/support.S 1.64 +25 -0 src/sys/sparc64/sparc64/trap.c From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 06:50:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AE8837B404 for ; Fri, 15 Aug 2003 06:50:28 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D7FC43FDD for ; Fri, 15 Aug 2003 06:50:26 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 17031 invoked by uid 65534); 15 Aug 2003 13:50:24 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp025) with SMTP; 15 Aug 2003 15:50:24 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19neyR-0000cm-Kd; Fri, 15 Aug 2003 15:50:35 +0200 Date: Fri, 15 Aug 2003 15:50:35 +0200 From: Thomas Moestl To: Harti Brandt Message-ID: <20030815135034.GA701@crow.dom2ip.de> Mail-Followup-To: Harti Brandt , sparc64@freebsd.org, jmg@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815121010.I97608@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 13:50:28 -0000 On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: > > Hi all, > > it seems I have identified which commit causes the slow down on some > sparcs. The kernel from just before that commit works just fine, the > kernel from just after it is 3x slower on my Ultra-10 (as was also > reported by others). I have no idea why that happens. The only difference > in the time -l report is user and system time going up by a factor of > three and the involuntary context switches doubling. It seems that deferred errors (and thus the data access errors generated due to PCI bus timeouts from non-existant devices) will disable the instruction and data cache by resetting the corresponding enable bits in the LSU control register, and the current code fails to reenable them (which also requires a cache flush). A simple workaround for now is to avoid triggering these errors, so enabling OFW_NEWPCI should help. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 07:00:58 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61B1B37B401; Fri, 15 Aug 2003 07:00:58 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B4DF43FDF; Fri, 15 Aug 2003 07:00:57 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id B54902A8; Fri, 15 Aug 2003 08:00:56 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7FE0ui12358; Fri, 15 Aug 2003 08:00:56 -0600 Date: Fri, 15 Aug 2003 08:00:56 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030815080055.O22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030815135034.GA701@crow.dom2ip.de>; from t.moestl@tu-bs.de on Fri, Aug 15, 2003 at 03:50:35PM +0200 X-Urban-Legend: There is lots of hidden information in headers cc: jmg@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 14:00:58 -0000 On Fri, Aug 15, 2003 at 03:50:35PM +0200, Thomas Moestl wrote: > On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: > > > > Hi all, > > > > it seems I have identified which commit causes the slow down on some > > sparcs. The kernel from just before that commit works just fine, the > > kernel from just after it is 3x slower on my Ultra-10 (as was also > > reported by others). I have no idea why that happens. The only difference > > in the time -l report is user and system time going up by a factor of > > three and the involuntary context switches doubling. > > It seems that deferred errors (and thus the data access errors > generated due to PCI bus timeouts from non-existant devices) will > disable the instruction and data cache by resetting the corresponding > enable bits in the LSU control register, and the current code fails to > reenable them (which also requires a cache flush). A simple workaround > for now is to avoid triggering these errors, so enabling OFW_NEWPCI > should help. Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it now and go through any needed reconfiguration will I be saving myself time in the future? The notes for OFW_NEWPCI say: # New OpenFirmware PCI framework. This fixes a number of interrupt- # routing problems and changes the device enumeration to be hopefully # closer to Solaris. Be aware that, because of the latter, enabling or # disabling this option may require reconfiguration, and can even # cause the machine to not boot without manual intervention before the # fstab is adjusted. What sort of changes are likely to occur that would affect fstab? The box is remote, so I can fix most things via a serial console as long as it'll boot :-) Thanks! -T -- The supreme irony of life is that hardly anyone gets out alive. - Robert Heinlein From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 07:33:57 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6160437B401 for ; Fri, 15 Aug 2003 07:33:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A35343FBF for ; Fri, 15 Aug 2003 07:33:55 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 6538 invoked by uid 65534); 15 Aug 2003 14:33:53 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp003) with SMTP; 15 Aug 2003 16:33:53 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19nfeW-0000js-FO; Fri, 15 Aug 2003 16:34:04 +0200 Date: Fri, 15 Aug 2003 16:34:04 +0200 From: Thomas Moestl To: Tillman Message-ID: <20030815143404.GB701@crow.dom2ip.de> Mail-Followup-To: Tillman , sparc64@freebsd.org, jmg@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815080055.O22214@seekingfire.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 14:33:57 -0000 On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote: > On Fri, Aug 15, 2003 at 03:50:35PM +0200, Thomas Moestl wrote: > > On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: > > > > > > Hi all, > > > > > > it seems I have identified which commit causes the slow down on some > > > sparcs. The kernel from just before that commit works just fine, the > > > kernel from just after it is 3x slower on my Ultra-10 (as was also > > > reported by others). I have no idea why that happens. The only difference > > > in the time -l report is user and system time going up by a factor of > > > three and the involuntary context switches doubling. > > > > It seems that deferred errors (and thus the data access errors > > generated due to PCI bus timeouts from non-existant devices) will > > disable the instruction and data cache by resetting the corresponding > > enable bits in the LSU control register, and the current code fails to > > reenable them (which also requires a cache flush). A simple workaround > > for now is to avoid triggering these errors, so enabling OFW_NEWPCI > > should help. > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it > now and go through any needed reconfiguration will I be saving myself > time in the future? Yes. > The notes for OFW_NEWPCI say: > > # New OpenFirmware PCI framework. This fixes a number of interrupt- > # routing problems and changes the device enumeration to be hopefully > # closer to Solaris. Be aware that, because of the latter, enabling or > # disabling this option may require reconfiguration, and can even > # cause the machine to not boot without manual intervention before the > # fstab is adjusted. > > What sort of changes are likely to occur that would affect fstab? The > box is remote, so I can fix most things via a serial console as long as > it'll boot :-) If you've got multiple SCSI or ATA controllers installed, the order in which they are recognized might change, which affects the enumeration of the devices attached to them. It should be no problem to boot into single user and request a mountroot prompt ('boot -as' from the loader), then identify the new disk enumeration, mount the root file system from the prompt and finally adjust the fstab in single user mode as required. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 07:58:47 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D50D137B401; Fri, 15 Aug 2003 07:58:47 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5715943FB1; Fri, 15 Aug 2003 07:58:46 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7FEwiv05943; Fri, 15 Aug 2003 16:58:44 +0200 (MEST) Date: Fri, 15 Aug 2003 16:58:44 +0200 (CEST) From: Harti Brandt To: Thomas Moestl In-Reply-To: <20030815135034.GA701@crow.dom2ip.de> Message-ID: <20030815165603.R92087@beagle.fokus.fraunhofer.de> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 14:58:48 -0000 On Fri, 15 Aug 2003, Thomas Moestl wrote: TM>On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: TM>> TM>> Hi all, TM>> TM>> it seems I have identified which commit causes the slow down on some TM>> sparcs. The kernel from just before that commit works just fine, the TM>> kernel from just after it is 3x slower on my Ultra-10 (as was also TM>> reported by others). I have no idea why that happens. The only difference TM>> in the time -l report is user and system time going up by a factor of TM>> three and the involuntary context switches doubling. TM> TM>It seems that deferred errors (and thus the data access errors TM>generated due to PCI bus timeouts from non-existant devices) will TM>disable the instruction and data cache by resetting the corresponding TM>enable bits in the LSU control register, and the current code fails to TM>reenable them (which also requires a cache flush). A simple workaround TM>for now is to avoid triggering these errors, so enabling OFW_NEWPCI TM>should help. I can confirm that it helps. I assume that OFW_NEWPCI is currently there to allow testing and one day to throw the switch and remove the old stuff? Wouldn't it help to make it the default? Otherwise the testing will be rather limited. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 08:34:50 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C88FB37B401 for ; Fri, 15 Aug 2003 08:34:50 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BD59943FDF for ; Fri, 15 Aug 2003 08:34:48 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 24796 invoked by uid 65534); 15 Aug 2003 15:34:47 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp012) with SMTP; 15 Aug 2003 17:34:47 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19ngbS-0000uM-9L; Fri, 15 Aug 2003 17:34:58 +0200 Date: Fri, 15 Aug 2003 17:34:58 +0200 From: Thomas Moestl To: harti@freebsd.org Message-ID: <20030815153458.GC701@crow.dom2ip.de> Mail-Followup-To: harti@freebsd.org, jmg@freebsd.org, sparc64@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815165603.R92087@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815165603.R92087@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 15:34:51 -0000 On Fri, 2003/08/15 at 16:58:44 +0200, Harti Brandt wrote: > On Fri, 15 Aug 2003, Thomas Moestl wrote: > > TM>On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: > TM>> > TM>> Hi all, > TM>> > TM>> it seems I have identified which commit causes the slow down on some > TM>> sparcs. The kernel from just before that commit works just fine, the > TM>> kernel from just after it is 3x slower on my Ultra-10 (as was also > TM>> reported by others). I have no idea why that happens. The only difference > TM>> in the time -l report is user and system time going up by a factor of > TM>> three and the involuntary context switches doubling. > TM> > TM>It seems that deferred errors (and thus the data access errors > TM>generated due to PCI bus timeouts from non-existant devices) will > TM>disable the instruction and data cache by resetting the corresponding > TM>enable bits in the LSU control register, and the current code fails to > TM>reenable them (which also requires a cache flush). A simple workaround > TM>for now is to avoid triggering these errors, so enabling OFW_NEWPCI > TM>should help. > > I can confirm that it helps. I assume that OFW_NEWPCI is currently there > to allow testing and one day to throw the switch and remove the old stuff? Yes. > Wouldn't it help to make it the default? Otherwise the testing will be > rather limited. I haven't made it the default because it can require configuration changes because of the different enumeration, as detailed in the warning notice in GENERIC and NOTES. I had hoped that making it an option would allow people could gradually change over their installations, so that the transition would be more painless. I guess I should make it the default soon. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 08:39:53 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79A6737B401; Fri, 15 Aug 2003 08:39:53 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA87A43FE3; Fri, 15 Aug 2003 08:39:51 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h7FFdov10054; Fri, 15 Aug 2003 17:39:50 +0200 (MEST) Date: Fri, 15 Aug 2003 17:39:50 +0200 (CEST) From: Harti Brandt To: Thomas Moestl In-Reply-To: <20030815153458.GC701@crow.dom2ip.de> Message-ID: <20030815173749.A92087@beagle.fokus.fraunhofer.de> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815165603.R92087@beagle.fokus.fraunhofer.de> <20030815153458.GC701@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 15:39:53 -0000 On Fri, 15 Aug 2003, Thomas Moestl wrote: TM>On Fri, 2003/08/15 at 16:58:44 +0200, Harti Brandt wrote: [SNIP] TM>> I can confirm that it helps. I assume that OFW_NEWPCI is currently there TM>> to allow testing and one day to throw the switch and remove the old stuff? TM> TM>Yes. TM> TM>> Wouldn't it help to make it the default? Otherwise the testing will be TM>> rather limited. TM> TM>I haven't made it the default because it can require configuration TM>changes because of the different enumeration, as detailed in the TM>warning notice in GENERIC and NOTES. I had hoped that making it an TM>option would allow people could gradually change over their TM>installations, so that the transition would be more painless. TM> TM>I guess I should make it the default soon. Yes. Write a HEADSUP to the sparc list, wait a couple of days and throw the switch. Otherwise you'll not get the testing :-| harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 10:02:22 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA77F37B401 for ; Fri, 15 Aug 2003 10:02:22 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id C228F43F93 for ; Fri, 15 Aug 2003 10:02:21 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 42F8294 for ; Fri, 15 Aug 2003 11:02:21 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7FH2LD12628 for sparc64@freebsd.org; Fri, 15 Aug 2003 11:02:21 -0600 Date: Fri, 15 Aug 2003 11:02:21 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030815110221.T22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030815143404.GB701@crow.dom2ip.de>; from t.moestl@tu-bs.de on Fri, Aug 15, 2003 at 04:34:04PM +0200 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 17:02:23 -0000 On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote: > On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote: > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it > > now and go through any needed reconfiguration will I be saving myself > > time in the future? > > Yes. Great, thanks for the info. I'll compile a new kernel with OFW_NEWPCI and try installing it over the weekend (compiling isn't fast at the moment ;-) ). > > # New OpenFirmware PCI framework. This fixes a number of interrupt- > > # routing problems and changes the device enumeration to be hopefully > > # closer to Solaris. Be aware that, because of the latter, enabling or > > # disabling this option may require reconfiguration, and can even > > # cause the machine to not boot without manual intervention before the > > # fstab is adjusted. > > > > What sort of changes are likely to occur that would affect fstab? The > > box is remote, so I can fix most things via a serial console as long as > > it'll boot :-) > > If you've got multiple SCSI or ATA controllers installed, the order in > which they are recognized might change, which affects the enumeration > of the devices attached to them. > It should be no problem to boot into single user and request a > mountroot prompt ('boot -as' from the loader), then identify the new > disk enumeration, mount the root file system from the prompt and > finally adjust the fstab in single user mode as required. Excellent, it looks like remotely changing to this should be fine :-) BTW, what does "closer to Solaris" refer to? Detection order? -T -- Enlightenment is: do what you want, eat what there is Jack Kerouac From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 14:42:22 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3CFC37B401; Fri, 15 Aug 2003 14:42:22 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-107-97.dsl.lsan03.pacbell.net [64.169.107.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D79D943F3F; Fri, 15 Aug 2003 14:42:21 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 9EF9B66B60; Fri, 15 Aug 2003 14:42:17 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 7589F643; Fri, 15 Aug 2003 14:42:17 -0700 (PDT) Date: Fri, 15 Aug 2003 14:42:17 -0700 From: Kris Kennaway To: anholt@freebsd.org Message-ID: <20030815214217.GA69336@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: sparc64@FreeBSD.org Subject: XFree86-PrintServer-4.3.0 broken on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 21:42:23 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline http://bento.freebsd.org/errorlogs/sparc64-5-latest/XFree86-PrintServer-4.3.0.log Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/PVO5Wry0BWjoQKURAgKdAJ95xHnACSotLQ5dtKZ5Chdey/862ACgqzNt Oj7h+xs0kYXZMCiEDuJp8QI= =nDyr -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 15:42:54 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA59037B401; Fri, 15 Aug 2003 15:42:54 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-107-97.dsl.lsan03.pacbell.net [64.169.107.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B0143FCB; Fri, 15 Aug 2003 15:42:51 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 899FC66D7A; Fri, 15 Aug 2003 15:42:46 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 58E0D7B4; Fri, 15 Aug 2003 15:42:46 -0700 (PDT) Date: Fri, 15 Aug 2003 15:42:46 -0700 From: Kris Kennaway To: Joe Marcus Clarke Message-ID: <20030815224246.GA70248@rot13.obsecurity.org> References: <20030815213552.GA69269@rot13.obsecurity.org> <1060984591.733.72.camel@gyros> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <1060984591.733.72.camel@gyros> User-Agent: Mutt/1.4.1i cc: FreeBSD GNOME Users cc: kan@FreeBSD.org cc: sparc64@FreeBSD.org cc: Kris Kennaway Subject: Error: relocation overflow (Re: gstreamer-plugins-0.6.2_1 broken on sparc64) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 22:42:55 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2003 at 05:56:32PM -0400, Joe Marcus Clarke wrote: > On Fri, 2003-08-15 at 17:35, Kris Kennaway wrote: > > http://bento.freebsd.org/errorlogs/sparc64-5-latest/gstreamer-plugins-0= .6.2_1.log >=20 > This I'm not so sure about. It used to work as you had built GNOME on > Sparc. Nothing has changed in this port, so perhaps this is a new bug > introduced on sparc64. mjpeg.c: In function `escape_FF': mjpeg.c:478: warning: cast from pointer to integer of different size {standard input}: Assembler messages: {standard input}:4078: Error: relocation overflow Yes, this has popped up on several ports since the gcc 3.3 upgrade. I think it's a gcc bug - we worked around a similar one in XFree86-libraries in order to get it to compile with gcc 3.2. Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/PWHmWry0BWjoQKURAhFBAJ9abX1WyYQAPV4HJqwMsbDrk/yEjwCg6gEM /usDYpCffoQcM/kDszy9pLo= =kuUL -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 19:53:48 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3401437B401; Fri, 15 Aug 2003 19:53:48 -0700 (PDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FF343FBF; Fri, 15 Aug 2003 19:53:47 -0700 (PDT) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158])h7G2oLNF014969; Fri, 15 Aug 2003 22:50:21 -0400 (EDT) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) h7G2rKUA037415; Fri, 15 Aug 2003 22:53:20 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Kris Kennaway In-Reply-To: <20030815224246.GA70248@rot13.obsecurity.org> References: <20030815213552.GA69269@rot13.obsecurity.org> <1060984591.733.72.camel@gyros> <20030815224246.GA70248@rot13.obsecurity.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uTQt82dNNtryHblhRMr4" Organization: MarcusCom, Inc. Message-Id: <1061002424.79131.6.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 15 Aug 2003 22:53:45 -0400 X-Spam-Status: No, hits=-11.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: FreeBSD GNOME Users cc: kan@freebsd.org cc: sparc64@freebsd.org Subject: Re: Error: relocation overflow (Re: gstreamer-plugins-0.6.2_1 broken on sparc64) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 02:53:48 -0000 --=-uTQt82dNNtryHblhRMr4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2003-08-15 at 18:42, Kris Kennaway wrote: > On Fri, Aug 15, 2003 at 05:56:32PM -0400, Joe Marcus Clarke wrote: > > On Fri, 2003-08-15 at 17:35, Kris Kennaway wrote: > > > http://bento.freebsd.org/errorlogs/sparc64-5-latest/gstreamer-plugins= -0.6.2_1.log > >=20 > > This I'm not so sure about. It used to work as you had built GNOME on > > Sparc. Nothing has changed in this port, so perhaps this is a new bug > > introduced on sparc64. >=20 > >=20 > mjpeg.c: In function `escape_FF': > mjpeg.c:478: warning: cast from pointer to integer of different size > {standard input}: Assembler messages: > {standard input}:4078: Error: relocation overflow >=20 > Yes, this has popped up on several ports since the gcc 3.3 upgrade. I > think it's a gcc bug - we worked around a similar one in > XFree86-libraries in order to get it to compile with gcc 3.2. Yeah, I remember that. Thanks for the tip. I'll investigate this further after looking at those X diffs. Joe >=20 > Kris --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-uTQt82dNNtryHblhRMr4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA/PZy4b2iPiv4Uz4cRAlZxAJwK/5ZmasRV0Sx6ycd3BD7aW/1GOACeNteP Nly5hqmvbiQ36vWh/FSGpx8= =pfim -----END PGP SIGNATURE----- --=-uTQt82dNNtryHblhRMr4-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 21:32:01 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5EF537B401 for ; Fri, 15 Aug 2003 21:32:01 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF27C43FBD for ; Fri, 15 Aug 2003 21:32:00 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 6464246 for ; Fri, 15 Aug 2003 22:32:00 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7G4VxM14169 for sparc64@freebsd.org; Fri, 15 Aug 2003 22:31:59 -0600 Date: Fri, 15 Aug 2003 22:31:59 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030815223159.F22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030815110221.T22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030815110221.T22214@seekingfire.com>; from tillman@seekingfire.com on Fri, Aug 15, 2003 at 11:02:21AM -0600 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 04:32:02 -0000 On Fri, Aug 15, 2003 at 11:02:21AM -0600, Tillman wrote: > On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote: > > On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote: > > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it > > > now and go through any needed reconfiguration will I be saving myself > > > time in the future? > > > > Yes. > > Great, thanks for the info. I'll compile a new kernel with OFW_NEWPCI > and try installing it over the weekend (compiling isn't fast at the > moment ;-) ). I can boot on the new kernel, but my hme interfaces don't seem to work (I have 1 onboard and a 4-port card). I see this in dmesg: hme1: error signaled, status=0x20001 (etc) hme1: error signaled, status=0x30001eived, 100% packet loss hme1: too may errors; not reporting any more Here's my ifconfig: hme0: flags=8843 mtu 1500 inet 192.168.23.30 netmask 0xffffff00 broadcast 192.168.23.255 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect (none) status: no carrier hme1: flags=8843 mtu 1500 inet 24.72.10.209 netmask 0xffffff00 broadcast 24.72.10.255 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect (100baseTX ) status: active hme2: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect hme3: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect hme4: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect Some of the dmesg that looks relevent: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A DVMA map: 0xc0000000 to 0xc3ffffff pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 and: hme0: mem 0xe0000000-0xe0007fff at device 1.1 on pci1 hme0: Ethernet address: 08:00:20:c6:7f:c7 miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and: hme1: mem 0x2800000-0x2807fff at device 0.1 on pci3 pcib3: slot 0 INTB is routed to irq 25 hme1: Ethernet address: 08:00:20:c6:7f:c7 miibus1: on hme1 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and: arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 Any ideas? Is it possible that the hme interfaces are numbered in a different order with the new kernel, similar to how the disk devices could have been renumbered (but that wasn't an issue for me)? I've reverted to the kernel.old in the meantime. -T From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 22:10:08 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD637B401 for ; Fri, 15 Aug 2003 22:10:08 -0700 (PDT) Received: from energistic.com (bdsl.66.12.217.106.gte.net [66.12.217.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E48A343F75 for ; Fri, 15 Aug 2003 22:10:06 -0700 (PDT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost [127.0.0.1]) by energistic.com (8.12.9/8.12.9) with ESMTP id h7G5A1pt088023; Sat, 16 Aug 2003 00:10:02 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.12.9/8.12.9/Submit) id h7G5A07t086890; Sat, 16 Aug 2003 00:10:00 -0500 (EST) (envelope-from steve) Date: Sat, 16 Aug 2003 00:10:00 -0500 From: Steve Ames To: Tillman Message-ID: <20030816051000.GA68818@energistic.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030815110221.T22214@seekingfire.com> <20030815223159.F22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815223159.F22214@seekingfire.com> User-Agent: Mutt/1.5.4i cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 05:10:08 -0000 On Fri, Aug 15, 2003 at 10:31:59PM -0600, Tillman wrote: > Any ideas? Is it possible that the hme interfaces are numbered in a > different order with the new kernel, similar to how the disk devices > could have been renumbered (but that wasn't an issue for me)? Dunno if its possible or not but easy enough to check. Do a quick ifconfig on the current kernel and write down the interface and corresponding MAC address. Boot into new kernel and see if anything has changes. -Steve From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 22:14:26 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73CE137B401 for ; Fri, 15 Aug 2003 22:14:26 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95DB443F75 for ; Fri, 15 Aug 2003 22:14:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7G5EPwO059849; Fri, 15 Aug 2003 22:14:25 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7G5EOtV033542; Fri, 15 Aug 2003 22:14:24 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7G5EJmr033535; Fri, 15 Aug 2003 22:14:19 -0700 (PDT) (envelope-from marcel) Date: Fri, 15 Aug 2003 22:14:19 -0700 From: Marcel Moolenaar To: Tillman Message-ID: <20030816051419.GA32579@dhcp42.pn.xcllnt.net> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030815110221.T22214@seekingfire.com> <20030815223159.F22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815223159.F22214@seekingfire.com> User-Agent: Mutt/1.5.4i cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 05:14:26 -0000 On Fri, Aug 15, 2003 at 10:31:59PM -0600, Tillman wrote: > > hme0: mem 0xe0000000-0xe0007fff at device 1.1 on pci1 > hme0: Ethernet address: 08:00:20:c6:7f:c7 > > hme1: mem 0x2800000-0x2807fff at device 0.1 on pci3 > hme1: Ethernet address: 08:00:20:c6:7f:c7 > > arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 > arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 > arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 > > Any ideas? Both hme0 and hme1 have the same MAC address. Suspicious... > Is it possible that the hme interfaces are numbered in a > different order with the new kernel, similar to how the disk devices > could have been renumbered (but that wasn't an issue for me)? Yes, definitely. When you enable OFW_NEWPCI, compare the old dmesg(8) with the new one to see what has changed and correct your setup accordingly. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 16 09:01:01 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE38B37B4E0 for ; Sat, 16 Aug 2003 09:00:51 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 372C54487C for ; Sat, 16 Aug 2003 08:09:08 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 66A1546 for ; Sat, 16 Aug 2003 09:08:57 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7GF8vf14937 for sparc64@freebsd.org; Sat, 16 Aug 2003 09:08:57 -0600 Date: Sat, 16 Aug 2003 09:08:57 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030816090857.I22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030815110221.T22214@seekingfire.com> <20030815223159.F22214@seekingfire.com> <20030816051419.GA32579@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Per.Hove@math.ntnu.no on Sat, Aug 16, 2003 at 03:39:59PM +0200 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 16:01:03 -0000 On Sat, Aug 16, 2003 at 03:39:59PM +0200, Per Kristian Hove wrote: > [Marcel Moolenaar, 2003-08-15] > > | Both hme0 and hme1 have the same MAC address. Suspicious... > > Not suspicious, but quite normal on SUNs. There is an EEPROM setting > for this: > > ok printenv local-mac-address? > local-mac-address? = false > ok > > If true, network interfaces use their own MAC address. If false > (default), the system's address is used. It shouldn't matter for most people unless they try to put two interfaces into the same network. In my case the two interfaces I'm using are on different physical broadcast domains (internal and external networks). -T -- Beauty is not diminished by being shared. - Robert Heinlein From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 16 10:06:44 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A21537B41A for ; Sat, 16 Aug 2003 10:06:44 -0700 (PDT) Received: from abel.math.ntnu.no (abel.math.ntnu.no [129.241.15.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 33AF7445B9 for ; Sat, 16 Aug 2003 06:40:06 -0700 (PDT) (envelope-from perhov@math.ntnu.no) Received: (qmail 7328 invoked by uid 29119); 16 Aug 2003 13:39:59 -0000 Date: Sat, 16 Aug 2003 15:39:59 +0200 (MEST) From: Per Kristian Hove To: Marcel Moolenaar In-Reply-To: <20030816051419.GA32579@dhcp42.pn.xcllnt.net> Message-ID: References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815080055.O22214@seekingfire.com> <20030815110221.T22214@seekingfire.com> <20030816051419.GA32579@dhcp42.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 17:06:47 -0000 [Marcel Moolenaar, 2003-08-15] | Both hme0 and hme1 have the same MAC address. Suspicious... Not suspicious, but quite normal on SUNs. There is an EEPROM setting for this: ok printenv local-mac-address? local-mac-address? = false ok If true, network interfaces use their own MAC address. If false (default), the system's address is used. (I guess this has to be honored by the hme driver, but it seems that that's the case). -- Per Kristian Hove Dept. of Mathematical Sciences Norwegian University of Science and Technology From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 16 14:27:32 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0885637B405; Sat, 16 Aug 2003 14:27:32 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8CE043FBF; Sat, 16 Aug 2003 14:27:28 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h7GLRSQX006209; Sat, 16 Aug 2003 14:27:28 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h7GLRRaH006208; Sat, 16 Aug 2003 14:27:27 -0700 (PDT) Date: Sat, 16 Aug 2003 14:27:27 -0700 From: "David O'Brien" To: Thomas Moestl Message-ID: <20030816212727.GA6164@dragon.nuxi.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815143404.GB701@crow.dom2ip.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 21:27:32 -0000 On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote: > > The notes for OFW_NEWPCI say: > > > > # New OpenFirmware PCI framework. This fixes a number of interrupt- > > # routing problems and changes the device enumeration to be hopefully > > # closer to Solaris. Be aware that, because of the latter, enabling or > > # disabling this option may require reconfiguration, and can even > > # cause the machine to not boot without manual intervention before the > > # fstab is adjusted. > > > > What sort of changes are likely to occur that would affect fstab? The > > box is remote, so I can fix most things via a serial console as long as > > it'll boot :-) Please, please, please, please consider making OFW_NEWPCI the default. After turning it on, 'make buildworld': 3h37m12.24s real 2h56m32.37s user 34m20.62s sys still a little slower than before, but not the 4x degradation I experienced. I'm curious why you didn't see this on your Blade 100 didn't experience this as mine did. Could it be that you have no devices in your PCI slots and I have two SCSI cards? -- -- David (obrien@FreeBSD.org) From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 16 15:09:13 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE8DB37B401 for ; Sat, 16 Aug 2003 15:09:13 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C5BB043FB1 for ; Sat, 16 Aug 2003 15:09:10 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 25780 invoked by uid 65534); 16 Aug 2003 22:09:09 -0000 Received: from p508E7962.dip.t-dialin.net (EHLO galatea.local) (80.142.121.98) by mail.gmx.net (mp003) with SMTP; 17 Aug 2003 00:09:09 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19o9Ee-0001ga-Ni; Sun, 17 Aug 2003 00:09:20 +0200 Date: Sun, 17 Aug 2003 00:09:20 +0200 From: Thomas Moestl To: David O'Brien Message-ID: <20030816220920.GA674@crow.dom2ip.de> Mail-Followup-To: David O'Brien , jmg@freebsd.org, sparc64@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030816212727.GA6164@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816212727.GA6164@dragon.nuxi.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 22:09:14 -0000 On Sat, 2003/08/16 at 14:27:27 -0700, David O'Brien wrote: > On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote: > > > The notes for OFW_NEWPCI say: > > > > > > # New OpenFirmware PCI framework. This fixes a number of interrupt- > > > # routing problems and changes the device enumeration to be hopefully > > > # closer to Solaris. Be aware that, because of the latter, enabling or > > > # disabling this option may require reconfiguration, and can even > > > # cause the machine to not boot without manual intervention before the > > > # fstab is adjusted. > > > > > > What sort of changes are likely to occur that would affect fstab? The > > > box is remote, so I can fix most things via a serial console as long as > > > it'll boot :-) > > Please, please, please, please consider making OFW_NEWPCI the default. I'll probably do that soon, but of course the bug which leaves the caches disabled should also be fixed. > After turning it on, 'make buildworld': > > 3h37m12.24s real 2h56m32.37s user 34m20.62s sys > > still a little slower than before, but not the 4x degradation I > experienced. > > I'm curious why you didn't see this on your Blade 100 didn't experience > this as mine did. Could it be that you have no devices in your PCI slots > and I have two SCSI cards? No, but I'm using OFW_NEWPCI routinely on my boxen and did not measure build times without this option. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C