From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 00:36:18 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB38416A401 for ; Sun, 1 Apr 2007 00:36:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 86F6313C459 for ; Sun, 1 Apr 2007 00:36:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so876259ana for ; Sat, 31 Mar 2007 17:36:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lYC4JoyTIICBxdHuNC9AniCHDwG3Os6ZW9jehBpzGQw+GVoiHGYASwqPuu08S7LAUJcgZxER4qIdmmLL06ZHmaY4PKkKu8f5xYx+IC/gszkwvF+/dCixOS9H6yA/eeRQHIgbmL5QFttxzZFiq0n1PQ41wh8YmTFxZYW3BMuseTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ugnuCHNabW6+drqcCpswqf3xGSzvWUNjOnSadyXM8NPMTYtwE8RZV/f0baSwF6lUjzaLXV7J3PX64WW4lz1vJqAMjIPLKcVotLPoKcOl/4rs+TYS3lr459b8sBYxgwTaDnRnZWyCQPqjOgWJ8Q6RJL4vs2sNZN0LG86YsWLpR84= Received: by 10.100.128.8 with SMTP id a8mr2556573and.1175387777509; Sat, 31 Mar 2007 17:36:17 -0700 (PDT) Received: by 10.100.191.1 with HTTP; Sat, 31 Mar 2007 17:36:17 -0700 (PDT) Message-ID: <3bbf2fe10703311736g6fd051a0w39bee9d750321b51@mail.gmail.com> Date: Sun, 1 Apr 2007 02:36:17 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kris Kennaway" In-Reply-To: <20070331234602.GB77982@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703312323.l2VNNgPb006391@repoman.freebsd.org> <20070331234602.GB77982@xor.obsecurity.org> X-Google-Sender-Auth: b78d70ea61a9c953 Cc: smp@freebsd.org, current@freebsd.org Subject: Re: cvs commit: src/share/man/man9 Makefile sx.9 src/sys/conf NOTES options src/sys/dev/acpica acpi_ec.c src/sys/dev/mxge if_mxge.c src/sys/dev/usb if_aue.c if_axe.c src/sys/gnu/fs/xfs/FreeBSD/support mrlock.c mrlock.h ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 00:36:18 -0000 2007/4/1, Kris Kennaway : > eOn Sat, Mar 31, 2007 at 11:23:42PM +0000, John Baldwin wrote: > > jhb 2007-03-31 23:23:42 UTC > > > > FreeBSD src repository > > > > Modified files: > > share/man/man9 Makefile sx.9 > > sys/conf NOTES options > > sys/dev/acpica acpi_ec.c > > sys/dev/mxge if_mxge.c > > sys/dev/usb if_aue.c if_axe.c > > sys/gnu/fs/xfs/FreeBSD/support mrlock.c mrlock.h > > sys/i386/acpica acpi_machdep.c > > sys/kern kern_sx.c > > sys/netinet6 in6_src.c > > sys/sys sleepqueue.h sx.h > > Added files: > > sys/sys _sx.h > > Log: > > Optimize sx locks to use simple atomic operations for the common cases of > > obtaining and releasing shared and exclusive locks. The algorithms for > > manipulating the lock cookie are very similar to that rwlocks. This patch > > also adds support for exclusive locks using the same algorithm as mutexes. > > Thanks to Attilio for doing this work and to John for committing it. > This is a significant step forward for 7.0 and will be the basis for > some major performance optimizations to be committed in the near > future (e.g. filedesc locking from rwatson, which gives even better > mysql performance than the "tophalf" mutexes Jeff and I recently > benchmarked). Thanks a lot to you for the biggest effort you did in testing and benchmarking the patch and to pho@ who did first stability tests on the first revision of the patch. These credits should be however shared completely with John who did an excellent job of revision on the code and in particulary for the challenging discussions we had during the time of sx rewriting. I think I learned a lot by his incredible way of coding. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 00:56:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C4B616A402; Sun, 1 Apr 2007 00:56:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E38B413C44C; Sun, 1 Apr 2007 00:56:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l310u4Uu073231; Sat, 31 Mar 2007 20:56:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l310u4GB053157; Sat, 31 Mar 2007 20:56:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 051A473039; Sat, 31 Mar 2007 19:56:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401005604.051A473039@freebsd-current.sentex.ca> Date: Sat, 31 Mar 2007 19:56:03 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 00:56:05 -0000 TB --- 2007-03-31 23:47:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-03-31 23:47:47 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-03-31 23:47:47 - cleaning the object tree TB --- 2007-03-31 23:48:15 - checking out the source tree TB --- 2007-03-31 23:48:15 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-03-31 23:48:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-03-31 23:56:23 - building world (CFLAGS=-O2 -pipe) TB --- 2007-03-31 23:56:23 - cd /src TB --- 2007-03-31 23:56:23 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 31 23:56:24 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 00:54:41 UTC 2007 TB --- 2007-04-01 00:54:41 - generating LINT kernel config TB --- 2007-04-01 00:54:41 - cd /src/sys/powerpc/conf TB --- 2007-04-01 00:54:41 - /usr/bin/make -B LINT TB --- 2007-04-01 00:54:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 00:54:41 - cd /src TB --- 2007-04-01 00:54:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 00:54:42 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/mmu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/kern/kern_sx.c:64:2: #error "You must have SMP to enable the ADAPTIVE_SX option" mkdep: compile failed *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 00:56:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 00:56:03 - ERROR: failed to build lint kernel TB --- 2007-04-01 00:56:03 - tinderbox aborted TB --- 0.68 user 2.49 system 4096.64 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 02:11:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F66416A401; Sun, 1 Apr 2007 02:11:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7348213C4AE; Sun, 1 Apr 2007 02:11:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l312BbbR076323; Sat, 31 Mar 2007 22:11:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l312BbJ0093753; Sat, 31 Mar 2007 22:11:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8723C73039; Sat, 31 Mar 2007 21:11:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401021137.8723C73039@freebsd-current.sentex.ca> Date: Sat, 31 Mar 2007 21:11:37 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 02:11:38 -0000 TB --- 2007-04-01 00:56:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 00:56:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-04-01 00:56:04 - cleaning the object tree TB --- 2007-04-01 00:56:36 - checking out the source tree TB --- 2007-04-01 00:56:36 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-04-01 00:56:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 01:04:49 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 01:04:49 - cd /src TB --- 2007-04-01 01:04:49 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 01:04:50 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 02:00:07 UTC 2007 TB --- 2007-04-01 02:00:07 - generating LINT kernel config TB --- 2007-04-01 02:00:07 - cd /src/sys/sparc64/conf TB --- 2007-04-01 02:00:07 - /usr/bin/make -B LINT TB --- 2007-04-01 02:00:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 02:00:07 - cd /src TB --- 2007-04-01 02:00:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 02:00:07 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 02:11:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 02:11:37 - ERROR: failed to build lint kernel TB --- 2007-04-01 02:11:37 - tinderbox aborted TB --- 0.83 user 2.48 system 4533.06 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 02:28:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AA8216A403; Sun, 1 Apr 2007 02:28:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 03DE513C44C; Sun, 1 Apr 2007 02:28:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l312S2Ri076928; Sat, 31 Mar 2007 22:28:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l312S28E001481; Sat, 31 Mar 2007 22:28:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1740B73039; Sat, 31 Mar 2007 21:28:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401022802.1740B73039@freebsd-current.sentex.ca> Date: Sat, 31 Mar 2007 21:28:02 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 02:28:03 -0000 TB --- 2007-04-01 01:15:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 01:15:41 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-04-01 01:15:41 - cleaning the object tree TB --- 2007-04-01 01:16:01 - checking out the source tree TB --- 2007-04-01 01:16:01 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-04-01 01:16:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 01:23:59 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 01:23:59 - cd /src TB --- 2007-04-01 01:23:59 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 01:24:00 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 02:17:17 UTC 2007 TB --- 2007-04-01 02:17:17 - generating LINT kernel config TB --- 2007-04-01 02:17:17 - cd /src/sys/sun4v/conf TB --- 2007-04-01 02:17:17 - /usr/bin/make -B LINT TB --- 2007-04-01 02:17:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 02:17:17 - cd /src TB --- 2007-04-01 02:17:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 02:17:18 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 02:28:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 02:28:02 - ERROR: failed to build lint kernel TB --- 2007-04-01 02:28:02 - tinderbox aborted TB --- 0.57 user 2.22 system 4341.02 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 02:33:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A62F516A402 for ; Sun, 1 Apr 2007 02:33:40 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from util2.sjc1.bitgravity.com (util2.sjc1.bitgravity.com [208.67.233.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9722713C4B0 for ; Sun, 1 Apr 2007 02:33:40 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from c-69-181-166-240.hsd1.ca.comcast.net ([69.181.166.240] helo=[192.168.1.197]) by util2.sjc1.bitgravity.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HXpLE-000LMy-B7 for current@freebsd.org; Sat, 31 Mar 2007 18:58:48 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070401005604.051A473039@freebsd-current.sentex.ca> References: <20070401005604.051A473039@freebsd-current.sentex.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Barrett Lyon Date: Sat, 31 Mar 2007 18:58:27 -0700 To: current@freebsd.org X-Mailer: Apple Mail (2.752.2) Cc: Subject: TCP sessions hanging in FIN_WAIT_1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 02:33:40 -0000 I've been testing CURRENT for a bit and with a thousands of short lived HTTP sessions, CURRENT hangs most of the sessions in FIN_WAIT_1 status until the machine runs out of resources and causes the network stack to stop performing. The HTTP daemon I am playing with is lighttpd-1.4.13, and I don't see this happening on any of the 6.2 test machines I run. There's nothing unusual about the build other than the interface card running the mxge driver. Has anyone else seen reports of this? I have seen this behavior on all source up to today's tree. -Barrett Barrett Lyon email/sip/iax: blyon@blyon.com From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 03:19:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6513016A401 for ; Sun, 1 Apr 2007 03:19:46 +0000 (UTC) (envelope-from tiffany.snyder@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.freebsd.org (Postfix) with ESMTP id 253D213C44B for ; Sun, 1 Apr 2007 03:19:46 +0000 (UTC) (envelope-from tiffany.snyder@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1098429wra for ; Sat, 31 Mar 2007 20:19:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MvnIx+vIwCDa47PYSCaV3meshrUJZGIBgJNQ+qB2QevRZWok+EVMfEiDv/rmciv3ewJTURhUy5dm2EoLYtjgijMPyGmx6IUnNSJn3NPkR1a71xweTcx/PooT3vlMxSfx6Ig0JtRaEur0sbLutK/d0TrQcL1lo2R7JhbIfsy2Xbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ArvAMBIDwer30PqQ4gRsc+mWXHVLRyidgMyni11DG3nUriWKkKkP43IWdAQJ/pDbMv0CvELSNNHJZzHHjHq3joLxt+3GGJq6YbhHG2yH+JbHcOJjZL7vY43vTpxAPZgncH5u06SsWX99PfCr7m6z3Uwd10cM+aYEqTdKIZKZamA= Received: by 10.65.152.17 with SMTP id e17mr7079432qbo.1175396081370; Sat, 31 Mar 2007 19:54:41 -0700 (PDT) Received: by 10.114.145.20 with HTTP; Sat, 31 Mar 2007 19:54:41 -0700 (PDT) Message-ID: Date: Sat, 31 Mar 2007 18:54:41 -0800 From: "Tiffany Snyder" To: "Kris Kennaway" In-Reply-To: <20070330192406.GA17536@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070329215652.GD1524@roadrunner.q.local> <20070330192406.GA17536@xor.obsecurity.org> Cc: current@freebsd.org Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 03:19:46 -0000 Kris, would you be able to elaborate more on why DTrace has ben suspended due to non-technical reasons - basically what the issue? I seen a few from -current offering to help. I just saw another email on this very topic on the OpenSolaris dtrace mailing list. Tiffany. On 3/30/07, Kris Kennaway wrote: > On Thu, Mar 29, 2007 at 11:56:52PM +0200, Ulrich Spoerlein wrote: > > Hi, > > > > there hasn't been much news about several features that were once said > > to arrive Real Soon[TM]. I just wanted to gather some news about their > > status and if they can/will/should make it into 7.0. > > > > - Superpages > > Don't know, I hope so. > > > - HPS USB stack > > It seems unlikely. > > > - DTrace > > Suspended due to non-technical reasons. > > > - ZFS > > Maybe. > > > - Xorg 7.1 (7.2?) > > Yes. > > Kris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 03:31:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CFB816A406 for ; Sun, 1 Apr 2007 03:31:44 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id C05FE13C465 for ; Sun, 1 Apr 2007 03:31:43 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so899885ana for ; Sat, 31 Mar 2007 20:31:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g2izwYAccuewXm2CBAvRyJQTSaGRTtxUdIIWvZJgrncm89PcYyf5k9mjzi0J+ep81IuriNhRwA8LHrITZxupUBQUJ6pqBLM/xu2e2OqmhaCYSkkZSw7MqFRcprV3OwZfcv14HYbUTGrtwRaPMvW/N/SjaPE7SlEw0vwf5zXJPn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AezW5Q3MV1Vd2E2HUZAxpAgxiUrBUScg3O7lxwWMQhwOndM+L6JHrkCoceWoSKOJey6RHvU+GgadveEx8RW1M10jtk0ta2Skrse6T2MoUzhE97HFzzC1ArQ16bmIKwZ4JMs9UrWGS5GM7Mz8cEv0DOSfMbi3jGuTvCWz0iuMO6E= Received: by 10.65.240.17 with SMTP id s17mr7190250qbr.1175398302759; Sat, 31 Mar 2007 20:31:42 -0700 (PDT) Received: from ?192.168.1.2? ( [75.60.112.101]) by mx.google.com with ESMTP id 38sm16999324nzk.2007.03.31.20.31.41; Sat, 31 Mar 2007 20:31:41 -0700 (PDT) Message-ID: <460F27B0.6040100@gmail.com> Date: Sat, 31 Mar 2007 22:32:00 -0500 From: Harrison Grundy User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Tiffany Snyder References: <20070329215652.GD1524@roadrunner.q.local> <20070330192406.GA17536@xor.obsecurity.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 03:31:44 -0000 Tiffany Snyder wrote: > Kris, > would you be able to elaborate more on why DTrace has ben > suspended due to non-technical reasons - basically what the issue? I > seen a few from -current offering to help. I just saw another email on > this very topic on the OpenSolaris dtrace mailing list. > > Tiffany. > As I understand it, its an issue with some of Sun's header files, and the CDDL. I'm working on a clean re-implimentation of these, but there's currently no ETA on when this will be accomplished, or even if this will be sufficent. --- Harrison From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 03:36:08 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 976E116A402 for ; Sun, 1 Apr 2007 03:36:08 +0000 (UTC) (envelope-from kpeter@melbpc.org.au) Received: from vscan02.westnet.com.au (vscan02.westnet.com.au [203.10.1.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7555513C448 for ; Sun, 1 Apr 2007 03:36:07 +0000 (UTC) (envelope-from kpeter@melbpc.org.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8F13311D462 for ; Sun, 1 Apr 2007 11:04:08 +0800 (WST) Received: from vscan02.westnet.com.au ([127.0.0.1]) by localhost (vscan02.westnet.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10862-11 for ; Sun, 1 Apr 2007 11:04:08 +0800 (WST) Received: from [192.168.0.2] (dsl-124-150-85-183.vic.westnet.com.au [124.150.85.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vscan02.westnet.com.au (Postfix) with ESMTP id 41CF411D24A for ; Sun, 1 Apr 2007 11:04:05 +0800 (WST) Message-ID: <460F2125.7070907@melbpc.org.au> Date: Sun, 01 Apr 2007 13:04:05 +1000 From: Peter Kostouros Organization: Melbourne PC User Group User-Agent: Thunderbird 1.5.0.9 (X11/20070101) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Content-Type: multipart/mixed; boundary="------------060609090407070800020702" Cc: Subject: [panic] Duplicate free of item ... from zone ... (mbuf_packet) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kpeter@melbpc.org.au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 03:36:08 -0000 This is a multi-part message in MIME format. --------------060609090407070800020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I have attached a debug session I hope someone finds useful in tracking the problem. I have noticed intermittent panics for about a month which may or may not be related, but the panics seem to occur while downloading (and or uploading). My sources are from 30MAR2007. Please let me know if I can provide further information. -- Regards Peter As always the organisation disavows knowledge of this email --------------060609090407070800020702 Content-Type: text/plain; name="script_159.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="script_159.txt" Script started on Sun Apr 1 12:38:04 2007 baron# exitkgdb -c /var/crash/vmcore.159 -f /boot/kernel/kernel [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Slab at 0xc456bfa8, freei 7 = 0. panic: Duplicate free of item 0xc456b700 from zone 0xc1462b40(mbuf_packet) cpuid = 0 Uptime: 2h51m45s Physical memory: 1011 MB Dumping 167 MB: 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:172 #1 0xc0787a5a in boot (howto=260) at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0787e21 in panic (fmt=0xc0aa836d "Duplicate free of item %p from zone %p(%s)\n") at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:563 #3 0xc093aaab in uma_dbg_free (zone=0xc1462b40, slab=0xc456bfa8, item=0xc456b700) at /mnt/cvs/FreeBSD/usr/src/sys/vm/uma_dbg.c:302 #4 0xc0938bea in uma_zfree_arg (zone=0xc1462b40, item=0xc456b700, udata=0x0) at /mnt/cvs/FreeBSD/usr/src/sys/vm/uma_core.c:2261 #5 0xc07dac88 in mb_free_ext (m=0xc456b700) at uma.h:305 #6 0xc07daab0 in m_freem (mb=0x0) at mbuf.h:447 #7 0xc46849f8 in ?? () #8 0xc456b700 in ?? () #9 0x00000000 in ?? () #10 0xe2981c54 in ?? () #11 0xc4033000 in ?? () #12 0x460f1757 in ?? () #13 0xe2981c54 in ?? () #14 0xc4684c1f in ?? () #15 0xc4033000 in ?? () #16 0xc51ca410 in ?? () #17 0xffffffff in ?? () #18 0xc4691848 in ?? () #19 0x00000016 in ?? () #20 0xe2981c70 in ?? () #21 0xc466aabf in ?? () #22 0xc4691ce4 in ?? () #23 0x00000000 in ?? () #24 0xc468ee5c in ?? () #25 0x000003e5 in ?? () #26 0x00000000 in ?? () #27 0xe2981cb0 in ?? () #28 0xc0798a66 in softclock (dummy=0xc4033000) at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_timeout.c:273 Previous frame inner to this frame (corrupt stack?) (kgdb) up 3 #3 0xc093aaab in uma_dbg_free (zone=0xc1462b40, slab=0xc456bfa8, item=0xc456b700) at /mnt/cvs/FreeBSD/usr/src/sys/vm/uma_dbg.c:302 /mnt/cvs/FreeBSD/usr/src/sys/vm/uma_dbg.c:302:7275:beg:0xc093aaab (kgdb) l 297 slabref->us_freelist[freei].us_item = 0; 298 } else { 299 if (slab->us_freelist[freei].us_item != 255) { 300 printf("Slab at %p, freei %d = %d.\n", 301 slab, freei, slab->us_freelist[freei].us_item); 302 panic("Duplicate free of item %p from zone %p(%s)\n", 303 item, zone, zone->uz_name); 304 } 305 306 /* (kgdb) p *zone $1 = {uz_name = 0xc0a88782 "mbuf_packet", uz_lock = 0xc1474e88, uz_keg = 0xc1474e80, uz_link = { le_next = 0x0, le_prev = 0xc146278c}, uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = { lh_first = 0x0}, uz_ctor = 0xc077b090 , uz_dtor = 0xc077acf0 , uz_init = 0xc077afc0 , uz_fini = 0xc077b030 , uz_allocs = 1151793, uz_frees = 1151409, uz_fails = 0, uz_fills = 0, uz_count = 128, uz_cpu = {{ uc_freebucket = 0xc5071c48, uc_allocbucket = 0xc145a624, uc_allocs = 281595, uc_frees = 281587}}} (kgdb) p slab $2 = 0xc456bfa8 (kgdb) p slab* $3 = {us_head = {us_keg = 0xc1474e80, us_type = {_us_link = {le_next = 0xc4606fa8, le_prev = 0xc1474eb0}, _us_size = 3294654376}, us_hlink = {sle_next = 0x0}, us_data = 0xc456b000 "", us_flags = 2 '\002', us_freecount = 1 '\001', us_firstfree = 8 '\b'}, us_freelist = {{us_item = 255 'ÿ'}}} (kgdb) p *slab     freei $4 = 7 (kgdb) p freei     *slab     slab->        p item $5 = (void *) 0xc456b700 (kgdb) p item* Attempt to dereference a generic pointer. (kgdb) exit    quit baron# exit exit Script done on Sun Apr 1 12:40:45 2007 --------------060609090407070800020702 Content-Type: text/plain; name="BARON" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="BARON" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.459 2006/10/26 22:11:35 jb Exp $ cpu I686_CPU ident BARON # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_4BSD # 4BSD scheduler options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption 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 MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) 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 KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) 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) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) # BARON device sound device snd_emu10kx options P1003_1B_MQUEUE options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC options ALTQ_DEBUG # options DEBUG # # Options to enable ATAPI devices to be accessed through SCSI subsystem # device atapicam device ata device scbus device cd device pass device iicbus device iicbb # # Hardware performance monitoring counter support. # options HWPMC_HOOKS device hwpmc --------------060609090407070800020702-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 04:26:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1199B16A402 for ; Sun, 1 Apr 2007 04:26:03 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id D93AD13C457 for ; Sun, 1 Apr 2007 04:26:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 689A35D00; Sun, 1 Apr 2007 00:07:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGyTnjczXb0l; Sun, 1 Apr 2007 00:07:50 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-116-136.ny325.east.verizon.net [68.161.116.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id CD6185C66; Sun, 1 Apr 2007 00:07:49 -0400 (EDT) Message-ID: <460F3015.5020308@mac.com> Date: Sun, 01 Apr 2007 00:07:49 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Harrison Grundy References: <20070329215652.GD1524@roadrunner.q.local> <20070330192406.GA17536@xor.obsecurity.org> <460F27B0.6040100@gmail.com> In-Reply-To: <460F27B0.6040100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tiffany Snyder , freebsd-current@freebsd.org Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 04:26:03 -0000 Harrison Grundy wrote: > Tiffany Snyder wrote: >> Kris, >> would you be able to elaborate more on why DTrace has ben >> suspended due to non-technical reasons - basically what the issue? I >> seen a few from -current offering to help. I just saw another email on >> this very topic on the OpenSolaris dtrace mailing list. >> >> Tiffany. >> > As I understand it, its an issue with some of Sun's header files, and > the CDDL. > > I'm working on a clean re-implimentation of these, but there's currently > no ETA on when this will be accomplished, or even if this will be > sufficent. Has anyone asked Sun whether they would dual-license the needed header files under a BSD-friendly license? Or whether they would publish the APIs via an RFC so that you could easily re-implement against that as a published spec? Sun's released lots of things like XDR and NFS via RFCs, so it's at least not unprecedented. :-) Anyone know Casper Dik well? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 04:29:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A78B16A401 for ; Sun, 1 Apr 2007 04:29:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id 2938613C4B8 for ; Sun, 1 Apr 2007 04:29:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so849724wxc for ; Sat, 31 Mar 2007 21:29:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ua1NCsJU+50o37kMaeE8+80xpTN/9i7jADX3N6Y0/nmsSeSiJA9lL4XaQx7FQVvmv0GxG3sKIZVlUOc6gsJRTO9c9M7qcGquu6vuqS91KPVNUETFDwXWsm+uG2dn0ZuISYhd7SlAcjBDXsxitRs6SiVkRjaWn+74kYkqWCzsCEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=peKpNAK+0NuMhK2oSoYG1CT9aIxJJEWgMo7DkrUBvc0VwtgABB5ukVSho3fwTspPFSnqsWqE6ECemzSdCgAjIKTcDCFCH7crF3GSvpD5iWhMkYSNaqKZ7ZAo5t/r79kToMJTfJ2sRPgmRPwRy76rAUAgtve23r6bGC8V1MZGDKI= Received: by 10.90.52.2 with SMTP id z2mr2563772agz.1175401786143; Sat, 31 Mar 2007 21:29:46 -0700 (PDT) Received: by 10.90.116.6 with HTTP; Sat, 31 Mar 2007 21:29:46 -0700 (PDT) Message-ID: Date: Sat, 31 Mar 2007 21:29:46 -0700 From: "Kip Macy" To: "Chuck Swiger" In-Reply-To: <460F3015.5020308@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070329215652.GD1524@roadrunner.q.local> <20070330192406.GA17536@xor.obsecurity.org> <460F27B0.6040100@gmail.com> <460F3015.5020308@mac.com> Cc: Tiffany Snyder , Harrison Grundy , freebsd-current@freebsd.org Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 04:29:47 -0000 > Has anyone asked Sun whether they would dual-license the needed header files > under a BSD-friendly license? Yes. Current answer is they'll think about it. > Or whether they would publish the APIs via an > RFC so that you could easily re-implement against that as a published spec? I don't know. That would be the cleanest approach. > Sun's released lots of things like XDR and NFS via RFCs, so it's at least not > unprecedented. :-) Its not a communications interface. They don't really have anything to gain (expect perhaps for good will), from standardizing it. -Kip From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 05:52:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A048116A405 for ; Sun, 1 Apr 2007 05:52:38 +0000 (UTC) (envelope-from tiffany.snyder@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.freebsd.org (Postfix) with ESMTP id 5E65613C483 for ; Sun, 1 Apr 2007 05:52:38 +0000 (UTC) (envelope-from tiffany.snyder@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1118027wra for ; Sat, 31 Mar 2007 22:52:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OENjBz5N0d3FFvp+VznN4XG3jSgedPUulNmapMce+FXXX/H+JCS6tUzr9hWS1KzRt0jFrLr+mKbnkKxm9oBTXsMkgYjNF2QzVMN/pp9IuBKlfaR5Z5LKMokaAzX+l1Uxv/BeybDAaBbZVWzz//1Ba2sKAdWCz7b8gdxbCxOcSW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TDtCHolGb++6fnaLrXCQM95hlKWTGDSFQqVa1lU6O4m7XeaEqwzP5pJGHHSmCtW0d3PbQf86JN+fVnBD1SmNH0UdkwS9xGKl4isI6EgRoXImDKx8ScR0Xyn4Njtz+mb7TezUCkEn0Peea+QOWK6GAs2FJ5VavZWz5ZUi02T2bsI= Received: by 10.114.153.18 with SMTP id a18mr1349273wae.1175405062992; Sat, 31 Mar 2007 22:24:22 -0700 (PDT) Received: by 10.114.145.20 with HTTP; Sat, 31 Mar 2007 22:24:22 -0700 (PDT) Message-ID: Date: Sat, 31 Mar 2007 21:24:22 -0800 From: "Tiffany Snyder" To: "Chuck Swiger" In-Reply-To: <460F3015.5020308@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070329215652.GD1524@roadrunner.q.local> <20070330192406.GA17536@xor.obsecurity.org> <460F27B0.6040100@gmail.com> <460F3015.5020308@mac.com> Cc: freebsd-current@freebsd.org, Harrison Grundy Subject: Re: Will these new features make it into 7.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 05:52:38 -0000 http://www.opensolaris.org/jive/thread.jspa?threadID=27426&tstart=0 On 3/31/07, Chuck Swiger wrote: > Harrison Grundy wrote: > > Tiffany Snyder wrote: > >> Kris, > >> would you be able to elaborate more on why DTrace has ben > >> suspended due to non-technical reasons - basically what the issue? I > >> seen a few from -current offering to help. I just saw another email on > >> this very topic on the OpenSolaris dtrace mailing list. > >> > >> Tiffany. > >> > > As I understand it, its an issue with some of Sun's header files, and > > the CDDL. > > > > I'm working on a clean re-implimentation of these, but there's currently > > no ETA on when this will be accomplished, or even if this will be > > sufficent. > > Has anyone asked Sun whether they would dual-license the needed header files > under a BSD-friendly license? Or whether they would publish the APIs via an > RFC so that you could easily re-implement against that as a published spec? > Sun's released lots of things like XDR and NFS via RFCs, so it's at least not > unprecedented. :-) > > Anyone know Casper Dik well? > > -- > -Chuck > From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 05:57:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07CE216A402; Sun, 1 Apr 2007 05:57:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8AF13C45A; Sun, 1 Apr 2007 05:57:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B0E2817380; Sun, 1 Apr 2007 05:57:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l315vb80088952; Sun, 1 Apr 2007 05:57:37 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 31 Mar 2007 16:06:22 CST." <20070331.160622.-30982624.imp@bsdimp.com> Date: Sun, 01 Apr 2007 05:57:37 +0000 Message-ID: <88951.1175407057@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: wkoszek@freebsd.org, spam@rm-rf.kiev.ua, freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 05:57:41 -0000 In message <20070331.160622.-30982624.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <20070324153108.P4956@fledge.watson.org> > Robert Watson writes: >: >> By the way, any plan to include INCLUDE_CONFIG_FILE in GENERIC? >: > >: > I'd like to have this enabled by default, and I know there should be no >: > strong objections. >: >: I agree -- the memory used by it is very small compared to the amount of >: memory in modern systems, and the potential administrative benefit is very >: large. As long as it remains an option, the embedded folk can turn it off >: easily. > >Agreed, with both my large system and embedded hats on :-) Feature request: If the config is included, stuff it in the minidump ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 07:00:41 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8F5316A402 for ; Sun, 1 Apr 2007 07:00:41 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C86BA13C44B for ; Sun, 1 Apr 2007 07:00:41 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 7293E1A4DB2; Sun, 1 Apr 2007 00:00:41 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6CB0B51E4D; Sun, 1 Apr 2007 03:00:38 -0400 (EDT) Date: Sun, 1 Apr 2007 03:00:38 -0400 From: Kris Kennaway To: Peter Kostouros Message-ID: <20070401070037.GA94785@xor.obsecurity.org> References: <460F2125.7070907@melbpc.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460F2125.7070907@melbpc.org.au> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@FreeBSD.ORG Subject: Re: [panic] Duplicate free of item ... from zone ... (mbuf_packet) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 07:00:41 -0000 On Sun, Apr 01, 2007 at 01:04:05PM +1000, Peter Kostouros wrote: > Hi > > I have attached a debug session I hope someone finds useful in tracking > the problem. I have noticed intermittent panics for about a month which > may or may not be related, but the panics seem to occur while > downloading (and or uploading). This is probably a bug in your ethernet driver, which one are you using? Kris From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 07:03:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F41816A401; Sun, 1 Apr 2007 07:03:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDBC13C455; Sun, 1 Apr 2007 07:03:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l3173Y7J086464; Sun, 1 Apr 2007 03:03:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l3173YIM030497; Sun, 1 Apr 2007 03:03:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B9A5B73039; Sun, 1 Apr 2007 03:03:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401070333.B9A5B73039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 03:03:33 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 07:03:35 -0000 TB --- 2007-04-01 05:23:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 05:23:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-04-01 05:23:05 - cleaning the object tree TB --- 2007-04-01 05:23:35 - checking out the source tree TB --- 2007-04-01 05:23:35 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-04-01 05:23:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 05:31:34 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 05:31:34 - cd /src TB --- 2007-04-01 05:31:34 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 05:31:35 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 06:47:59 UTC 2007 TB --- 2007-04-01 06:47:59 - generating LINT kernel config TB --- 2007-04-01 06:47:59 - cd /src/sys/ia64/conf TB --- 2007-04-01 06:47:59 - /usr/bin/make -B LINT TB --- 2007-04-01 06:48:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 06:48:00 - cd /src TB --- 2007-04-01 06:48:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 06:48:00 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 07:03:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 07:03:33 - ERROR: failed to build lint kernel TB --- 2007-04-01 07:03:33 - tinderbox aborted TB --- 0.77 user 2.56 system 6027.97 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 07:16:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5517A16A401; Sun, 1 Apr 2007 07:16:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3DF13C44C; Sun, 1 Apr 2007 07:16:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l317GB9f086950; Sun, 1 Apr 2007 03:16:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l317GBw9062582; Sun, 1 Apr 2007 03:16:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 23E2C73039; Sun, 1 Apr 2007 03:16:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401071611.23E2C73039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 03:16:11 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 07:16:12 -0000 TB --- 2007-04-01 06:07:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 06:07:06 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-04-01 06:07:06 - cleaning the object tree TB --- 2007-04-01 06:07:30 - checking out the source tree TB --- 2007-04-01 06:07:30 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-04-01 06:07:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 06:14:52 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 06:14:52 - cd /src TB --- 2007-04-01 06:14:52 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 06:14:54 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 07:14:29 UTC 2007 TB --- 2007-04-01 07:14:29 - generating LINT kernel config TB --- 2007-04-01 07:14:29 - cd /src/sys/powerpc/conf TB --- 2007-04-01 07:14:29 - /usr/bin/make -B LINT TB --- 2007-04-01 07:14:30 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 07:14:30 - cd /src TB --- 2007-04-01 07:14:30 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 07:14:30 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/mmu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding /src/sys/kern/kern_sx.c:64:2: #error "You must have SMP to enable the ADAPTIVE_SX option" mkdep: compile failed *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 07:16:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 07:16:10 - ERROR: failed to build lint kernel TB --- 2007-04-01 07:16:10 - tinderbox aborted TB --- 0.57 user 1.71 system 4144.70 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 08:32:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 600BC16A405; Sun, 1 Apr 2007 08:32:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2F10013C45A; Sun, 1 Apr 2007 08:32:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l318WiXU090042; Sun, 1 Apr 2007 04:32:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l318Wim3003619; Sun, 1 Apr 2007 04:32:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F26BF73039; Sun, 1 Apr 2007 04:32:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401083243.F26BF73039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 04:32:43 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 08:32:45 -0000 TB --- 2007-04-01 07:03:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 07:03:34 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-04-01 07:03:34 - cleaning the object tree TB --- 2007-04-01 07:04:12 - checking out the source tree TB --- 2007-04-01 07:04:12 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-04-01 07:04:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 07:22:17 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 07:22:17 - cd /src TB --- 2007-04-01 07:22:17 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 07:22:19 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 08:21:02 UTC 2007 TB --- 2007-04-01 08:21:02 - generating LINT kernel config TB --- 2007-04-01 08:21:02 - cd /src/sys/sparc64/conf TB --- 2007-04-01 08:21:02 - /usr/bin/make -B LINT TB --- 2007-04-01 08:21:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 08:21:02 - cd /src TB --- 2007-04-01 08:21:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 08:21:03 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 08:32:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 08:32:43 - ERROR: failed to build lint kernel TB --- 2007-04-01 08:32:43 - tinderbox aborted TB --- 0.63 user 1.94 system 5349.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 08:39:56 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CDFC16A401; Sun, 1 Apr 2007 08:39:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1B913C45E; Sun, 1 Apr 2007 08:39:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l318dtGk090229; Sun, 1 Apr 2007 04:39:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l318dtFA083741; Sun, 1 Apr 2007 04:39:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 51CE473039; Sun, 1 Apr 2007 04:39:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401083955.51CE473039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 04:39:55 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 08:39:56 -0000 TB --- 2007-04-01 07:16:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 07:16:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-04-01 07:16:11 - cleaning the object tree TB --- 2007-04-01 07:16:50 - checking out the source tree TB --- 2007-04-01 07:16:50 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-04-01 07:16:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 07:31:45 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 07:31:45 - cd /src TB --- 2007-04-01 07:31:45 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 07:31:47 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 08:29:07 UTC 2007 TB --- 2007-04-01 08:29:07 - generating LINT kernel config TB --- 2007-04-01 08:29:07 - cd /src/sys/sun4v/conf TB --- 2007-04-01 08:29:07 - /usr/bin/make -B LINT TB --- 2007-04-01 08:29:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 08:29:07 - cd /src TB --- 2007-04-01 08:29:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 08:29:07 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 08:39:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 08:39:55 - ERROR: failed to build lint kernel TB --- 2007-04-01 08:39:55 - tinderbox aborted TB --- 0.57 user 1.88 system 5024.09 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 09:30:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48ED416A401 for ; Sun, 1 Apr 2007 09:30:16 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9836913C44C for ; Sun, 1 Apr 2007 09:30:15 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 01 Apr 2007 09:30:13 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp040) with SMTP; 01 Apr 2007 11:30:13 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX19UBiQuiL9UbmvMlq+gEZDqqkOQoM+rWI7VBdzblM QCa+btBJrEAHKD From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sun, 1 Apr 2007 11:30:10 +0200 User-Agent: KMail/1.9.6 References: <20070331160627.GC5704@obiwan.tataz.chchile.org> In-Reply-To: <20070331160627.GC5704@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704011130.10954.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Jeremie Le Hen Subject: Re: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 09:30:16 -0000 On Saturday 31 March 2007 18:06:27 Jeremie Le Hen wrote: > Hi, > > I've set legal.intel_iwi.license_ack=1 in loader.conf(5) and tried > to load if_iwi but I get the following message: > > % iwi0: mem 0xc8218000-0xc8218fff irq 11 at > device 3.0 on pci6 % iwi0: using obsoleted if_watchdog interface > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > % iwi0: [ITHREAD] > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > % iwi0: could not load boot firmware iwi_bss > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > % iwi0: could not load boot firmware iwi_bss > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > % iwi0: could not load boot firmware iwi_bss > % in_delmulti_locked: purging ifma 0xc3caf420 > % iwi0: timeout waiting for iwi_bss firmware initialization to complete > % iwi0: could not load boot firmware iwi_bss > > jarjarbinks:~:105# kldstat | grep iwi > 5 1 0xc4158000 30000 iwi_bss.ko > 10 1 0xc4188000 e000 if_iwi.ko You need the iwifw module. I also stumbled across this. The UPDATING entry should probably mention this. From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 12:17:26 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1BB616A402 for ; Sun, 1 Apr 2007 12:17:26 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id E88A913C43E for ; Sun, 1 Apr 2007 12:17:25 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-g20.free.fr (Postfix) with ESMTP id BCBECC7C075 for ; Sun, 1 Apr 2007 13:41:58 +0200 (CEST) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp6-g19.free.fr (Postfix) with ESMTP id 45C065DC97; Sun, 1 Apr 2007 13:41:57 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 8202711DBA; Sun, 1 Apr 2007 13:41:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at xbsd.org Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6LIURzuff28; Sun, 1 Apr 2007 13:41:51 +0200 (CEST) Received: from [193.120.13.130] (cream.xbsd.org [193.120.13.130]) by smtp.xbsd.org (Postfix) with ESMTP id 9C07B118F2; Sun, 1 Apr 2007 13:41:49 +0200 (CEST) Message-ID: <460F9A84.8040904@FreeBSD.org> Date: Sun, 01 Apr 2007 12:41:56 +0100 From: Florent Thoumie User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: Jeremie Le Hen References: <20070331160627.GC5704@obiwan.tataz.chchile.org> In-Reply-To: <20070331160627.GC5704@obiwan.tataz.chchile.org> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7181A05CCE7D25B41CDB2D10" Cc: freebsd-current@FreeBSD.org Subject: Re: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 12:17:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7181A05CCE7D25B41CDB2D10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jeremie Le Hen wrote: > Hi, >=20 > I've set legal.intel_iwi.license_ack=3D1 in loader.conf(5) and tried > to load if_iwi but I get the following message: >=20 > % iwi0: mem 0xc8218000-0xc8218fff irq 11= at device 3.0 on pci6 > % iwi0: using obsoleted if_watchdog interface > % iwi0: Ethernet address: 00:12:f0:2c:f3:6e > % iwi0: [ITHREAD] > % iwi0: timeout waiting for iwi_bss firmware initialization to complete= > % iwi0: could not load boot firmware iwi_bss > % iwi0: timeout waiting for iwi_bss firmware initialization to complete= > % iwi0: could not load boot firmware iwi_bss > % iwi0: timeout waiting for iwi_bss firmware initialization to complete= > % iwi0: could not load boot firmware iwi_bss > % in_delmulti_locked: purging ifma 0xc3caf420 > % iwi0: timeout waiting for iwi_bss firmware initialization to complete= > % iwi0: could not load boot firmware iwi_bss >=20 > jarjarbinks:~:105# kldstat | grep iwi > 5 1 0xc4158000 30000 iwi_bss.ko > 10 1 0xc4188000 e000 if_iwi.ko >=20 >=20 > Help would be welcome. Can you try to kldload iwi_bss *before* if_iwi, rather than having if_iwi automatically loading iwi_bss? --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --------------enig7181A05CCE7D25B41CDB2D10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGD5qIMxEkbVFH3PQRCnHhAJ9tvYnLR4c2tWGhkZ+kAH8fdmVw+ACggW0H rxY+n/cbdJqFgYViAPXh0Q8= =lwq4 -----END PGP SIGNATURE----- --------------enig7181A05CCE7D25B41CDB2D10-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 12:37:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 414A716A403; Sun, 1 Apr 2007 12:37:00 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id B4C1513C4AE; Sun, 1 Apr 2007 12:36:59 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id l31D7euC014318; Sun, 1 Apr 2007 13:07:41 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id l31D7aHI014317; Sun, 1 Apr 2007 13:07:36 GMT (envelope-from dunstan) Date: Sun, 1 Apr 2007 13:07:36 +0000 From: "Wojciech A. Koszek" To: Poul-Henning Kamp Message-ID: <20070401130735.GA14280@FreeBSD.czest.pl> Mail-Followup-To: "Wojciech A. Koszek" , Poul-Henning Kamp , "M. Warner Losh" , spam@rm-rf.kiev.ua, freebsd-current@freebsd.org, rwatson@freebsd.org References: <20070331.160622.-30982624.imp@bsdimp.com> <88951.1175407057@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <88951.1175407057@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Sun, 01 Apr 2007 13:07:41 +0000 (UTC) Cc: rwatson@freebsd.org, freebsd-current@freebsd.org, spam@rm-rf.kiev.ua, "M. Warner Losh" Subject: Re: Improved INCLUDE_CONFIG_FILE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 12:37:00 -0000 On Sun, Apr 01, 2007 at 05:57:37AM +0000, Poul-Henning Kamp wrote: > In message <20070331.160622.-30982624.imp@bsdimp.com>, "M. Warner Losh" writes: > >In message: <20070324153108.P4956@fledge.watson.org> > > Robert Watson writes: > >: >> By the way, any plan to include INCLUDE_CONFIG_FILE in GENERIC? > >: > > >: > I'd like to have this enabled by default, and I know there should be no > >: > strong objections. > >: > >: I agree -- the memory used by it is very small compared to the amount of > >: memory in modern systems, and the potential administrative benefit is very > >: large. As long as it remains an option, the embedded folk can turn it off > >: easily. > > > >Agreed, with both my large system and embedded hats on :-) > > Feature request: If the config is included, stuff it in the minidump ? It's present in minidump. I also added 'kernconf' command to gdbinit.kernel script, so that it's easily obtainable while doing post-mortem analisis with kgdb(1). -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 13:13:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F07016A405; Sun, 1 Apr 2007 13:13:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E2A8713C45B; Sun, 1 Apr 2007 13:13:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l31DDacu001422; Sun, 1 Apr 2007 09:13:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l31DDaii030982; Sun, 1 Apr 2007 09:13:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B556673039; Sun, 1 Apr 2007 09:13:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401131335.B556673039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 09:13:35 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 13:13:37 -0000 TB --- 2007-04-01 11:32:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 11:32:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-04-01 11:32:50 - cleaning the object tree TB --- 2007-04-01 11:33:17 - checking out the source tree TB --- 2007-04-01 11:33:17 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-04-01 11:33:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 11:41:12 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 11:41:12 - cd /src TB --- 2007-04-01 11:41:12 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 11:41:13 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 12:57:37 UTC 2007 TB --- 2007-04-01 12:57:37 - generating LINT kernel config TB --- 2007-04-01 12:57:37 - cd /src/sys/ia64/conf TB --- 2007-04-01 12:57:37 - /usr/bin/make -B LINT TB --- 2007-04-01 12:57:37 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 12:57:37 - cd /src TB --- 2007-04-01 12:57:37 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 12:57:38 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 13:13:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 13:13:35 - ERROR: failed to build lint kernel TB --- 2007-04-01 13:13:35 - tinderbox aborted TB --- 0.62 user 2.02 system 6045.24 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 13:16:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CDA116A409 for ; Sun, 1 Apr 2007 13:16:43 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8DE1C13C458 for ; Sun, 1 Apr 2007 13:16:42 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 01 Apr 2007 13:16:41 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp049) with SMTP; 01 Apr 2007 15:16:41 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX184sM5JrPY4gLLasp1DQ9j9CZ3c6VhnJ7fVvO3C/N mUC7j0dIgyLUHq From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sun, 1 Apr 2007 15:16:38 +0200 User-Agent: KMail/1.9.6 References: <20070331160627.GC5704@obiwan.tataz.chchile.org> <200704011130.10954.shoesoft@gmx.net> In-Reply-To: <200704011130.10954.shoesoft@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704011516.38966.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Jeremie Le Hen Subject: Re: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 13:16:43 -0000 On Sunday 01 April 2007 11:30:10 Stefan Ehmann wrote: > On Saturday 31 March 2007 18:06:27 Jeremie Le Hen wrote: > > Hi, > > > > I've set legal.intel_iwi.license_ack=1 in loader.conf(5) and tried > > to load if_iwi but I get the following message: > > ... > > jarjarbinks:~:105# kldstat | grep iwi > > 5 1 0xc4158000 30000 iwi_bss.ko > > 10 1 0xc4188000 e000 if_iwi.ko > > You need the iwifw module. > > I also stumbled across this. The UPDATING entry should probably mention > this. Oops, overread that iwi_bss.ko is loaded. Please ignore the previous mail. From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 13:35:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45DAA16A402; Sun, 1 Apr 2007 13:35:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1EACC13C483; Sun, 1 Apr 2007 13:35:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l31DZqMG002964; Sun, 1 Apr 2007 09:35:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l31DZqUE044653; Sun, 1 Apr 2007 09:35:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4019373039; Sun, 1 Apr 2007 09:35:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070401133552.4019373039@freebsd-current.sentex.ca> Date: Sun, 1 Apr 2007 09:35:52 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 13:35:53 -0000 TB --- 2007-04-01 12:17:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-01 12:17:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-04-01 12:17:45 - cleaning the object tree TB --- 2007-04-01 12:18:10 - checking out the source tree TB --- 2007-04-01 12:18:10 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-04-01 12:18:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-01 12:25:31 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-01 12:25:31 - cd /src TB --- 2007-04-01 12:25:31 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 1 12:25:32 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 1 13:25:46 UTC 2007 TB --- 2007-04-01 13:25:46 - generating LINT kernel config TB --- 2007-04-01 13:25:46 - cd /src/sys/powerpc/conf TB --- 2007-04-01 13:25:46 - /usr/bin/make -B LINT TB --- 2007-04-01 13:25:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-01 13:25:46 - cd /src TB --- 2007-04-01 13:25:46 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 1 13:25:47 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/debug.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/ktrace.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c: In function `ismrlocked': /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: `curthread' undeclared (first use in this function) /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: (Each undeclared identifier is reported only once /src/sys/gnu/fs/xfs/FreeBSD/support/mrlock.c:12: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-01 13:35:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-01 13:35:51 - ERROR: failed to build lint kernel TB --- 2007-04-01 13:35:51 - tinderbox aborted TB --- 0.52 user 1.78 system 4686.42 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 16:33:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3831016A402; Sun, 1 Apr 2007 16:33:57 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE2313C4B8; Sun, 1 Apr 2007 16:33:56 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh2.centtech.com (8.13.8/8.13.8) with ESMTP id l31GXsAV014314; Sun, 1 Apr 2007 11:33:55 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <460FDEF2.2060203@centtech.com> Date: Sun, 01 Apr 2007 11:33:54 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2987/Sat Mar 31 22:15:28 2007 on mh2.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh2.centtech.com X-Mailman-Approved-At: Sun, 01 Apr 2007 16:36:17 +0000 Cc: Pawel Jakub Dawidek Subject: geom_journal panic: wrong offset 500107860990 for sectorsize 512 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 16:33:57 -0000 After running: gjournal load gjournal label -s 4G /dev/mirror/data I got this panic, and now every time I load geom_journal.ko, the system panics this same way. GEOM_JOURNAL: Journal 4239489025: mirror/data contains data. GEOM_JOURNAL: Journal 4239489025: mirror/data contains journal. GEOM_JOURNAL: Journal mirror/data clean. panic: wrong offset 500107860990 for sectorsize 512 I have a crash dump to look at if needed. Looks something like this: #8 0xc06e0f13 in kdb_enter (msg=0x12
) at cpufunc.h:60 #9 0xc06c2334 in panic (fmt=0xc0943b8b "wrong offset %jd for sectorsize %u") at /usr/src/sys/kern/kern_shutdown.c:547 #10 0xc0685316 in g_io_request (bp=0xc2edaad4, cp=0xc2485140) at /usr/src/sys/geom/geom_io.c:356 #11 0xc0685aae in g_write_data (cp=0xc2485140, offset=Unhandled dwarf expression opcode 0x93) at /usr/src/sys/geom/geom_io.c:643 This is running -CURRENT's latest snapshot (from March). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 17:54:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E118B16A405 for ; Sun, 1 Apr 2007 17:54:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 786C813C45E for ; Sun, 1 Apr 2007 17:54:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.27.128] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HY4Fa0AlS-00067J; Sun, 01 Apr 2007 19:53:58 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sun, 1 Apr 2007 18:53:40 +0100 User-Agent: KMail/1.9.5 References: <20070331160627.GC5704@obiwan.tataz.chchile.org> <200704011130.10954.shoesoft@gmx.net> <200704011516.38966.shoesoft@gmx.net> In-Reply-To: <200704011516.38966.shoesoft@gmx.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1234656.96TmJnITXy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704011953.51090.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19eLVfn4++570GoRfGiDYczGWbVhZlNlR/qlAU nR+iM+yXEpgcYeE3MQoaNVTZtHBsT3iBYWteYSWP8ygGlL0b3h pvuZraO9Tma+b0tzP8nUw== Cc: Jeremie Le Hen , Stefan Ehmann Subject: Re: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 17:54:11 -0000 --nextPart1234656.96TmJnITXy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 01 April 2007 15:16, Stefan Ehmann wrote: > On Sunday 01 April 2007 11:30:10 Stefan Ehmann wrote: > > On Saturday 31 March 2007 18:06:27 Jeremie Le Hen wrote: > > > Hi, > > > > > > I've set legal.intel_iwi.license_ack=3D1 in loader.conf(5) and tried > > > to load if_iwi but I get the following message: > > ... > > > > jarjarbinks:~:105# kldstat | grep iwi > > > 5 1 0xc4158000 30000 iwi_bss.ko > > > 10 1 0xc4188000 e000 if_iwi.ko > > > > You need the iwifw module. > > > > I also stumbled across this. The UPDATING entry should probably > > mention this. > > Oops, overread that iwi_bss.ko is loaded. Please ignore the previous > mail. Good catch nontheless. I updated UPDATING accordingly. Jeremie, can you provide kern.osreldate and a bit more information about=20 your setup? i.e. what's in your loader.conf? There have been some=20 problems with firmware(9) in the past, that should be taken care of by=20 now. Could you try to update to a more recent current? Using the=20 firmware from base shouldn't hurt either. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1234656.96TmJnITXy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGD/GuXyyEoT62BG0RAiUwAJ4vhTN4zrTgbFcxbpk09FQK33fK9QCfTBzR +ZsxfGr57TBYZx7eGofGlOM= =zJ4M -----END PGP SIGNATURE----- --nextPart1234656.96TmJnITXy-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 18:01:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F13F16A421 for ; Sun, 1 Apr 2007 18:01:52 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id F409A13C458 for ; Sun, 1 Apr 2007 18:01:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4AF6A4569A; Sun, 1 Apr 2007 20:01:50 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9558645683; Sun, 1 Apr 2007 20:01:43 +0200 (CEST) Date: Sun, 1 Apr 2007 20:01:25 +0200 From: Pawel Jakub Dawidek To: Eric Anderson Message-ID: <20070401180125.GE25661@garage.freebsd.pl> References: <460FDEF2.2060203@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GLp9dJVi+aaipsRk" Content-Disposition: inline In-Reply-To: <460FDEF2.2060203@centtech.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: geom_journal panic: wrong offset 500107860990 for sectorsize 512 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 18:01:52 -0000 --GLp9dJVi+aaipsRk Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 01, 2007 at 11:33:54AM -0500, Eric Anderson wrote: > After running: >=20 > gjournal load > gjournal label -s 4G /dev/mirror/data >=20 > I got this panic, and now every time I load geom_journal.ko, the system p= anics this same way. >=20 > GEOM_JOURNAL: Journal 4239489025: mirror/data contains data. > GEOM_JOURNAL: Journal 4239489025: mirror/data contains journal. > GEOM_JOURNAL: Journal mirror/data clean. > panic: wrong offset 500107860990 for sectorsize 512 >=20 > I have a crash dump to look at if needed. > Looks something like this: > #8 0xc06e0f13 in kdb_enter (msg=3D0x12
) at = cpufunc.h:60 > #9 0xc06c2334 in panic (fmt=3D0xc0943b8b "wrong offset %jd for sectorsiz= e %u") at /usr/src/sys/kern/kern_shutdown.c:547 > #10 0xc0685316 in g_io_request (bp=3D0xc2edaad4, cp=3D0xc2485140) at /usr= /src/sys/geom/geom_io.c:356 > #11 0xc0685aae in g_write_data (cp=3D0xc2485140, offset=3DUnhandled dwarf= expression opcode 0x93) at /usr/src/sys/geom/geom_io.c:643 >=20 >=20 > This is running -CURRENT's latest snapshot (from March). Could you give me full backtrace? I don't see who calls g_write_data() exactly. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GLp9dJVi+aaipsRk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGD/N1ForvXbEpPzQRAg8WAJ44gte03bNHvca5Lp/Qla9S7HmSDQCg39GT oNwnlq/1/LV2PXxJKVyF6fk= =0SZj -----END PGP SIGNATURE----- --GLp9dJVi+aaipsRk-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 20:03:04 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DFE916A407; Sun, 1 Apr 2007 20:03:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2491313C458; Sun, 1 Apr 2007 20:03:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C17BF46CEB; Sun, 1 Apr 2007 16:03:02 -0400 (EDT) Date: Sun, 1 Apr 2007 16:03:02 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070401155910.O75869@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org Subject: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 20:03:04 -0000 Dear all, The attached patch moves file descriptor locks from being a custom mutex/sleep lock implemented using msleep() to an sx lock. With the new sx lock optimizations in place, this is now sensible, avoiding both a custom lock type and significantly improving performance. Kris has reported 2x-4x improvement in transactions/sec with MySQL using this patch, as it greatly reduces the cost of lock contention during file descriptor lookup for threaded applications, and also moves to shared locking to avoid exclusive acquisition for read-only operations (the vast majority in most workloads). Patch is below, but you can also download from: http://www.watson.org/~robert/freebsd/netperf/20070401a-filedesc-sx.diff I'm currently waiting for the sx lock changes to settle for a few days before committing, so will plan to commit this around Wednesday/Thursday of this week (unless serious problems arise). Robert N M Watson Computer Laboratory University of Cambridge --- //depot/vendor/freebsd/src/sys/compat/linux/linux_file.c 2007/03/29 02:17:34 +++ //depot/user/rwatson/filedesc/src/sys/compat/linux/linux_file.c 2007/04/01 15:10:26 @@ -193,7 +193,7 @@ linux_at(struct thread *td, int dirfd, char *filename, char **newpath, char **freebuf) { struct file *fp; - int error = 0; + int error = 0, vfslocked; struct vnode *dvp; struct filedesc *fdp = td->td_proc->p_fd; char *fullpath = "unknown"; @@ -207,9 +207,10 @@ /* check for AT_FDWCD */ if (dirfd == LINUX_AT_FDCWD) { - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); dvp = fdp->fd_cdir; - FILEDESC_UNLOCK(fdp); + vref(dvp); + FILEDESC_SUNLOCK(fdp); } else { error = fget(td, dirfd, &fp); if (error) @@ -220,16 +221,28 @@ fdrop(fp, td); return (ENOTDIR); } + vref(dvp); fdrop(fp, td); } + /* + * XXXRW: This is bogus, as vn_fullpath() returns only an advisory + * file path, and may fail in several common situations, including + * for file systmes that don't use the name cache, and if the entry + * for the file falls out of the name cache. We should implement + * openat() in the FreeBSD native system call layer properly (using a + * requested starting directory), and have Linux and other ABIs wrap + * the native implementation. + */ error = vn_fullpath(td, dvp, &fullpath, &freepath); if (!error) { *newpath = malloc(strlen(fullpath) + strlen(filename) + 2, M_TEMP, M_WAITOK | M_ZERO); *freebuf = freepath; sprintf(*newpath, "%s/%s", fullpath, filename); } - + vfslocked = VFS_LOCK_GIANT(dvp->v_mount); + vrele(dvp); + VFS_UNLOCK_GIANT(vfslocked); return (error); } --- //depot/vendor/freebsd/src/sys/compat/svr4/svr4_filio.c 2005/01/05 22:36:13 +++ //depot/user/rwatson/filedesc/src/sys/compat/svr4/svr4_filio.c 2007/03/03 22:39:43 @@ -211,15 +211,15 @@ switch (cmd) { case SVR4_FIOCLEX: - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_ofileflags[fd] |= UF_EXCLOSE; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); return 0; case SVR4_FIONCLEX: - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_ofileflags[fd] &= ~UF_EXCLOSE; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); return 0; case SVR4_FIOGETOWN: --- //depot/vendor/freebsd/src/sys/dev/streams/streams.c 2006/07/21 20:40:58 +++ //depot/user/rwatson/filedesc/src/sys/dev/streams/streams.c 2007/03/03 22:39:43 @@ -253,12 +253,15 @@ return error; } - FILEDESC_LOCK_FAST(fdp); + /* + * XXXRW: Should be locking fp? + */ + FILEDESC_XLOCK(fdp); fp->f_data = so; fp->f_flag = FREAD|FWRITE; fp->f_ops = &svr4_netops; fp->f_type = DTYPE_SOCKET; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); /* * Allocate a stream structure and attach it to this socket. --- //depot/vendor/freebsd/src/sys/fs/fdescfs/fdesc_vfsops.c 2006/05/15 19:46:09 +++ //depot/user/rwatson/filedesc/src/sys/fs/fdescfs/fdesc_vfsops.c 2007/03/03 22:39:43 @@ -176,7 +176,7 @@ lim = lim_cur(td->td_proc, RLIMIT_NOFILE); PROC_UNLOCK(td->td_proc); fdp = td->td_proc->p_fd; - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); last = min(fdp->fd_nfiles, lim); freefd = 0; for (i = fdp->fd_freefile; i < last; i++) @@ -189,7 +189,7 @@ */ if (fdp->fd_nfiles < lim) freefd += (lim - fdp->fd_nfiles); - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); sbp->f_flags = 0; sbp->f_bsize = DEV_BSIZE; --- //depot/vendor/freebsd/src/sys/fs/fdescfs/fdesc_vnops.c 2007/03/13 01:54:24 +++ //depot/user/rwatson/filedesc/src/sys/fs/fdescfs/fdesc_vnops.c 2007/03/17 21:03:04 @@ -457,7 +457,7 @@ fcnt = i - 2; /* The first two nodes are `.' and `..' */ - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); while (i < fdp->fd_nfiles + 2 && uio->uio_resid >= UIO_MX) { switch (i) { case 0: /* `.' */ @@ -473,7 +473,7 @@ break; default: if (fdp->fd_ofiles[fcnt] == NULL) { - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); goto done; } @@ -487,15 +487,15 @@ /* * And ship to userland */ - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); error = uiomove(dp, UIO_MX, uio); if (error) goto done; - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); i++; fcnt++; } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); done: uio->uio_offset = i * UIO_MX; --- //depot/vendor/freebsd/src/sys/fs/unionfs/union_subr.c 2007/03/13 01:54:24 +++ //depot/user/rwatson/filedesc/src/sys/fs/unionfs/union_subr.c 2007/03/17 21:03:04 @@ -450,9 +450,9 @@ } break; default: /* UNIONFS_TRADITIONAL */ - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_SLOCK(td->td_proc->p_fd); uva->va_mode = 0777 & ~td->td_proc->p_fd->fd_cmask; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); uva->va_uid = ump->um_uid; uva->va_gid = ump->um_gid; break; --- //depot/vendor/freebsd/src/sys/kern/kern_descrip.c 2007/03/15 21:21:17 +++ //depot/user/rwatson/filedesc/src/sys/kern/kern_descrip.c 2007/04/01 17:49:49 @@ -211,9 +211,11 @@ static void fdused(struct filedesc *fdp, int fd) { - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + + FILEDESC_XLOCK_ASSERT(fdp); KASSERT(!fdisused(fdp, fd), ("fd already used")); + fdp->fd_map[NDSLOT(fd)] |= NDBIT(fd); if (fd > fdp->fd_lastfile) fdp->fd_lastfile = fd; @@ -227,11 +229,13 @@ static void fdunused(struct filedesc *fdp, int fd) { - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + + FILEDESC_XLOCK_ASSERT(fdp); KASSERT(fdisused(fdp, fd), ("fd is already unused")); KASSERT(fdp->fd_ofiles[fd] == NULL, ("fd is still in use")); + fdp->fd_map[NDSLOT(fd)] &= ~NDBIT(fd); if (fd < fdp->fd_freefile) fdp->fd_freefile = fd; @@ -371,10 +375,14 @@ flg = F_POSIX; p = td->td_proc; fdp = p->p_fd; - FILEDESC_LOCK(fdp); + + /* + * XXXRW: It could be an exclusive lock is not [always] needed here. + */ + FILEDESC_XLOCK(fdp); if ((unsigned)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EBADF; goto done2; } @@ -383,7 +391,7 @@ switch (cmd) { case F_DUPFD: /* mtx_assert(&Giant, MA_NOTOWNED); */ - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); newmin = arg; PROC_LOCK(p); if (newmin >= lim_cur(p, RLIMIT_NOFILE) || @@ -399,14 +407,14 @@ case F_GETFD: /* mtx_assert(&Giant, MA_NOTOWNED); */ td->td_retval[0] = (*pop & UF_EXCLOSE) ? FD_CLOEXEC : 0; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); break; case F_SETFD: /* mtx_assert(&Giant, MA_NOTOWNED); */ *pop = (*pop &~ UF_EXCLOSE) | (arg & FD_CLOEXEC ? UF_EXCLOSE : 0); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); break; case F_GETFL: @@ -414,7 +422,7 @@ FILE_LOCK(fp); td->td_retval[0] = OFLAGS(fp->f_flag); FILE_UNLOCK(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); break; case F_SETFL: @@ -424,7 +432,7 @@ fp->f_flag &= ~FCNTLFLAGS; fp->f_flag |= FFLAGS(arg & ~O_ACCMODE) & FCNTLFLAGS; FILE_UNLOCK(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); tmp = fp->f_flag & FNONBLOCK; error = fo_ioctl(fp, FIONBIO, &tmp, td->td_ucred, td); if (error) { @@ -448,7 +456,7 @@ case F_GETOWN: mtx_assert(&Giant, MA_OWNED); fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = fo_ioctl(fp, FIOGETOWN, &tmp, td->td_ucred, td); if (error == 0) td->td_retval[0] = tmp; @@ -458,7 +466,7 @@ case F_SETOWN: mtx_assert(&Giant, MA_OWNED); fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); tmp = arg; error = fo_ioctl(fp, FIOSETOWN, &tmp, td->td_ucred, td); fdrop(fp, td); @@ -472,7 +480,7 @@ case F_SETLK: mtx_assert(&Giant, MA_OWNED); if (fp->f_type != DTYPE_VNODE) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EBADF; break; } @@ -482,7 +490,7 @@ if (fp->f_offset < 0 || (flp->l_start > 0 && fp->f_offset > OFF_MAX - flp->l_start)) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EOVERFLOW; break; } @@ -493,7 +501,7 @@ * VOP_ADVLOCK() may block. */ fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); vp = fp->f_vnode; switch (flp->l_type) { @@ -528,10 +536,10 @@ break; } /* Check for race with close */ - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); if ((unsigned) fd >= fdp->fd_nfiles || fp != fdp->fd_ofiles[fd]) { - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); flp->l_whence = SEEK_SET; flp->l_start = 0; flp->l_len = 0; @@ -539,21 +547,21 @@ (void) VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_UNLCK, flp, F_POSIX); } else - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); fdrop(fp, td); break; case F_GETLK: mtx_assert(&Giant, MA_OWNED); if (fp->f_type != DTYPE_VNODE) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EBADF; break; } flp = (struct flock *)arg; if (flp->l_type != F_RDLCK && flp->l_type != F_WRLCK && flp->l_type != F_UNLCK) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EINVAL; break; } @@ -562,7 +570,7 @@ fp->f_offset > OFF_MAX - flp->l_start) || (flp->l_start < 0 && fp->f_offset < OFF_MIN - flp->l_start)) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EOVERFLOW; break; } @@ -572,14 +580,14 @@ * VOP_ADVLOCK() may block. */ fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); vp = fp->f_vnode; error = VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_GETLK, flp, F_POSIX); fdrop(fp, td); break; default: - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = EINVAL; break; } @@ -593,7 +601,8 @@ * Common code for dup, dup2, and fcntl(F_DUPFD). */ static int -do_dup(struct thread *td, enum dup_type type, int old, int new, register_t *retval) +do_dup(struct thread *td, enum dup_type type, int old, int new, + register_t *retval) { struct filedesc *fdp; struct proc *p; @@ -619,14 +628,14 @@ if (new >= maxfd) return (EMFILE); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); if (old >= fdp->fd_nfiles || fdp->fd_ofiles[old] == NULL) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (EBADF); } if (type == DUP_FIXED && old == new) { *retval = new; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (0); } fp = fdp->fd_ofiles[old]; @@ -646,7 +655,7 @@ fdused(fdp, new); } else { if ((error = fdalloc(td, new, &new)) != 0) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); fdrop(fp, td); return (error); } @@ -661,7 +670,7 @@ /* we've allocated a descriptor which we won't use */ if (fdp->fd_ofiles[new] == NULL) fdunused(fdp, new); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); fdrop(fp, td); return (EBADF); } @@ -708,20 +717,20 @@ knote_fdclose(td, new); if (delfp->f_type == DTYPE_MQUEUE) mq_fdclose(td, new, delfp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); (void) closef(delfp, td); if (holdleaders) { - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_holdleaderscount--; if (fdp->fd_holdleaderscount == 0 && fdp->fd_holdleaderswakeup != 0) { fdp->fd_holdleaderswakeup = 0; wakeup(&fdp->fd_holdleaderscount); } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); } } else { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } return (0); } @@ -979,10 +988,10 @@ AUDIT_SYSCLOSE(td, fd); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); if ((unsigned)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (EBADF); } fdp->fd_ofiles[fd] = NULL; @@ -998,27 +1007,26 @@ } /* - * We now hold the fp reference that used to be owned by the descriptor - * array. - * We have to unlock the FILEDESC *AFTER* knote_fdclose to prevent a - * race of the fd getting opened, a knote added, and deleteing a knote - * for the new fd. + * We now hold the fp reference that used to be owned by the + * descriptor array. We have to unlock the FILEDESC *AFTER* + * knote_fdclose to prevent a race of the fd getting opened, a knote + * added, and deleteing a knote for the new fd. */ knote_fdclose(td, fd); if (fp->f_type == DTYPE_MQUEUE) mq_fdclose(td, fd, fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); error = closef(fp, td); if (holdleaders) { - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_holdleaderscount--; if (fdp->fd_holdleaderscount == 0 && fdp->fd_holdleaderswakeup != 0) { fdp->fd_holdleaderswakeup = 0; wakeup(&fdp->fd_holdleaderscount); } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); } return (error); } @@ -1176,7 +1184,7 @@ int nnfiles, onfiles; NDSLOTTYPE *nmap; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_XLOCK_ASSERT(fdp); KASSERT(fdp->fd_nfiles > 0, ("zero-length file table")); @@ -1189,7 +1197,7 @@ return; /* allocate a new table and (if required) new bitmaps */ - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); MALLOC(ntable, struct file **, nnfiles * OFILESIZE, M_FILEDESC, M_ZERO | M_WAITOK); nfileflags = (char *)&ntable[nnfiles]; @@ -1198,7 +1206,7 @@ M_FILEDESC, M_ZERO | M_WAITOK); else nmap = NULL; - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); /* * We now have new tables ready to go. Since we dropped the @@ -1237,7 +1245,7 @@ struct filedesc *fdp = p->p_fd; int fd = -1, maxfd; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_XLOCK_ASSERT(fdp); if (fdp->fd_freefile > minfd) minfd = fdp->fd_freefile; @@ -1276,8 +1284,8 @@ } /* - * Check to see whether n user file descriptors - * are available to the process p. + * Check to see whether n user file descriptors are available to the process + * p. */ int fdavail(struct thread *td, int n) @@ -1287,7 +1295,7 @@ struct file **fpp; int i, lim, last; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_LOCK_ASSERT(fdp); PROC_LOCK(p); lim = min((int)lim_cur(p, RLIMIT_NOFILE), maxfilesperproc); @@ -1304,12 +1312,11 @@ } /* - * Create a new open file structure and allocate - * a file decriptor for the process that refers to it. - * We add one reference to the file for the descriptor table - * and one reference for resultfp. This is to prevent us being - * preempted and the entry in the descriptor table closed after - * we release the FILEDESC lock. + * Create a new open file structure and allocate a file decriptor for the + * process that refers to it. We add one reference to the file for the + * descriptor table and one reference for resultfp. This is to prevent us + * being preempted and the entry in the descriptor table closed after we + * release the FILEDESC lock. */ int falloc(struct thread *td, struct file **resultfp, int *resultfd) @@ -1350,7 +1357,7 @@ fp->f_ops = &badfileops; fp->f_data = NULL; fp->f_vnode = NULL; - FILEDESC_LOCK(p->p_fd); + FILEDESC_XLOCK(p->p_fd); if ((fq = p->p_fd->fd_ofiles[0])) { LIST_INSERT_AFTER(fq, fp, f_list); } else { @@ -1358,14 +1365,14 @@ } sx_xunlock(&filelist_lock); if ((error = fdalloc(td, 0, &i))) { - FILEDESC_UNLOCK(p->p_fd); + FILEDESC_XUNLOCK(p->p_fd); fdrop(fp, td); if (resultfp) fdrop(fp, td); return (error); } p->p_fd->fd_ofiles[i] = fp; - FILEDESC_UNLOCK(p->p_fd); + FILEDESC_XUNLOCK(p->p_fd); if (resultfp) *resultfp = fp; if (resultfd) @@ -1383,9 +1390,9 @@ struct filedesc0 *newfdp; newfdp = malloc(sizeof *newfdp, M_FILEDESC, M_WAITOK | M_ZERO); - mtx_init(&newfdp->fd_fd.fd_mtx, FILEDESC_LOCK_DESC, NULL, MTX_DEF); + FILEDESC_LOCK_INIT(&newfdp->fd_fd); if (fdp != NULL) { - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); newfdp->fd_fd.fd_cdir = fdp->fd_cdir; if (newfdp->fd_fd.fd_cdir) VREF(newfdp->fd_fd.fd_cdir); @@ -1395,7 +1402,7 @@ newfdp->fd_fd.fd_jdir = fdp->fd_jdir; if (newfdp->fd_fd.fd_jdir) VREF(newfdp->fd_fd.fd_jdir); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } /* Create the file descriptor table. */ @@ -1434,7 +1441,7 @@ if (i > 0) return; - mtx_destroy(&fdp->fd_mtx); + FILEDESC_LOCK_DESTROY(fdp); FREE(fdp, M_FILEDESC); } @@ -1444,9 +1451,10 @@ struct filedesc * fdshare(struct filedesc *fdp) { - FILEDESC_LOCK_FAST(fdp); + + FILEDESC_XLOCK(fdp); fdp->fd_refcnt++; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); return (fdp); } @@ -1457,22 +1465,21 @@ fdunshare(struct proc *p, struct thread *td) { - FILEDESC_LOCK_FAST(p->p_fd); + FILEDESC_XLOCK(p->p_fd); if (p->p_fd->fd_refcnt > 1) { struct filedesc *tmp; - FILEDESC_UNLOCK_FAST(p->p_fd); + FILEDESC_XUNLOCK(p->p_fd); tmp = fdcopy(p->p_fd); fdfree(td); p->p_fd = tmp; } else - FILEDESC_UNLOCK_FAST(p->p_fd); + FILEDESC_XUNLOCK(p->p_fd); } /* - * Copy a filedesc structure. - * A NULL pointer in returns a NULL reference, this is to ease callers, - * not catch errors. + * Copy a filedesc structure. A NULL pointer in returns a NULL reference, + * this is to ease callers, not catch errors. */ struct filedesc * fdcopy(struct filedesc *fdp) @@ -1485,13 +1492,13 @@ return (NULL); newfdp = fdinit(fdp); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); while (fdp->fd_lastfile >= newfdp->fd_nfiles) { - FILEDESC_UNLOCK_FAST(fdp); - FILEDESC_LOCK(newfdp); + FILEDESC_SUNLOCK(fdp); + FILEDESC_XLOCK(newfdp); fdgrowtable(newfdp, fdp->fd_lastfile + 1); - FILEDESC_UNLOCK(newfdp); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XUNLOCK(newfdp); + FILEDESC_SLOCK(fdp); } /* copy everything except kqueue descriptors */ newfdp->fd_freefile = -1; @@ -1507,17 +1514,17 @@ newfdp->fd_freefile = i; } } - FILEDESC_UNLOCK_FAST(fdp); - FILEDESC_LOCK(newfdp); + FILEDESC_SUNLOCK(fdp); + FILEDESC_XLOCK(newfdp); for (i = 0; i <= newfdp->fd_lastfile; ++i) if (newfdp->fd_ofiles[i] != NULL) fdused(newfdp, i); - FILEDESC_UNLOCK(newfdp); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XUNLOCK(newfdp); + FILEDESC_SLOCK(fdp); if (newfdp->fd_freefile == -1) newfdp->fd_freefile = i; newfdp->fd_cmask = fdp->fd_cmask; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); return (newfdp); } @@ -1543,7 +1550,7 @@ /* Check for special need to clear POSIX style locks */ fdtol = td->td_proc->p_fdtol; if (fdtol != NULL) { - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); KASSERT(fdtol->fdl_refcount > 0, ("filedesc_to_refcount botch: fdl_refcount=%d", fdtol->fdl_refcount)); @@ -1557,7 +1564,7 @@ continue; fp = *fpp; fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; @@ -1571,7 +1578,7 @@ &lf, F_POSIX); VFS_UNLOCK_GIANT(locked); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); fdrop(fp, td); fpp = fdp->fd_ofiles + i; } @@ -1585,18 +1592,18 @@ * in a shared file descriptor table. */ fdp->fd_holdleaderswakeup = 1; - msleep(&fdp->fd_holdleaderscount, &fdp->fd_mtx, - PLOCK, "fdlhold", 0); + sx_sleep(&fdp->fd_holdleaderscount, + FILEDESC_LOCK(fdp), PLOCK, "fdlhold", 0); goto retry; } if (fdtol->fdl_holdcount > 0) { /* - * Ensure that fdtol->fdl_leader - * remains valid in closef(). + * Ensure that fdtol->fdl_leader remains + * valid in closef(). */ fdtol->fdl_wakeup = 1; - msleep(fdtol, &fdp->fd_mtx, - PLOCK, "fdlhold", 0); + sx_sleep(fdtol, FILEDESC_LOCK(fdp), PLOCK, + "fdlhold", 0); goto retry; } } @@ -1608,13 +1615,13 @@ } else fdtol = NULL; td->td_proc->p_fdtol = NULL; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); if (fdtol != NULL) FREE(fdtol, M_FILEDESC_TO_LEADER); } - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); i = --fdp->fd_refcnt; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); if (i > 0) return; /* @@ -1626,7 +1633,7 @@ if (*fpp) (void) closef(*fpp, td); } - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); /* XXX This should happen earlier. */ mtx_lock(&fdesc_mtx); @@ -1646,7 +1653,7 @@ fdp->fd_rdir = NULL; jdir = fdp->fd_jdir; fdp->fd_jdir = NULL; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); if (cdir) { locked = VFS_LOCK_GIANT(cdir->v_mount); @@ -1706,7 +1713,7 @@ * Note: fdp->fd_ofiles may be reallocated out from under us while * we are blocked in a close. Be careful! */ - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); for (i = 0; i <= fdp->fd_lastfile; i++) { if (i > 2) break; @@ -1722,35 +1729,33 @@ fdp->fd_ofiles[i] = NULL; fdp->fd_ofileflags[i] = 0; fdunused(fdp, i); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); (void) closef(fp, td); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); } } - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } /* - * If a specific file object occupies a specific file descriptor, - * close the file descriptor entry and drop a reference on the file - * object. This is a convenience function to handle a subsequent - * error in a function that calls falloc() that handles the race that - * another thread might have closed the file descriptor out from under - * the thread creating the file object. + * If a specific file object occupies a specific file descriptor, close the + * file descriptor entry and drop a reference on the file object. This is a + * convenience function to handle a subsequent error in a function that calls + * falloc() that handles the race that another thread might have closed the + * file descriptor out from under the thread creating the file object. */ void fdclose(struct filedesc *fdp, struct file *fp, int idx, struct thread *td) { - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); if (fdp->fd_ofiles[idx] == fp) { fdp->fd_ofiles[idx] = NULL; fdunused(fdp, idx); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); fdrop(fp, td); - } else { - FILEDESC_UNLOCK(fdp); - } + } else + FILEDESC_XUNLOCK(fdp); } /* @@ -1767,7 +1772,7 @@ if (fdp == NULL) return; - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); /* * We cannot cache fd_ofiles or fd_ofileflags since operations @@ -1790,12 +1795,12 @@ fdunused(fdp, i); if (fp->f_type == DTYPE_MQUEUE) mq_fdclose(td, i, fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); (void) closef(fp, td); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); } } - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } /* @@ -1838,14 +1843,15 @@ /* * Someone may have closed the entry in the * file descriptor table, so check it hasn't - * changed before dropping the reference count. + * changed before dropping the reference + * count. */ - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); KASSERT(fdp->fd_ofiles[fd] == fp, ("table not shared, how did it change?")); fdp->fd_ofiles[fd] = NULL; fdunused(fdp, fd); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); fdrop(fp, td); fdrop(fp, td); break; @@ -1873,8 +1879,7 @@ } /* - * Internal form of close. - * Decrement reference count on file structure. + * Internal form of close. Decrement reference count on file structure. * Note: td may be NULL when closing a file that was being passed in a * message. * @@ -1917,11 +1922,11 @@ fdtol = td->td_proc->p_fdtol; if (fdtol != NULL) { /* - * Handle special case where file descriptor table - * is shared between multiple process leaders. + * Handle special case where file descriptor table is + * shared between multiple process leaders. */ fdp = td->td_proc->p_fd; - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); for (fdtol = fdtol->fdl_next; fdtol != td->td_proc->p_fdtol; fdtol = fdtol->fdl_next) { @@ -1929,7 +1934,7 @@ P_ADVLOCK) == 0) continue; fdtol->fdl_holdcount++; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; @@ -1938,7 +1943,7 @@ (void) VOP_ADVLOCK(vp, (caddr_t)fdtol->fdl_leader, F_UNLCK, &lf, F_POSIX); - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); fdtol->fdl_holdcount--; if (fdtol->fdl_holdcount == 0 && fdtol->fdl_wakeup != 0) { @@ -1946,7 +1951,7 @@ wakeup(fdtol); } } - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } VFS_UNLOCK_GIANT(vfslocked); } @@ -1954,21 +1959,21 @@ } /* - * Extract the file pointer associated with the specified descriptor for - * the current user process. + * Extract the file pointer associated with the specified descriptor for the + * current user process. * * If the descriptor doesn't exist, EBADF is returned. * - * If the descriptor exists but doesn't match 'flags' then - * return EBADF for read attempts and EINVAL for write attempts. + * If the descriptor exists but doesn't match 'flags' then return EBADF for + * read attempts and EINVAL for write attempts. * * If 'hold' is set (non-zero) the file's refcount will be bumped on return. - * It should be dropped with fdrop(). - * If it is not set, then the refcount will not be bumped however the - * thread's filedesc struct will be returned locked (for fgetsock). + * It should be dropped with fdrop(). If it is not set, then the refcount + * will not be bumped however the thread's filedesc struct will be returned + * locked (for fgetsock). * - * If an error occured the non-zero error is returned and *fpp is set to NULL. - * Otherwise *fpp is set and zero is returned. + * If an error occured the non-zero error is returned and *fpp is set to + * NULL. Otherwise *fpp is set and zero is returned. */ static __inline int _fget(struct thread *td, int fd, struct file **fpp, int flags, int hold) @@ -1979,9 +1984,9 @@ *fpp = NULL; if (td == NULL || (fdp = td->td_proc->p_fd) == NULL) return (EBADF); - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); if ((fp = fget_locked(fdp, fd)) == NULL || fp->f_ops == &badfileops) { - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (EBADF); } @@ -1991,16 +1996,16 @@ * Only one flag, or 0, may be specified. */ if (flags == FREAD && (fp->f_flag & FREAD) == 0) { - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (EBADF); } if (flags == FWRITE && (fp->f_flag & FWRITE) == 0) { - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (EBADF); } if (hold) { fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); } *fpp = fp; return (0); @@ -2028,9 +2033,9 @@ } /* - * Like fget() but loads the underlying vnode, or returns an error if - * the descriptor does not represent a vnode. Note that pipes use vnodes - * but never have VM objects. The returned vnode will be vref()d. + * Like fget() but loads the underlying vnode, or returns an error if the + * descriptor does not represent a vnode. Note that pipes use vnodes but + * never have VM objects. The returned vnode will be vref()'d. * * XXX: what about the unused flags ? */ @@ -2049,7 +2054,7 @@ *vpp = fp->f_vnode; vref(*vpp); } - FILEDESC_UNLOCK(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); return (error); } @@ -2077,15 +2082,15 @@ #endif /* - * Like fget() but loads the underlying socket, or returns an error if - * the descriptor does not represent a socket. + * Like fget() but loads the underlying socket, or returns an error if the + * descriptor does not represent a socket. * - * We bump the ref count on the returned socket. XXX Also obtain the SX - * lock in the future. + * We bump the ref count on the returned socket. XXX Also obtain the SX lock + * in the future. * * XXXRW: fgetsock() and fputsock() are deprecated, as consumers should rely - * on their file descriptor reference to prevent the socket from being - * freed during use. + * on their file descriptor reference to prevent the socket from being free'd + * during use. */ int fgetsock(struct thread *td, int fd, struct socket **spp, u_int *fflagp) @@ -2110,7 +2115,7 @@ soref(*spp); SOCK_UNLOCK(*spp); } - FILEDESC_UNLOCK(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); return (error); } @@ -2257,22 +2262,20 @@ * of file descriptors, or the fd to be dup'd has already been * closed, then reject. */ - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); if (dfd < 0 || dfd >= fdp->fd_nfiles || (wfp = fdp->fd_ofiles[dfd]) == NULL) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (EBADF); } /* * There are two cases of interest here. * - * For ENODEV simply dup (dfd) to file descriptor - * (indx) and return. + * For ENODEV simply dup (dfd) to file descriptor (indx) and return. * - * For ENXIO steal away the file structure from (dfd) and - * store it in (indx). (dfd) is effectively closed by - * this operation. + * For ENXIO steal away the file structure from (dfd) and store it in + * (indx). (dfd) is effectively closed by this operation. * * Any other error code is just returned. */ @@ -2285,7 +2288,7 @@ FILE_LOCK(wfp); if (((mode & (FREAD|FWRITE)) | wfp->f_flag) != wfp->f_flag) { FILE_UNLOCK(wfp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (EACCES); } fp = fdp->fd_ofiles[indx]; @@ -2295,7 +2298,7 @@ fdused(fdp, indx); fhold_locked(wfp); FILE_UNLOCK(wfp); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); if (fp != NULL) /* * We now own the reference to fp that the ofiles[] @@ -2316,7 +2319,7 @@ fdunused(fdp, dfd); if (fp == NULL) fdused(fdp, indx); - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); /* * We now own the reference to fp that the ofiles[] array @@ -2327,16 +2330,15 @@ return (0); default: - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (error); } /* NOTREACHED */ } /* - * Scan all active processes to see if any of them have a current - * or root directory of `olddp'. If so, replace them with the new - * mount point. + * Scan all active processes to see if any of them have a current or root + * directory of `olddp'. If so, replace them with the new mount point. */ void mountcheckdirs(struct vnode *olddp, struct vnode *newdp) @@ -2353,7 +2355,7 @@ if (fdp == NULL) continue; nrele = 0; - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); if (fdp->fd_cdir == olddp) { vref(newdp); fdp->fd_cdir = newdp; @@ -2364,7 +2366,7 @@ fdp->fd_rdir = newdp; nrele++; } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); fddrop(fdp); while (nrele--) vrele(olddp); @@ -2391,12 +2393,12 @@ fdtol->fdl_wakeup = 0; fdtol->fdl_leader = leader; if (old != NULL) { - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); fdtol->fdl_next = old->fdl_next; fdtol->fdl_prev = old; old->fdl_next = fdtol; fdtol->fdl_next->fdl_prev = fdtol; - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); } else { fdtol->fdl_next = fdtol; fdtol->fdl_prev = fdtol; @@ -2459,7 +2461,7 @@ fdp = fdhold(p); if (fdp == NULL) continue; - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); for (n = 0; fdp->fd_refcnt > 0 && n < fdp->fd_nfiles; ++n) { if ((fp = fdp->fd_ofiles[n]) == NULL) continue; @@ -2476,7 +2478,7 @@ if (error) break; } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); fddrop(fdp); if (error) break; --- //depot/vendor/freebsd/src/sys/kern/kern_event.c 2007/03/04 22:41:05 +++ //depot/user/rwatson/filedesc/src/sys/kern/kern_event.c 2007/03/05 16:48:38 @@ -527,9 +527,9 @@ knlist_init(&kq->kq_sel.si_note, &kq->kq_lock, NULL, NULL, NULL); TASK_INIT(&kq->kq_task, 0, kqueue_task, kq); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); SLIST_INSERT_HEAD(&fdp->fd_kqlist, kq, kq_list); - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); FILE_LOCK(fp); fp->f_flag = FREAD | FWRITE; @@ -1493,9 +1493,9 @@ KQ_UNLOCK(kq); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); SLIST_REMOVE(&fdp->fd_kqlist, kq, kqueue, kq_list); - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); knlist_destroy(&kq->kq_sel.si_note); mtx_destroy(&kq->kq_lock); @@ -1781,9 +1781,9 @@ } /* - * remove all knotes referencing a specified fd - * must be called with FILEDESC lock. This prevents a race where a new fd - * comes along and occupies the entry and we attach a knote to the fd. + * Remove all knotes referencing a specified fd must be called with FILEDESC + * lock. This prevents a race where a new fd comes along and occupies the + * entry and we attach a knote to the fd. */ void knote_fdclose(struct thread *td, int fd) @@ -1793,7 +1793,7 @@ struct knote *kn; int influx; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_XLOCK_ASSERT(fdp); /* * We shouldn't have to worry about new kevents appearing on fd --- //depot/vendor/freebsd/src/sys/kern/kern_fork.c 2007/03/04 22:41:05 +++ //depot/user/rwatson/filedesc/src/sys/kern/kern_fork.c 2007/03/05 16:48:38 @@ -458,9 +458,9 @@ * shared process leaders. */ fdtol = p1->p_fdtol; - FILEDESC_LOCK_FAST(p1->p_fd); + FILEDESC_XLOCK(p1->p_fd); fdtol->fdl_refcount++; - FILEDESC_UNLOCK_FAST(p1->p_fd); + FILEDESC_XUNLOCK(p1->p_fd); } else { /* * Shared file descriptor table, and --- //depot/vendor/freebsd/src/sys/kern/subr_witness.c 2007/04/01 15:52:48 +++ //depot/user/rwatson/filedesc/src/sys/kern/subr_witness.c 2007/04/01 18:01:27 @@ -281,7 +281,6 @@ * Various mutexes */ { "Giant", &lock_class_mtx_sleep }, - { "filedesc structure", &lock_class_mtx_sleep }, { "pipe mutex", &lock_class_mtx_sleep }, { "sigio lock", &lock_class_mtx_sleep }, { "process group", &lock_class_mtx_sleep }, @@ -294,7 +293,6 @@ /* * Sockets */ - { "filedesc structure", &lock_class_mtx_sleep }, { "accept", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, { "so_rcv", &lock_class_mtx_sleep }, --- //depot/vendor/freebsd/src/sys/kern/sys_generic.c 2007/03/05 13:12:17 +++ //depot/user/rwatson/filedesc/src/sys/kern/sys_generic.c 2007/03/05 16:48:38 @@ -568,14 +568,14 @@ fdp = td->td_proc->p_fd; switch (com) { case FIONCLEX: - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_ofileflags[fd] &= ~UF_EXCLOSE; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); goto out; case FIOCLEX: - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); fdp->fd_ofileflags[fd] |= UF_EXCLOSE; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); goto out; case FIONBIO: FILE_LOCK(fp); @@ -658,11 +658,10 @@ return (EINVAL); fdp = td->td_proc->p_fd; - FILEDESC_LOCK_FAST(fdp); - + FILEDESC_SLOCK(fdp); if (nd > td->td_proc->p_fd->fd_nfiles) nd = td->td_proc->p_fd->fd_nfiles; /* forgiving; slightly wrong */ - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); /* * Allocate just enough bits for the non-null fd_sets. Use the @@ -809,7 +808,7 @@ static int flag[3] = { POLLRDNORM, POLLWRNORM, POLLRDBAND }; struct filedesc *fdp = td->td_proc->p_fd; - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); for (msk = 0; msk < 3; msk++) { if (ibits[msk] == NULL) continue; @@ -820,7 +819,7 @@ if (!(bits & 1)) continue; if ((fp = fget_locked(fdp, fd)) == NULL) { - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (EBADF); } if (fo_poll(fp, flag[msk], td->td_ucred, @@ -832,7 +831,7 @@ } } } - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); td->td_retval[0] = n; return (0); } @@ -973,7 +972,7 @@ struct file *fp; int n = 0; - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); for (i = 0; i < nfd; i++, fds++) { if (fds->fd >= fdp->fd_nfiles) { fds->revents = POLLNVAL; @@ -997,7 +996,7 @@ } } } - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); td->td_retval[0] = n; return (0); } --- //depot/vendor/freebsd/src/sys/kern/uipc_mqueue.c 2007/03/13 01:54:24 +++ //depot/user/rwatson/filedesc/src/sys/kern/uipc_mqueue.c 2007/03/17 21:03:04 @@ -2013,10 +2013,10 @@ fp->f_data = pn; FILE_UNLOCK(fp); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); if (fdp->fd_ofiles[fd] == fp) fdp->fd_ofileflags[fd] |= UF_EXCLOSE; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); td->td_retval[0] = fd; fdrop(fp, td); return (0); @@ -2197,14 +2197,14 @@ if (error) return (error); again: - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); if (fget_locked(fdp, uap->mqd) != fp) { - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); error = EBADF; goto out; } mtx_lock(&mq->mq_mutex); - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); if (uap->sigev != NULL) { if (mq->mq_notifier != NULL) { error = EBUSY; @@ -2267,7 +2267,8 @@ struct mqueue *mq; fdp = td->td_proc->p_fd; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_LOCK_ASSERT(fdp); + if (fp->f_ops == &mqueueops) { mq = FPTOMQ(fp); mtx_lock(&mq->mq_mutex); @@ -2295,7 +2296,7 @@ int i; fdp = p->p_fd; - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); for (i = 0; i < fdp->fd_nfiles; ++i) { fp = fget_locked(fdp, i); if (fp != NULL && fp->f_ops == &mqueueops) { @@ -2305,7 +2306,7 @@ mtx_unlock(&mq->mq_mutex); } } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); KASSERT(LIST_EMPTY(&p->p_mqnotifier), ("mq notifiers left")); } --- //depot/vendor/freebsd/src/sys/kern/uipc_syscalls.c 2007/03/05 13:12:17 +++ //depot/user/rwatson/filedesc/src/sys/kern/uipc_syscalls.c 2007/03/05 16:48:38 @@ -124,7 +124,7 @@ if (fdp == NULL) error = EBADF; else { - FILEDESC_LOCK_FAST(fdp); + FILEDESC_SLOCK(fdp); fp = fget_locked(fdp, fd); if (fp == NULL) error = EBADF; @@ -137,7 +137,7 @@ *fflagp = fp->f_flag; error = 0; } - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_SUNLOCK(fdp); } *fpp = fp; return (error); @@ -182,12 +182,17 @@ if (error) { fdclose(fdp, fp, fd, td); } else { - FILEDESC_LOCK_FAST(fdp); + /* + * XXXRW: The logic here seems wrong -- shouldn't it be + * locking the file, not the filedesc? Other threads could + * already have a reference to the socket by now. + */ + FILEDESC_XLOCK(fdp); fp->f_data = so; /* already has ref count */ fp->f_flag = FREAD|FWRITE; fp->f_ops = &socketops; fp->f_type = DTYPE_SOCKET; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); td->td_retval[0] = fd; } fdrop(fp, td); --- //depot/vendor/freebsd/src/sys/kern/uipc_usrreq.c 2007/03/12 14:57:57 +++ //depot/user/rwatson/filedesc/src/sys/kern/uipc_usrreq.c 2007/03/17 21:03:04 @@ -1579,10 +1579,10 @@ unp_freerights(rp, newfds); goto next; } - FILEDESC_LOCK(td->td_proc->p_fd); + FILEDESC_XLOCK(td->td_proc->p_fd); /* if the new FD's will not fit free them. */ if (!fdavail(td, newfds)) { - FILEDESC_UNLOCK(td->td_proc->p_fd); + FILEDESC_XUNLOCK(td->td_proc->p_fd); error = EMSGSIZE; unp_freerights(rp, newfds); goto next; @@ -1597,7 +1597,7 @@ *controlp = sbcreatecontrol(NULL, newlen, SCM_RIGHTS, SOL_SOCKET); if (*controlp == NULL) { - FILEDESC_UNLOCK(td->td_proc->p_fd); + FILEDESC_XUNLOCK(td->td_proc->p_fd); error = E2BIG; unp_freerights(rp, newfds); goto next; @@ -1616,7 +1616,7 @@ unp_rights--; *fdp++ = f; } - FILEDESC_UNLOCK(td->td_proc->p_fd); + FILEDESC_XUNLOCK(td->td_proc->p_fd); } else { /* We can just copy anything else across. */ if (error || controlp == NULL) @@ -1738,23 +1738,24 @@ * files. If not, reject the entire operation. */ fdp = data; - FILEDESC_LOCK(fdescp); + FILEDESC_SLOCK(fdescp); for (i = 0; i < oldfds; i++) { fd = *fdp++; if ((unsigned)fd >= fdescp->fd_nfiles || fdescp->fd_ofiles[fd] == NULL) { - FILEDESC_UNLOCK(fdescp); + FILEDESC_SUNLOCK(fdescp); error = EBADF; goto out; } fp = fdescp->fd_ofiles[fd]; if (!(fp->f_ops->fo_flags & DFLAG_PASSABLE)) { - FILEDESC_UNLOCK(fdescp); + FILEDESC_SUNLOCK(fdescp); error = EOPNOTSUPP; goto out; } } + /* * Now replace the integer FDs with pointers to * the associated global file table entry.. @@ -1763,7 +1764,7 @@ *controlp = sbcreatecontrol(NULL, newlen, SCM_RIGHTS, SOL_SOCKET); if (*controlp == NULL) { - FILEDESC_UNLOCK(fdescp); + FILEDESC_SUNLOCK(fdescp); error = E2BIG; goto out; } @@ -1780,7 +1781,7 @@ FILE_UNLOCK(fp); unp_rights++; } - FILEDESC_UNLOCK(fdescp); + FILEDESC_SUNLOCK(fdescp); break; case SCM_TIMESTAMP: --- //depot/vendor/freebsd/src/sys/kern/vfs_cache.c 2007/03/05 13:12:17 +++ //depot/user/rwatson/filedesc/src/sys/kern/vfs_cache.c 2007/03/05 16:48:38 @@ -717,10 +717,10 @@ tmpbuf = malloc(buflen, M_TEMP, M_WAITOK); fdp = td->td_proc->p_fd; mtx_lock(&Giant); - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); error = vn_fullpath1(td, fdp->fd_cdir, fdp->fd_rdir, tmpbuf, &bp, buflen); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); mtx_unlock(&Giant); if (!error) { @@ -771,9 +771,9 @@ buf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK); fdp = td->td_proc->p_fd; - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); error = vn_fullpath1(td, vn, fdp->fd_rdir, buf, retbuf, MAXPATHLEN); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); if (!error) *freebuf = buf; --- //depot/vendor/freebsd/src/sys/kern/vfs_lookup.c 2007/03/31 16:11:57 +++ //depot/user/rwatson/filedesc/src/sys/kern/vfs_lookup.c 2007/04/01 13:10:13 @@ -188,14 +188,14 @@ /* * Get starting point for the translation. */ - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); ndp->ni_rootdir = fdp->fd_rdir; ndp->ni_topdir = fdp->fd_jdir; dp = fdp->fd_cdir; vfslocked = VFS_LOCK_GIANT(dp->v_mount); VREF(dp); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); for (;;) { /* * Check if root directory should replace current directory. --- //depot/vendor/freebsd/src/sys/kern/vfs_mount.c 2007/04/01 13:12:37 +++ //depot/user/rwatson/filedesc/src/sys/kern/vfs_mount.c 2007/04/01 13:21:17 @@ -1361,7 +1361,7 @@ panic("Cannot find root vnode"); p = td->td_proc; - FILEDESC_LOCK(p->p_fd); + FILEDESC_SLOCK(p->p_fd); if (p->p_fd->fd_cdir != NULL) vrele(p->p_fd->fd_cdir); @@ -1373,7 +1373,7 @@ p->p_fd->fd_rdir = rootvnode; VREF(rootvnode); - FILEDESC_UNLOCK(p->p_fd); + FILEDESC_SUNLOCK(p->p_fd); VOP_UNLOCK(rootvnode, 0, td); } --- //depot/vendor/freebsd/src/sys/kern/vfs_syscalls.c 2007/03/21 19:36:52 +++ //depot/user/rwatson/filedesc/src/sys/kern/vfs_syscalls.c 2007/04/01 13:10:13 @@ -715,10 +715,10 @@ } VOP_UNLOCK(vp, 0, td); VFS_UNLOCK_GIANT(vfslocked); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); vpold = fdp->fd_cdir; fdp->fd_cdir = vp; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); vfslocked = VFS_LOCK_GIANT(vpold->v_mount); vrele(vpold); VFS_UNLOCK_GIANT(vfslocked); @@ -767,10 +767,10 @@ VOP_UNLOCK(nd.ni_vp, 0, td); VFS_UNLOCK_GIANT(vfslocked); NDFREE(&nd, NDF_ONLY_PNBUF); - FILEDESC_LOCK_FAST(fdp); + FILEDESC_XLOCK(fdp); vp = fdp->fd_cdir; fdp->fd_cdir = nd.ni_vp; - FILEDESC_UNLOCK_FAST(fdp); + FILEDESC_XUNLOCK(fdp); vfslocked = VFS_LOCK_GIANT(vp->v_mount); vrele(vp); VFS_UNLOCK_GIANT(vfslocked); @@ -789,7 +789,8 @@ struct file *fp; int fd; - FILEDESC_LOCK_ASSERT(fdp, MA_OWNED); + FILEDESC_LOCK_ASSERT(fdp); + for (fd = 0; fd < fdp->fd_nfiles ; fd++) { fp = fget_locked(fdp, fd); if (fp == NULL) @@ -905,12 +906,12 @@ VFS_ASSERT_GIANT(vp->v_mount); fdp = td->td_proc->p_fd; - FILEDESC_LOCK(fdp); + FILEDESC_XLOCK(fdp); if (chroot_allow_open_directories == 0 || (chroot_allow_open_directories == 1 && fdp->fd_rdir != rootvnode)) { error = chroot_refuse_vdir_fds(fdp); if (error) { - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); return (error); } } @@ -921,7 +922,7 @@ fdp->fd_jdir = vp; VREF(fdp->fd_jdir); } - FILEDESC_UNLOCK(fdp); + FILEDESC_XUNLOCK(fdp); vfslocked = VFS_LOCK_GIANT(oldvp->v_mount); vrele(oldvp); VFS_UNLOCK_GIANT(vfslocked); @@ -1030,18 +1031,18 @@ * * Handle the case where someone closed the file (via its file * descriptor) while we were blocked. The end result should look - * like opening the file succeeded but it was immediately closed. - * We call vn_close() manually because we haven't yet hooked up - * the various 'struct file' fields. + * like opening the file succeeded but it was immediately closed. We + * call vn_close() manually because we haven't yet hooked up the + * various 'struct file' fields. */ - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); FILE_LOCK(fp); if (fp->f_count == 1) { mp = vp->v_mount; KASSERT(fdp->fd_ofiles[indx] != fp, ("Open file descriptor lost all refs")); FILE_UNLOCK(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); VOP_UNLOCK(vp, 0, td); vn_close(vp, flags & FMASK, fp->f_cred, td); VFS_UNLOCK_GIANT(vfslocked); @@ -1058,7 +1059,7 @@ fp->f_seqcount = 1; fp->f_type = (vp->v_type == VFIFO ? DTYPE_FIFO : DTYPE_VNODE); FILE_UNLOCK(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); VOP_UNLOCK(vp, 0, td); if (flags & (O_EXLOCK | O_SHLOCK)) { @@ -1206,10 +1207,10 @@ return (EEXIST); } else { VATTR_NULL(&vattr); - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_SLOCK(td->td_proc->p_fd); vattr.va_mode = (mode & ALLPERMS) & ~td->td_proc->p_fd->fd_cmask; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); vattr.va_rdev = dev; whiteout = 0; @@ -1319,9 +1320,9 @@ } VATTR_NULL(&vattr); vattr.va_type = VFIFO; - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_SLOCK(td->td_proc->p_fd); vattr.va_mode = (mode & ALLPERMS) & ~td->td_proc->p_fd->fd_cmask; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); #ifdef MAC error = mac_check_vnode_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, &vattr); @@ -1534,9 +1535,9 @@ goto restart; } VATTR_NULL(&vattr); - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_SLOCK(td->td_proc->p_fd); vattr.va_mode = ACCESSPERMS &~ td->td_proc->p_fd->fd_cmask; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); #ifdef MAC vattr.va_type = VLNK; error = mac_check_vnode_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, @@ -3418,9 +3419,9 @@ } VATTR_NULL(&vattr); vattr.va_type = VDIR; - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_SLOCK(td->td_proc->p_fd); vattr.va_mode = (mode & ACCESSPERMS) &~ td->td_proc->p_fd->fd_cmask; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_SUNLOCK(td->td_proc->p_fd); #ifdef MAC error = mac_check_vnode_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, &vattr); @@ -3807,11 +3808,11 @@ { register struct filedesc *fdp; - FILEDESC_LOCK_FAST(td->td_proc->p_fd); + FILEDESC_XLOCK(td->td_proc->p_fd); fdp = td->td_proc->p_fd; td->td_retval[0] = fdp->fd_cmask; fdp->fd_cmask = uap->newmask & ALLPERMS; - FILEDESC_UNLOCK_FAST(td->td_proc->p_fd); + FILEDESC_XUNLOCK(td->td_proc->p_fd); return (0); } @@ -3887,7 +3888,7 @@ if (fdp == NULL) error = EBADF; else { - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); if ((u_int)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) error = EBADF; @@ -3898,7 +3899,7 @@ fhold(fp); error = 0; } - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); } *fpp = fp; return (error); --- //depot/vendor/freebsd/src/sys/netsmb/smb_dev.c 2007/02/09 17:22:48 +++ //depot/user/rwatson/filedesc/src/sys/netsmb/smb_dev.c 2007/03/03 22:39:43 @@ -368,15 +368,15 @@ { struct file* fp; - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); if (((u_int)fd) >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL || (fp->f_flag & flag) == 0) { - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (NULL); } fhold(fp); - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); return (fp); } --- //depot/vendor/freebsd/src/sys/security/audit/audit_bsm_klib.c 2006/12/29 12:22:04 +++ //depot/user/rwatson/filedesc/src/sys/security/audit/audit_bsm_klib.c 2007/03/03 22:39:43 @@ -494,7 +494,7 @@ fdp = td->td_proc->p_fd; bufp = path; cisr = 0; - FILEDESC_LOCK(fdp); + FILEDESC_SLOCK(fdp); if (*(path) == '/') { while (*(bufp) == '/') bufp++; /* Skip leading '/'s. */ @@ -516,7 +516,7 @@ vref(vnp); bufp = path; } - FILEDESC_UNLOCK(fdp); + FILEDESC_SUNLOCK(fdp); if (vnp != NULL) { /* * XXX: vn_fullpath() on FreeBSD is "less reliable" than --- //depot/vendor/freebsd/src/sys/sys/filedesc.h 2006/04/07 05:20:46 +++ //depot/user/rwatson/filedesc/src/sys/sys/filedesc.h 2007/04/01 19:46:08 @@ -35,9 +35,9 @@ #include #include +#include #include -#include -#include +#include #include @@ -60,10 +60,7 @@ u_short fd_cmask; /* mask for file creation */ u_short fd_refcnt; /* thread reference count */ u_short fd_holdcnt; /* hold count on structure + mutex */ - - struct mtx fd_mtx; /* protects members of this struct */ - int fd_locked; /* long lock flag */ - int fd_wanted; /* "" */ + struct sx fd_sx; /* protects members of this struct */ struct kqlist fd_kqlist; /* list of kqueues on this filedesc */ int fd_holdleaderscount; /* block fdfree() for shared close() */ int fd_holdleaderswakeup; /* fdfree() needs wakeup */ @@ -96,61 +93,18 @@ #ifdef _KERNEL /* Lock a file descriptor table. */ -#define FILEDESC_LOCK(fd) \ - do { \ - mtx_lock(&(fd)->fd_mtx); \ - (fd)->fd_wanted++; \ - while ((fd)->fd_locked) \ - msleep(&(fd)->fd_locked, &(fd)->fd_mtx, PLOCK, "fdesc", 0); \ - (fd)->fd_locked = 2; \ - (fd)->fd_wanted--; \ - mtx_unlock(&(fd)->fd_mtx); \ - } while (0) +#define FILEDESC_LOCK_INIT(fdp) sx_init(&(fdp)->fd_sx, "filedesc structure") +#define FILEDESC_LOCK_DESTROY(fdp) sx_destroy(&(fdp)->fd_sx) +#define FILEDESC_LOCK(fdp) (&(fdp)->fd_sx) +#define FILEDESC_XLOCK(fdp) sx_xlock(&(fdp)->fd_sx) +#define FILEDESC_XUNLOCK(fdp) sx_xunlock(&(fdp)->fd_sx) +#define FILEDESC_SLOCK(fdp) sx_slock(&(fdp)->fd_sx) +#define FILEDESC_SUNLOCK(fdp) sx_sunlock(&(fdp)->fd_sx) -#define FILEDESC_UNLOCK(fd) \ - do { \ - mtx_lock(&(fd)->fd_mtx); \ - KASSERT((fd)->fd_locked == 2, \ - ("fdesc locking mistake %d should be %d", (fd)->fd_locked, 2)); \ - (fd)->fd_locked = 0; \ - if ((fd)->fd_wanted) \ - wakeup(&(fd)->fd_locked); \ - mtx_unlock(&(fd)->fd_mtx); \ - } while (0) - -#define FILEDESC_LOCK_FAST(fd) \ - do { \ - mtx_lock(&(fd)->fd_mtx); \ - (fd)->fd_wanted++; \ - while ((fd)->fd_locked) \ - msleep(&(fd)->fd_locked, &(fd)->fd_mtx, PLOCK, "fdesc", 0); \ - (fd)->fd_locked = 1; \ - (fd)->fd_wanted--; \ - } while (0) - -#define FILEDESC_UNLOCK_FAST(fd) \ - do { \ - KASSERT((fd)->fd_locked == 1, \ - ("fdesc locking mistake %d should be %d", (fd)->fd_locked, 1)); \ - (fd)->fd_locked = 0; \ - if ((fd)->fd_wanted) \ - wakeup(&(fd)->fd_locked); \ - mtx_unlock(&(fd)->fd_mtx); \ - } while (0) - -#ifdef INVARIANT_SUPPORT -#define FILEDESC_LOCK_ASSERT(fd, arg) \ - do { \ - if ((arg) == MA_OWNED) \ - KASSERT((fd)->fd_locked != 0, ("fdesc locking mistake")); \ - else \ - KASSERT((fd)->fd_locked == 0, ("fdesc locking mistake")); \ - } while (0) -#else -#define FILEDESC_LOCK_ASSERT(fd, arg) -#endif - -#define FILEDESC_LOCK_DESC "filedesc structure" +#define FILEDESC_LOCK_ASSERT(fdp) sx_assert(&(fdp)->fd_sx, SX_LOCKED | \ + SX_NOTRECURSED) +#define FILEDESC_XLOCK_ASSERT(fdp) sx_assert(&(fdp)->fd_sx, SX_XLOCKED | \ + SX_NOTRECURSED) struct thread; From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 20:49:57 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21B9016A403 for ; Sun, 1 Apr 2007 20:49:57 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id AA26D13C46E for ; Sun, 1 Apr 2007 20:49:56 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1437324ugh for ; Sun, 01 Apr 2007 13:49:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition; b=mvkwUQHEZIREr7niyr8K5f01OAf3b5/M5+4tggERI5M6BdmW8YgWYVCHx4dlLD56JmpEAmQTnHVQHDGqe7z3Gfp51CMkXX4M6bFU6gM1I8Jtj74ql3WVuGU1we3GGL2bBrgZkI/3gb7yjWOTI/n7wiOtxnNi9ydRgb53p1SPVJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition; b=Gj1QxQ2Tc82cKusxBKnXQ77MYDpEtIZixaTw23oc1R+/91Ya4rY/tqQTIvV1/YFyG4lgk5CJSeU53YvzgVJc7i/9i7f1tyKNO3oThuLn/yVp5EvZLXhl1KOW9T+AT7F+Gb7bP9AmXYYm2gLxQi0rAnYZf2qvAAbZ/NbaEAvRfnI= Received: by 10.67.115.11 with SMTP id s11mr3739880ugm.1175460595352; Sun, 01 Apr 2007 13:49:55 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.190.94]) by mx.google.com with ESMTP id 53sm6134523ugn.2007.04.01.13.49.52; Sun, 01 Apr 2007 13:49:54 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l31KnhEr002620 for ; Sun, 1 Apr 2007 22:49:43 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l31KnhM0002619 for current@freebsd.org; Sun, 1 Apr 2007 22:49:43 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sun, 1 Apr 2007 22:49:42 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070401204942.GA14445@roadrunner.q.local> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: intsmb fails to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 20:49:57 -0000 Hi, I just upgraded my oldish ASUS P2B machine to current, and noticed intsmb0 failing to attach. It's not that I need it, but perhaps the problem is more wide spread: intsmb0: port 0xe800-0xe80f at device 4.3 on pci0 intsmb0: intr IRQ 9 enabled revision 0 intsmb0: Unsupported interrupt mode device_attach: intsmb0 attach returned 6 intsmb0@pci0:4:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class = bridge Any stuff I should try? There are also some ACPI reservations failing, but as this is an old board, I think this is to be expected: ACPI: RSDP @ 0x0xf7f80/0x0014 (v 0 ASUS ) ACPI: RSDT @ 0x0x13ffd000/0x002C (v 1 ASUS P2B 0x42302E31 MSFT 0x31313031) ACPI: FACP @ 0x0x13ffd080/0x0074 (v 1 ASUS P2B 0x42302E31 MSFT 0x31313031) ACPI: DSDT @ 0x0x13ffd100/0x1BA8 (v 1 ASUS P2B 0x00001000 MSFT 0x01000001) ACPI: FACS @ 0x0x13fff000/0x0040 ACPI: BOOT @ 0x0x13ffd040/0x0028 (v 1 ASUS P2B 0x42302E31 MSFT 0x31313031) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 13f00000 (3) failed Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 01:02:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8695916A401 for ; Mon, 2 Apr 2007 01:02:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3A24F13C458 for ; Mon, 2 Apr 2007 01:02:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so828804nza for ; Sun, 01 Apr 2007 18:02:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=qe0/GHS7gUss8kr7n2VzJdH/xEFUKmn6ZJ669+1wjj2e+XGGqcyWbIp8m2KS/XmfLARfg8xpHp1Vf4YUVsJ2UKmoBnd2lHY4mN/kwbyOqRcCJ6B0HlZfn0rZ7hEgZVdl4TPWZgpt6q+Y/YVrQ8q/NgnWukmqWdJbSPwmrbZIasI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=I4QeE7HffNLnOuDNMX92p9vQAdjZ3hLiEo9COwtXy6diaVghnLsXv/EU7YvkbkEqSrmHC+ptIAyfSPW9j9zJeMZmwrLQiTGvgir879qtehJN6sybcsQMH7yuKZ6Kv5Nows8xOnekidPqE4vAo+Q5gRb+eD8rEkzN5Nx3F1lSpdM= Received: by 10.65.236.14 with SMTP id n14mr8773038qbr.1175475762468; Sun, 01 Apr 2007 18:02:42 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 38sm21451725nza.2007.04.01.18.02.39; Sun, 01 Apr 2007 18:02:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l3212VMh001783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 10:02:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3212ULU001782; Mon, 2 Apr 2007 10:02:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 2 Apr 2007 10:02:30 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070402010230.GA1323@cdnetworks.co.kr> References: <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460E77BE.9090503@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org, Shigeaki Tagashira Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 01:02:43 -0000 On Sat, Mar 31, 2007 at 05:01:18PM +0200, Rainer Hurling wrote: > Thank you Pyun YongHyeon for the newest patch. I am running it with > if_nfe.c and if_nfereg.h from 03/21/2007 and if_nfevar.h from 03/19/2007 > on FreeBSD 7.0-CURRENT (i386) from today. > > boot -v gives me: > nfe0: port 0xb000-0xb007 mem > xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > miibus0: on nfe0 > ciphy0: PHY 1 on miibus0 > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: bpf attached > nfe0: Ethernet address: 00:16:17:95:d9:7c > nfe0: [MPSAFE] > nfe0: [FILTER] > > > Now there are no more warning from miibus0 :-) > Thanks for testing. > Unfortunately at bigger network transfers I still observe the previously > described watchdog timeouts: > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > ... > > During these timeouts I am not able to use my network ;-( > > I would be happy if I could help solving this problem. Let me know if I > can test anything. > Does nfe(4) use shared interrupt with other devices? (Check 'vmstat -i' output.) Since the watchdog timeout error indicates you've had missing Tx completion interrupts I guess you've lost Tx completion interrupts under high systems loads. One of major changes in new nfe(4) was switching to so-called adaptive polling and it is known to give better performance. However it can loose interrupts under high system loads (e.g. buildworld) and I guess there are two ways to fix the issue. 1. Add MSI/MSI-X support. I think this is the cleanest solution to the issue. But old hardwares which has no MSI/MSI-X support and buggy PCI bridges may have issues dealing with MSI/MSI-X. In addition, there is no public documentation available for NVIDIA NICs and lack of MSI/MSI-X capable hardwares make me hard to add MSI/MSI-X support. AFAIK, Shigeaki Tagashira is working on supporting MSI/MSI-X.(CCed) 2. polling(4) Because polling(4) does not rely on timed-delivery of Tx interrupts it would help in your case. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 02:08:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D556416A405 for ; Mon, 2 Apr 2007 02:08:21 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id B524C13C465 for ; Mon, 2 Apr 2007 02:08:21 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3228L4I013327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 1 Apr 2007 19:08:21 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3228Kbi016138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 1 Apr 2007 19:08:20 -0700 Message-ID: <46106567.8060109@u.washington.edu> Date: Sun, 01 Apr 2007 19:07:35 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.1.185535 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Anything (general) needing testing in -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 02:08:21 -0000 Hello all, I got my Core 2 Duo box hooked up with vmware, and I was wondering if there were any general items that needed to be tested in -CURRENT that I could help with. I'd like to run FreeBSD natively but I'm running into some issues with driver support (stupid me for purchasing an ATI card and Creative X-Fi card :(..). -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 04:22:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AF1C16A402 for ; Mon, 2 Apr 2007 04:22:03 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5160413C4B0 for ; Mon, 2 Apr 2007 04:22:03 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l324M2jH048307 for ; Sun, 1 Apr 2007 23:22:02 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461084EA.1000706@freebsd.org> Date: Sun, 01 Apr 2007 23:22:02 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2992/Sun Apr 1 18:20:09 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Subject: pccard flash card reader - no longer works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 04:22:03 -0000 I've been using the same card reader for ages, with various cf cards. Yesterday, I noticed it no longer works. I know it worked around March 3rd-ish. Here's what I get: Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range 0xecb00000-0xecbfffff: good Mar 31 21:10:50 neutrino kernel: pccard0: CIS version PCCARD 2.0 or 2.1 Mar 31 21:10:50 neutrino kernel: pccard0: CIS info: Vendor, CF_Card, Mar 31 21:10:50 neutrino kernel: pccard0: Manufacturer code 0xa, product 0x0 Mar 31 21:10:50 neutrino kernel: pccard0: function 0: fixed disk, ccr addr 200 mask f Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry 0: memory card; irq mask 0; mwait_required rdybsy_active powerdown Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; rdybsy_active io8 io16 irqshare irqpulse irqlevel p owerdown Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; rdybsy_active io8 io16 irqshare irqpuls e irqlevel powerdown Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; rdybsy_active io8 io16 irqshare irqpuls e irqlevel powerdown Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range 0xecb00000-0xecbfffff: good Mar 31 21:10:50 neutrino kernel: ata2: at port 0x910-0x91f irq 19 function 0 config 1 on pccard0 Mar 31 21:10:50 neutrino kernel: ata2: reset tp1 mask=00 ostat0=ff ostat1=00 Mar 31 21:10:50 neutrino kernel: ata2: [MPSAFE] Mar 31 21:10:50 neutrino kernel: ata2: [ITHREAD] Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range 0xecb00000-0xecbfffff: good The flash card works fine if I plug it in via a USB<->CF adapter. Any ideas? Eric From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 06:24:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AC8E16A403 for ; Mon, 2 Apr 2007 06:24:18 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id B111913C458 for ; Mon, 2 Apr 2007 06:24:17 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 450A438250; Mon, 2 Apr 2007 08:24:16 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 733B49B9B0; Mon, 2 Apr 2007 06:24:15 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 562AB405B; Mon, 2 Apr 2007 08:24:15 +0200 (CEST) Date: Mon, 2 Apr 2007 08:24:15 +0200 From: Jeremie Le Hen To: Max Laier Message-ID: <20070402062415.GA5155@obiwan.tataz.chchile.org> References: <20070331160627.GC5704@obiwan.tataz.chchile.org> <200704011130.10954.shoesoft@gmx.net> <200704011516.38966.shoesoft@gmx.net> <200704011953.51090.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704011953.51090.max@love2party.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org, Jeremie Le Hen , Stefan Ehmann Subject: Re: iwi0: could not load boot firmware iwi_bss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 06:24:18 -0000 Hi, Max, On Sun, Apr 01, 2007 at 06:53:40PM +0100, Max Laier wrote: > Good catch nontheless. I updated UPDATING accordingly. > > Jeremie, can you provide kern.osreldate and a bit more information about > your setup? i.e. what's in your loader.conf? There have been some > problems with firmware(9) in the past, that should be taken care of by > now. Could you try to update to a more recent current? Using the > firmware from base shouldn't hurt either. kern.osreldate: 700035 Even better: jarjarbinks:/usr/src:111# cat sys/CVS/Tag D2007.03.31.04.00.00 Do you think it would be worth upgrading ? I saw no relevant commit since yesterday. I've attached my kernel configuration file. It starts from GENERIC and first removes all options/devices I don't need; at the bottom, I add a couple of options and devices I need. /boot/loader.conf: % hw.pci.allow_unsupported_io_range=1 % % hint.acpi.0.disabled="1" % debug.cpufreq.lowest=0 % acpi_dsdt_load="YES" % acpi_dsdt_name="/boot/DSDT.aml" % % beastie_disable="YES" % verbose_loading="YES" % % if_bge_load="YES" % legal.intel_iwi.license_ack=1 Following Florent's advice I began to play with the LKM. I needed to stop devd(8) to workaround the "autoreload" bug. I can then load if_iwi.ko and iwi_bss.ko in _any order_ without any groan from the kernel. However as soon as I start devd(8) or wpa_supplicant(8), the same message appears: % iwi0: timeout waiting for iwi_bss firmware initialization to complete % iwi0: could not load boot firmware iwi_bss Thank you for your help. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:11:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54AFE16A401 for ; Mon, 2 Apr 2007 09:11:44 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id CAF3713C45A for ; Mon, 2 Apr 2007 09:11:43 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from rhea.ceid.upatras.gr (rhea.ceid.upatras.gr [150.140.141.171]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 06A4B5C250B for ; Mon, 2 Apr 2007 11:54:21 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by rhea.ceid.upatras.gr (Postfix) with ESMTP id C594080003 for ; Mon, 2 Apr 2007 11:54:11 +0300 (EEST) Received: from rhea.ceid.upatras.gr ([127.0.0.1]) by localhost (rhea [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27499-04 for ; Mon, 2 Apr 2007 11:54:10 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (diogenis.ceid.upatras.gr [150.140.141.181]) by rhea.ceid.upatras.gr (Postfix) with ESMTP id 319FC80001 for ; Mon, 2 Apr 2007 11:54:09 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 901D3B0128; Mon, 2 Apr 2007 11:54:12 +0300 (EEST) Date: Mon, 2 Apr 2007 11:54:12 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070402085412.GA31689@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ceid.upatras.gr Subject: Thermal Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:11:44 -0000 Hello people, I have a Dell XPS M1210 with Core 2 Duo (T7200) etc and I wonder if the temperatures that my laptop has with FreeBSD are normal .While idling it has about 62.5 C and on heavy load (qemu and compiling) I 've seen about 84.5 C.I feel I can boil an egg on my laptop.I want to mention that with debian I had before I 've never seen so big temperatures. Is there something I can do about that?AFAIK there is nothing I can do to use Intel Speedstep.I tried to use cpufreq module but it doesn't seem to work well. >marinosi@lucifer:~$ sudo kldload cpufreq >Password: >marinosi@lucifer:~$ dmesg | grep -i cpu >CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1997.35-MHz 686-class CPU) >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >cpu0: on acpi0 >acpi_throttle0: on cpu0 >cpu1: on acpi0 >acpi_throttle1: on cpu1 >SMP: AP CPU #1 Launched! >acpi_throttle1: on cpu1 >est0: on cpu0 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6130c2a06000c2a >acpi_throttle1: on cpu1 >est1: on cpu1 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6130c2a06000c2a >est0: on cpu0 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6130c2a06000c2a >p4tcc0: on cpu0 >[...] marinosi@lucifer:~$ sysctl -a | grep temperature hw.acpi.thermal.tz0.temperature: 62.5C Could these temperatures be harmful for the laptop? Thank you all and have a nice day :D Ilias Marinos From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:18:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D9616A402 for ; Mon, 2 Apr 2007 09:18:14 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC9B13C43E for ; Mon, 2 Apr 2007 09:18:14 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=l1YEHVpDBOdm8U5elZiiwDh8cmpb5riZ5qLWY6Uet1IVGogaqWEShtt22DuHuEdckUlwiPHQfk9Qzlq3Us6egHnStQkkTUvrQLa3mFWedjFxth1sTV/VnSC2FhgvJ8j1NLkSTgN3SU/m+iJ4kK8G/JZiXwFi2oVxeNtQQ5sCr+LEJt7RpvDc5RlLaPb9jgGrF7yswYjwS192Bhh1d0T5+dFyZgIr2pTWMfMdY1CS8gJnvUhmaOYSG0NYjfrPIvyd; Received: from uucp by munchkin.clue.co.za with local (Exim 4.66) (envelope-from ) id 1HYIg1-0001xn-TM; Mon, 02 Apr 2007 09:18:13 +0000 Received: from cluetoy.clue.co.za ([10.0.0.19] helo=clue.co.za) by urchin.clue.co.za with esmtpa (Exim 4.66) (envelope-from ) id 1HYIfJ-0007cm-1e; Mon, 02 Apr 2007 09:17:29 +0000 Received: from localhost ([127.0.0.1]) by clue.co.za with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HYIfJ-0000jM-1y; Mon, 02 Apr 2007 11:17:29 +0200 To: Andrew Thompson , freebsd-current@freebsd.org From: Ian FREISLICH In-Reply-To: Message from Andrew Thompson of "Fri, 30 Mar 2007 13:13:54 +1200." <20070330011354.GE97061@heff.fud.org.nz> X-Attribution: BOFH Date: Mon, 02 Apr 2007 11:17:29 +0200 Message-Id: Cc: Subject: Re: CFT: new trunk(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:18:14 -0000 Andrew Thompson wrote: > Here is a patch to add OpenBSD's trunk(4) interface, and also includes > LACP support which came from agr(4) on NetBSD. Im interested in anyone > who wants to test this and in particular lacp mode if you have a switch > that supports it. > > http://people.freebsd.org/~thompsa/if_trunk-20070330b.diff This looks very interesting. I'm busy testing with a switch that claims 802.3ad support. We're making extensive use of vlans to increase the number of interfaces availabble to us using switches to break out gigE into 100M interfaces. The bandwidth problem we're having is to our provider, a 100M connection, and we're looking at doing exactly this. However, it appears that this interface can't trunk vlan interfaces. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:19:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6988616A40A for ; Mon, 2 Apr 2007 09:19:27 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id D822A13C4B8 for ; Mon, 2 Apr 2007 09:19:26 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from rhea.ceid.upatras.gr (rhea.ceid.upatras.gr [150.140.141.171]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 4AB315C247B; Mon, 2 Apr 2007 12:19:35 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by rhea.ceid.upatras.gr (Postfix) with ESMTP id 0035280003; Mon, 2 Apr 2007 12:19:25 +0300 (EEST) Received: from rhea.ceid.upatras.gr ([127.0.0.1]) by localhost (rhea [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32546-09; Mon, 2 Apr 2007 12:19:24 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (diogenis.ceid.upatras.gr [150.140.141.181]) by rhea.ceid.upatras.gr (Postfix) with ESMTP id 33DD480001; Mon, 2 Apr 2007 12:19:24 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 10E97B0128; Mon, 2 Apr 2007 12:19:27 +0300 (EEST) Date: Mon, 2 Apr 2007 12:19:27 +0300 From: Marinos Ilias To: Takanori Watanabe Message-ID: <20070402091927.GA729@ceid.upatras.gr> References: <20070402085412.GA31689@ceid.upatras.gr> <200704020902.l3292net008721@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704020902.l3292net008721@sana.init-main.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ceid.upatras.gr Cc: freebsd-current@freebsd.org Subject: Re: Thermal Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:19:27 -0000 Hello again, marinosi@lucifer:~$ sysctl -a | grep CRT hw.acpi.thermal.tz0._CRT: 126.0C But it sounds huge!126C?It will melt. Ilias From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:24:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 894F816A401 for ; Mon, 2 Apr 2007 09:24:25 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4743713C469 for ; Mon, 2 Apr 2007 09:24:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HYIlq-0005du-7z for freebsd-current@freebsd.org; Mon, 02 Apr 2007 11:24:14 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2007 11:24:14 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Apr 2007 11:24:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 02 Apr 2007 11:23:54 +0200 Lines: 36 Message-ID: References: <20070402085412.GA31689@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB48CFDE31CE1935F8F8C923F" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070402085412.GA31689@ceid.upatras.gr> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: Thermal Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:24:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB48CFDE31CE1935F8F8C923F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Marinos Ilias wrote: > Hello people, > I have a Dell XPS M1210 with Core 2 Duo (T7200) etc and I wonder if the= temperatures that my laptop has with FreeBSD are normal .While idling it= has about 62.5 C and on heavy load (qemu and compiling) I 've seen about= 84.5 C.I feel I can boil an egg on my laptop.I want to mention that with= debian I had before I 've never seen so big temperatures. Unless you measured the temperature with the computer's BIOS (e.g. by=20 looking at the BIOS's screen about thermal data), don't trust the values = too much. Also, try running powerd. --------------enigB48CFDE31CE1935F8F8C923F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGEMuqldnAQVacBcgRAnIJAJ9I5twlGeQnq/ut/H957/I2OHNyqQCgmA6d VVg8xnCQW2Ag32zSQk1ojRY= =RvT/ -----END PGP SIGNATURE----- --------------enigB48CFDE31CE1935F8F8C923F-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:28:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E85416A401 for ; Mon, 2 Apr 2007 09:28:32 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2D57013C457 for ; Mon, 2 Apr 2007 09:28:32 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 93C351CC58; Mon, 2 Apr 2007 21:28:30 +1200 (NZST) Date: Mon, 2 Apr 2007 21:28:30 +1200 From: Andrew Thompson To: Ian FREISLICH Message-ID: <20070402092830.GB28809@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Ian FREISLICH , freebsd-current@freebsd.org References: <20070330011354.GE97061@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: CFT: new trunk(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:28:32 -0000 On Mon, Apr 02, 2007 at 11:17:29AM +0200, Ian FREISLICH wrote: > Andrew Thompson wrote: > > Here is a patch to add OpenBSD's trunk(4) interface, and also includes > > LACP support which came from agr(4) on NetBSD. Im interested in anyone > > who wants to test this and in particular lacp mode if you have a switch > > that supports it. > > > > http://people.freebsd.org/~thompsa/if_trunk-20070330b.diff > > This looks very interesting. I'm busy testing with a switch that > claims 802.3ad support. > > We're making extensive use of vlans to increase the number of > interfaces availabble to us using switches to break out gigE into > 100M interfaces. The bandwidth problem we're having is to our > provider, a 100M connection, and we're looking at doing exactly > this. However, it appears that this interface can't trunk vlan > interfaces. It sounds like you want it the other way around. The trunk should be the lowest component in any setup so you should vlan the trunk interface rather than trunk a vlan. ifconfig trunk0 create ... ifconfig vlan0 vlan 10 vlandev trunk0 (or use ifconfig trunk0.10 create which is a better syntax) regards, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:58:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 489B916A405 for ; Mon, 2 Apr 2007 09:58:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B047E13C483 for ; Mon, 2 Apr 2007 09:58:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 8424 invoked from network); 2 Apr 2007 08:58:10 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Apr 2007 08:58:10 -0000 Message-ID: <4610CD68.2060706@freebsd.org> Date: Mon, 02 Apr 2007 11:31:20 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Barrett Lyon References: <20070401005604.051A473039@freebsd-current.sentex.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: TCP sessions hanging in FIN_WAIT_1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:58:04 -0000 Barrett Lyon wrote: > I've been testing CURRENT for a bit and with a thousands of short lived > HTTP sessions, CURRENT hangs most of the sessions in FIN_WAIT_1 status > until the machine runs out of resources and causes the network stack to > stop performing. The HTTP daemon I am playing with is lighttpd-1.4.13, > and I don't see this happening on any of the 6.2 test machines I run. > > There's nothing unusual about the build other than the interface card > running the mxge driver. Has anyone else seen reports of this? I have > seen this behavior on all source up to today's tree. Are you running a pure GENERIC kernel or do you have any other modifications? What about firewall packages (ipfw, pf, ipfilter)? -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 09:59:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE02F16A409; Mon, 2 Apr 2007 09:59:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4D14B13C483; Mon, 2 Apr 2007 09:59:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.191.69] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HYJJZ3uCB-0001La; Mon, 02 Apr 2007 11:59:06 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Mon, 2 Apr 2007 10:58:55 +0100 User-Agent: KMail/1.9.5 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX1/hLp09xaC++YinlYJV80IiKfp5IDKgMCbf8TG 4P5imQ4cpRGsV8+A3ZxReWKAVMkoO8V2XVQ1KXcljI4yX1dryP CNJld8EukiZbVJ53psJQw== Cc: freebsd-current@freebsd.org Subject: FreeBSD Status Reports due Saturday (04/07) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 09:59:26 -0000 --nextPart2063530.WJYOiiugub Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, quick note from the "better late than never"-department. This is a=20 reminder that we collect status reports every three months. The reports=20 for the first three month (January - Now) are due by Saturday, April 7. =20 We are looking for anything FreeBSD related: Code, Advocacy, Vendor=20 reports, Community activities ... =2E.. on that note, I'd like to remind you that BSDCan in Ottawa is coming= =20 up 16-19 May. http://www.bsdcan.org/ for more information - see you=20 there! Please use the xml generator[1] or the template[2] and send your report to= =20 monthly@ by Saturday. Thanks, looking forward to your reports. [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2063530.WJYOiiugub Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGENPoXyyEoT62BG0RAnI2AJ9DpLZCqq3AlNQHATJkoyGZ1axNVgCeN4pc Bh+bfnjLWURihjJtbFT5fck= =0OAf -----END PGP SIGNATURE----- --nextPart2063530.WJYOiiugub-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 10:20:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED70416A402 for ; Mon, 2 Apr 2007 10:20:56 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7905913C457 for ; Mon, 2 Apr 2007 10:20:56 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 2E1442B970B for ; Mon, 2 Apr 2007 11:20:53 +0100 (BST) Received: (qmail 42751 invoked by uid 2223); 2 Apr 2007 10:20:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2007 10:20:54 -0000 Date: Mon, 2 Apr 2007 11:20:54 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: freebsd-current@freebsd.org Message-ID: <20070402111110.E36340@nux.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 02 Apr 2007 11:16:54 +0000 Subject: zfs + ggate testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 10:20:57 -0000 Hi, I have continued to test zfs and ggated and have managed to panic the machine a few times i have a number of saved vmcores however i am not too familiar with kgdb but from following the handbook i have produced a backtrace - please let me know if there is any other info i can provide or if there is any testing i can do. Before any panics i am getting a lot of message on the console like: zfs_lowmem:2681[0]: 2596 ENTER zfs_lowmem:2686[0]: 2596 EXIT zfs_lowmem:2681[0]: 2593 ENTER zfs_lowmem:2686[0]: 2593 EXIT zfs_lowmem:2681[0]: 2598 ENTER zfs_lowmem:2686[0]: 2598 EXIT zfs_lowmem:2681[0]: 2598 ENTER zfs_lowmem:2686[0]: 2598 EXIT f7# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined s GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0686bda stack pointer = 0x28:0xe6572b28 frame pointer = 0x28:0xe6572b3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1085 (solthread 0xc41f633) panic: from debugger cpuid = 0 Uptime: 7m15s Physical memory: 999 MB Dumping 58 MB: 43 27 11 #0 doadump () at pcpu.h:147 147 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list 0xc0686bda Function "0xc0686bda" not defined. (kgdb) list *0xc0686bda 0xc0686bda is in g_io_request (/usr/src/sys/geom/geom_io.c:364). 359 KASSERT(bp->bio_length % cp->provider->sectorsize == 0, 360 ("wrong length %jd for sectorsize %u", 361 bp->bio_length, cp->provider->sectorsize)); 362 } 363 364 g_trace(G_T_BIO, "bio_request(%p) from %p(%s) to %p(%s) cmd %d", 365 bp, cp, cp->geom->name, pp, pp->name, bp->bio_cmd); 366 367 bp->bio_from = cp; 368 bp->bio_to = pp; (kgdb) backtrace #0 doadump () at pcpu.h:147 #1 0xc06c6232 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06c6573 in panic (fmt=0xc091a5f6 "from debugger") at /usr/src/sys/kern/kern_shut #3 0xc0476b8a in db_panic (addr=-1066898470, have_addr=0, count=-1, modif=0xe65728f8 " #4 0xc0476b23 in db_command (last_cmdp=0xc0a23dc4, cmd_table=0x0) at /usr/src/sys/ddb/ #5 0xc0476bde in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #6 0xc0478835 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc06e5ebc in kdb_trap (type=12, code=0, tf=0xe6572ae8) at /usr/src/sys/kern/subr_k #8 0xc08d3bdd in trap_fatal (frame=0xe6572ae8, eva=0) at /usr/src/sys/i386/i386/trap.c #9 0xc08d3917 in trap_pfault (frame=0xe6572ae8, usermode=0, eva=0) at /usr/src/sys/i38 #10 0xc08d3502 in trap (frame=0xe6572ae8) at /usr/src/sys/i386/i386/trap.c:462 #11 0xc08bd23b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0xc0686bda in g_io_request (bp=0xc411739c, cp=0xc4111540) at /usr/src/sys/geom/geom #13 0xc4227cd2 in ?? () #14 0xc411739c in ?? () #15 0xc4111540 in ?? () #16 0xc3c0e000 in ?? () #17 0xc400c800 in ?? () #18 0xc44f0400 in ?? () #19 0xe6572b64 in ?? () #20 0xc41fe46f in ?? () #21 0xc44f0400 in ?? () #22 0xe6572b84 in ?? () #23 0xc42129d8 in ?? () #24 0xc44f0400 in ?? () #25 0x00000200 in ?? () ---Type to continue, or q to quit--- #26 0x00000000 in ?? () #27 0xc44f0400 in ?? () #28 0xc44f2400 in ?? () #29 0xc44f0400 in ?? () #30 0xe6572b94 in ?? () #31 0xc4212e66 in ?? () #32 0xc44f0400 in ?? () #33 0xc44f0400 in ?? () #34 0xe6572ba8 in ?? () #35 0xc421159e in ?? () #36 0xc44f0400 in ?? () #37 0xc44f0400 in ?? () #38 0xc44f0600 in ?? () #39 0xe6572bb8 in ?? () #40 0xc4212e66 in ?? () #41 0xc44f0400 in ?? () #42 0xc44f05ec in ?? () #43 0xe6572bd0 in ?? () #44 0xc4211443 in ?? () #45 0xc44f0400 in ?? () #46 0xc44f0400 in ?? () #47 0x00000000 in ?? () #48 0xc4599000 in ?? () #49 0xe6572be4 in ?? () #50 0xc421152d in ?? () #51 0xc44f0400 in ?? () ---Type to continue, or q to quit--- #52 0x00000001 in ?? () #53 0xc44f05ec in ?? () #54 0xe6572bf4 in ?? () #55 0xc4212f12 in ?? () #56 0xc44f0400 in ?? () #57 0xc3c0e000 in ?? () #58 0xe6572c00 in ?? () #59 0xc42113ff in ?? () #60 0xc44f0400 in ?? () #61 0xe6572c10 in ?? () #62 0xc41ffb5a in ?? () #63 0xc44f0400 in ?? () #64 0xc44f2400 in ?? () #65 0xe6572c64 in ?? () #66 0xc42001b4 in ?? () #67 0xc44f2400 in ?? () #68 0xc3c0e000 in ?? () #69 0x00000000 in ?? () #70 0xc4599000 in ?? () #71 0x00004000 in ?? () #72 0x00000000 in ?? () #73 0x0001c000 in ?? () #74 0x00000000 in ?? () #75 0x00000000 in ?? () #76 0x00000000 in ?? () #77 0xc3fef800 in ?? () ---Type to continue, or q to quit--- #78 0x00000000 in ?? () #79 0x00000000 in ?? () #80 0x00000805 in ?? () #81 0xc3fef800 in ?? () #82 0x00000000 in ?? () #83 0x00000000 in ?? () #84 0xc3c0e000 in ?? () #85 0xc3fef800 in ?? () #86 0xe6572c8c in ?? () #87 0xc41fd852 in ?? () #88 0xc3c0e000 in ?? () #89 0x00000000 in ?? () #90 0x00000000 in ?? () #91 0xe6572cb8 in ?? () #92 0xc41fd7b9 in ?? () #93 0x00000000 in ?? () #94 0xc400c800 in ?? () #95 0xc3fef800 in ?? () #96 0xe6572cb4 in ?? () #97 0xc41fd813 in ?? () #98 0xc3c0e000 in ?? () #99 0xc400c800 in ?? () #100 0x37040000 in ?? () #101 0x00000001 in ?? () #102 0x00000009 in ?? () #103 0xc400c800 in ?? () ---Type to continue, or q to quit--- #104 0xc3fef800 in ?? () #105 0xc3fef800 in ?? () #106 0xe6572cd0 in ?? () #107 0xc41fda25 in ?? () #108 0xc400c800 in ?? () #109 0xc400c800 in ?? () #110 0xc400c800 in ?? () #111 0xc3eee800 in ?? () #112 0x00000000 in ?? () #113 0xe6572ce8 in ?? () #114 0xc41f630c in ?? () #115 0xc400c800 in ?? () #116 0xc3fefbb0 in ?? () #117 0xc3fef800 in ?? () #118 0x00000001 in ?? () #119 0xe6572d00 in ?? () #120 0xc41f63be in ?? () #121 0xc3fef800 in ?? () #122 0xc3fef800 in ?? () #123 0xc41f6334 in ?? () #124 0x00000000 in ?? () #125 0xe6572d24 in ?? () #126 0xc06af7d3 in fork_exit (callout=0xc44f0400, arg=0xe6572b84, frame=0xc42129d8) at Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 14:50:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26AAB16A401 for ; Mon, 2 Apr 2007 14:50:22 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.freebsd.org (Postfix) with ESMTP id A589B13C459 for ; Mon, 2 Apr 2007 14:50:21 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from koala.unime.lan (87.18.101.132) by vsmtp4.tin.it (7.2.072.1) id 460BC759004CAEA1 for freebsd-current@freebsd.org; Mon, 2 Apr 2007 16:38:47 +0200 Received: from koala.unime.lan (localhost [127.0.0.1]) by koala.unime.lan (8.13.8/8.13.8) with ESMTP id l32EZcSJ006263 for ; Mon, 2 Apr 2007 16:35:38 +0200 (CEST) (envelope-from yal@yal.hopto.org) Received: (from www@localhost) by koala.unime.lan (8.13.8/8.13.8/Submit) id l32EZb32006262; Mon, 2 Apr 2007 16:35:37 +0200 (CEST) (envelope-from yal@yal.hopto.org) X-Authentication-Warning: koala.unime.lan: www set sender to yal@yal.hopto.org using -f Received: from 87.18.101.132 (SquirrelMail authenticated user yal) by yal.hopto.org with HTTP; Mon, 2 Apr 2007 16:35:36 +0200 (CEST) Message-ID: <3763.87.18.101.132.1175524536.squirrel@yal.hopto.org> Date: Mon, 2 Apr 2007 16:35:36 +0200 (CEST) From: "yal" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yal@yal.hopto.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 14:50:22 -0000 Hi, Are there any schedules for a new official driver for the Intel 3945? I've been unable to run the old beta wpi driver on -CURRENT for weeks now! From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 15:11:41 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 913AC16A404 for ; Mon, 2 Apr 2007 15:11:41 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from util2.sjc1.bitgravity.com (util2.sjc1.bitgravity.com [208.67.233.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7F06713C457 for ; Mon, 2 Apr 2007 15:11:41 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from c-69-181-166-240.hsd1.ca.comcast.net ([69.181.166.240] helo=[192.168.1.197]) by util2.sjc1.bitgravity.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYOCQ-0006f5-1D; Mon, 02 Apr 2007 08:12:02 -0700 In-Reply-To: <4610CD68.2060706@freebsd.org> References: <20070401005604.051A473039@freebsd-current.sentex.ca> <4610CD68.2060706@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Barrett Lyon Date: Mon, 2 Apr 2007 08:11:39 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org Subject: Re: TCP sessions hanging in FIN_WAIT_1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 15:11:41 -0000 Generic kernel, I had some stuff in there related to the http accept filter but I removed all that when I noticed the problem. I moved the traffic over to if_em for testing and the problem went away, when I brought it back to mxge the FIN_WAIT_1 issue came back. This was without rebooting or changing anything other than the interface. -Barrett On Apr 2, 2007, at 2:31 AM, Andre Oppermann wrote: > Barrett Lyon wrote: >> I've been testing CURRENT for a bit and with a thousands of short >> lived HTTP sessions, CURRENT hangs most of the sessions in >> FIN_WAIT_1 status until the machine runs out of resources and >> causes the network stack to stop performing. The HTTP daemon I >> am playing with is lighttpd-1.4.13, and I don't see this >> happening on any of the 6.2 test machines I run. >> There's nothing unusual about the build other than the interface >> card running the mxge driver. Has anyone else seen reports of >> this? I have seen this behavior on all source up to today's tree. > > Are you running a pure GENERIC kernel or do you have any other > modifications? > What about firewall packages (ipfw, pf, ipfilter)? > > -- > Andre > From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 15:43:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 951CF16A408 for ; Mon, 2 Apr 2007 15:43:27 +0000 (UTC) (envelope-from faber@ISI.EDU) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.freebsd.org (Postfix) with ESMTP id 608B113C48C for ; Mon, 2 Apr 2007 15:43:27 +0000 (UTC) (envelope-from faber@ISI.EDU) Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l32FXLs2007507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Apr 2007 08:33:21 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l32FXLSH098835 for current@freebsd.org; Mon, 2 Apr 2007 08:33:21 -0700 (PDT) (envelope-from faber) Date: Mon, 2 Apr 2007 08:33:21 -0700 From: Ted Faber To: current@freebsd.org Message-ID: <20070402153321.GC97955@hut.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jousvV0MzM2p6OtC" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu Cc: Subject: Clock setting bug on current/i386 (patch available) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 15:43:27 -0000 --jousvV0MzM2p6OtC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I had a sort of wierd bug with the code in sys/i386/isa/clock.c that sets the kernel clock from the realtime clock. The short story is in=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D111117 The longer story is that my EPIA ME6000 clock seems to have the day of the week wrong in its real time clock (RTC) and no way to adjust that value. This shouldn't be a big deal, but the code that converts from the RTC to seconds (clock_ct_to_ts() in sys/kern/subr_clock.c) checks the day of the week value - unless it's set to -1 - though it isn't used in the conversion. That code fails with an error if the day of the week is wrong. The i386 clock-setting code doesn't check this return value and the kernel time is set to whatever lucky value was on the stack when the function was called. There is much odd behavior on a box that thinks that the year is 1937. newsyslog fails to parse configuration files, for example... The PR has a few line patch to call clock_ct_to_ts() again with the day of the week set to -1 if the function fails and the day of the week wasn't -1. It prints some diagnostics to let a user know their clock isn't set should none of that work. Feel free to clip the diagnostics, but they would have saved me some time. :-) It's a short patch. I'm sending this mail in the hope that some committer will pop it in as an easy Monday morning thing. Thanks! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --jousvV0MzM2p6OtC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGESJBaUz3f+Zf+XsRAoa0AJ0RCyIr7swIQW2G72RzQeFXtCdDxACggd19 lVNlNRZw6ICIsHY6AwTjQZ8= =lfEN -----END PGP SIGNATURE----- --jousvV0MzM2p6OtC-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 17:08:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5726116A401 for ; Mon, 2 Apr 2007 17:08:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id E3A6A13C45A for ; Mon, 2 Apr 2007 17:08:12 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C8E2845684; Mon, 2 Apr 2007 19:08:10 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4E59845681; Mon, 2 Apr 2007 19:08:00 +0200 (CEST) Date: Mon, 2 Apr 2007 19:07:50 +0200 From: Pawel Jakub Dawidek To: Mike Wolman Message-ID: <20070402170750.GD34180@garage.freebsd.pl> References: <20070329174620.Q90308@nux.eros.office> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P+33d92oIH25kiaB" Content-Disposition: inline In-Reply-To: <20070329174620.Q90308@nux.eros.office> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: ggated, gmirror + zfs panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 17:08:13 -0000 --P+33d92oIH25kiaB Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 05:47:01PM +0100, Mike Wolman wrote: > Hi, >=20 > I am experimenting with ggate, gmirror and zfs to create a redundant file= system using 2 machines. >=20 > I currently do not have 10 spare drives so i have been using md devices t= o test the setup with. >=20 > If I run through the below commands i am able to crash the machine every = time. I have a vmcore available but think this should be easy to reproduce. I'm able to reproduce it. Give me some time to track it down. > # dd if=3D/dev/zero of=3D/home/mike-play/file0 bs=3D1k count=3D1000k > # dd if=3D/dev/zero of=3D/home/mike-play/file1 bs=3D1k count=3D1000k > # dd if=3D/dev/zero of=3D/home/mike-play/file2 bs=3D1k count=3D1000k > # dd if=3D/dev/zero of=3D/home/mike-play/file3 bs=3D1k count=3D1000k > # dd if=3D/dev/zero of=3D/home/mike-play/file4 bs=3D1k count=3D1000k >=20 > # mdconfig -a -t vnode -f /home/mike-play/file0 -u 0 > # mdconfig -a -t vnode -f /home/mike-play/file1 -u 1 > # mdconfig -a -t vnode -f /home/mike-play/file2 -u 2 > # mdconfig -a -t vnode -f /home/mike-play/file3 -u 3 > # mdconfig -a -t vnode -f /home/mike-play/file4 -u 4 >=20 > edit /etc/gg.exports >=20 > 192.168.5.0/24 RW /dev/md0 > 192.168.5.0/24 RW /dev/md1 > 192.168.5.0/24 RW /dev/md2 > 192.168.5.0/24 RW /dev/md3 > 192.168.5.0/24 RW /dev/md4 ggated(8) support regular files as well, so you don't have to use mdconfig(8) to export them. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --P+33d92oIH25kiaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGEThmForvXbEpPzQRAhIUAJ9u4wIqGdRtmohbqUzfSGOpe7jU+ACfcNuH 4vaU7nI3fDJSVPfW2cYC+D8= =QPMO -----END PGP SIGNATURE----- --P+33d92oIH25kiaB-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 17:27:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56BCC16A402 for ; Mon, 2 Apr 2007 17:27:30 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6F47113C469 for ; Mon, 2 Apr 2007 17:27:29 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HYQJL-0003pu-Sx; Mon, 02 Apr 2007 19:27:21 +0200 Message-ID: <46113CF2.6090009@gwdg.de> Date: Mon, 02 Apr 2007 19:27:14 +0200 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070318) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070311050627.GC79728@cdnetworks.co.kr> <45F3B94B.3030104@gwdg.de> <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> In-Reply-To: <20070402010230.GA1323@cdnetworks.co.kr> Content-Type: multipart/mixed; boundary="------------090700070103090904040807" X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 17:27:30 -0000 This is a multi-part message in MIME format. --------------090700070103090904040807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pyun YongHyeon schrieb: > On Sat, Mar 31, 2007 at 05:01:18PM +0200, Rainer Hurling wrote: > > Thank you Pyun YongHyeon for the newest patch. I am running it with > > if_nfe.c and if_nfereg.h from 03/21/2007 and if_nfevar.h from 03/19/2007 > > on FreeBSD 7.0-CURRENT (i386) from today. > > > > boot -v gives me: > > nfe0: port 0xb000-0xb007 mem > > xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > > miibus0: on nfe0 > > ciphy0: PHY 1 on miibus0 > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > nfe0: bpf attached > > nfe0: Ethernet address: 00:16:17:95:d9:7c > > nfe0: [MPSAFE] > > nfe0: [FILTER] > > > > > > Now there are no more warning from miibus0 :-) > > > > Thanks for testing. > > > Unfortunately at bigger network transfers I still observe the previously > > described watchdog timeouts: > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > ... > > > > During these timeouts I am not able to use my network ;-( > > > > I would be happy if I could help solving this problem. Let me know if I > > can test anything. > > > > Does nfe(4) use shared interrupt with other devices? > (Check 'vmstat -i' output.) #vmstat -i interrupt total rate irq1: atkbd0 10848 1 irq12: psm0 79500 7 irq14: ata0 102455 10 irq16: sym0 14 0 irq17: nvidia0 632579 61 irq21: pcm0 ohci0 30994 3 irq22: nfe0 ehci0 36673 3 irq23: atapci1 143425 14 cpu0: timer 20480047 1999 cpu1: timer 20466044 1998 Total 41982579 4099 > Since the watchdog timeout error indicates you've had missing Tx > completion interrupts I guess you've lost Tx completion interrupts > under high systems loads. One of major changes in new nfe(4) was > switching to so-called adaptive polling and it is known to give better > performance. However it can loose interrupts under high system loads > (e.g. buildworld) and I guess there are two ways to fix the issue. > > 1. Add MSI/MSI-X support. > I think this is the cleanest solution to the issue. But old > hardwares which has no MSI/MSI-X support and buggy PCI bridges may > have issues dealing with MSI/MSI-X. In addition, there is no public > documentation available for NVIDIA NICs and lack of MSI/MSI-X capable > hardwares make me hard to add MSI/MSI-X support. AFAIK, Shigeaki > Tagashira is working on supporting MSI/MSI-X.(CCed) dmesg shows on my MCP55 system: pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: HT Bridge at 0:5:0 has non-default MSI window 0xc02000a pcib0: HT Bridge at 0:5:1 has non-default MSI window 0x602000a pcib0: HT Bridge at 0:6:1 has non-default MSI window 0x0 pcib0: HT Bridge at 0:8:0 has non-default MSI window 0x75011 pci0: at device 0.0 (no driver attached) A more comprehensive info of 'boot -v' you can find as attachement. I snipped a few lines because they are not necessary in this context (cpu, pcm0, ad, acd, ...). > 2. polling(4) > Because polling(4) does not rely on timed-delivery of Tx interrupts > it would help in your case. Is polling in classical sense the right way for this new driver with 'adaptive polling'? I think you could be right when assuming inadequate MSI/MSI-X support for the MCP55 chipset. Rainer Hurling --------------090700070103090904040807 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x10de, dev=0x0369, revid=0xa1 bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0363, revid=0xa2 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0368, revid=0xa2 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0xcc00, size 6, enabled map[20]: type 4, range 32, base 0x2d00, size 6, enabled map[24]: type 4, range 32, base 0x2e00, size 6, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.LSMB:0) pci_link13: Picked IRQ 20 with weight 0 pcib0: slot 1 INTA routed to irq 20 via \\_SB_.LSMB found-> vendor=0x10de, dev=0x036c, revid=0xa1 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xfbefb000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LUB0:0) pci_link8: Picked IRQ 21 with weight 0 pcib0: slot 2 INTA routed to irq 21 via \\_SB_.LUB0 found-> vendor=0x10de, dev=0x036d, revid=0xa2 bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xfbefac00, size 8, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.LUB2:0) pci_link10: Picked IRQ 22 with weight 0 pcib0: slot 2 INTB routed to irq 22 via \\_SB_.LUB2 found-> vendor=0x10de, dev=0x036e, revid=0xa1 bus=0, slot=4, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0xffa0, size 4, enabled pcib0: HT Bridge at 0:5:0 has non-default MSI window 0xc02000a found-> vendor=0x10de, dev=0x037f, revid=0xa2 bus=0, slot=5, func=0 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type 4, range 32, base 0xc480, size 3, enabled map[14]: type 4, range 32, base 0xc400, size 2, enabled map[18]: type 4, range 32, base 0xc080, size 3, enabled map[1c]: type 4, range 32, base 0xc000, size 2, enabled map[20]: type 4, range 32, base 0xbc00, size 4, enabled map[24]: type 1, range 32, base 0xfbef9000, size 12, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.LSA0:0) pci_link15: Picked IRQ 23 with weight 0 pcib0: slot 5 INTA routed to irq 23 via \\_SB_.LSA0 pcib0: HT Bridge at 0:5:1 has non-default MSI window 0x602000a found-> vendor=0x10de, dev=0x037f, revid=0xa2 bus=0, slot=5, func=1 class=01-01-85, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type 4, range 32, base 0xb880, size 3, enabled map[14]: type 4, range 32, base 0xb800, size 2, enabled map[18]: type 4, range 32, base 0xb480, size 3, enabled map[1c]: type 4, range 32, base 0xb400, size 2, enabled map[20]: type 4, range 32, base 0xb080, size 4, enabled map[24]: type 1, range 32, base 0xfbef8000, size 12, enabled pcib0: matched entry for 0.5.INTB (src \\_SB_.LSA1:0) pci_link16: Picked IRQ 20 with weight 1 pcib0: slot 5 INTB routed to irq 20 via \\_SB_.LSA1 found-> vendor=0x10de, dev=0x0370, revid=0xa2 bus=0, slot=6, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x02 (500 ns) pcib0: HT Bridge at 0:6:1 has non-default MSI window 0x0 found-> vendor=0x10de, dev=0x0371, revid=0xa2 bus=0, slot=6, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks map[10]: type 1, range 32, base 0xfbef4000, size 14, enabled pcib0: matched entry for 0.6.INTB (src \\_SB_.LAZA:0) pci_link12: Picked IRQ 21 with weight 1 pcib0: slot 6 INTB routed to irq 21 via \\_SB_.LAZA pcib0: HT Bridge at 0:8:0 has non-default MSI window 0x75011 found-> vendor=0x10de, dev=0x0373, revid=0xa2 bus=0, slot=8, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 8 messages, 64 bit, vector masks MSI-X supports 8 messages in maps 0x18 and 0x1c map[10]: type 1, range 32, base 0xfbef3000, size 12, enabled map[14]: type 4, range 32, base 0xb000, size 3, enabled map[18]: type 1, range 32, base 0xfbefa800, size 8, enabled map[1c]: type 1, range 32, base 0xfbefa400, size 4, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.LMAC:0) pci_link11: Picked IRQ 22 with weight 1 pcib0: slot 8 INTA routed to irq 22 via \\_SB_.LMAC found-> vendor=0x10de, dev=0x0374, revid=0xa2 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0004, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0374, revid=0xa2 bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0004, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0378, revid=0xa2 bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0004, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0375, revid=0xa2 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0004, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0377, revid=0xa2 bus=0, slot=15, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfbefb000-0xfbefbfff irq 21 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbefb000 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfbefac00-0xfbefacff irq 22 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfbefac00 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 4.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0xc480-0xc487,0xc400-0xc403,0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc0f mem 0xfbef9000-0xfbef9fff irq 23 at device 5.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbc00 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfbef9000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc480 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xc400 ata2: SATA connect time=0ms ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xc080 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xc000 ata3: SATA connect status=00000000 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0xb880-0xb887,0xb800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb08f mem 0xfbef8000-0xfbef8fff irq 20 at device 5.1 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb080 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xfbef8000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb880 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xb800 ata4: SATA connect status=00000000 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb480 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb400 ata5: SATA connect status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] pcib1: at device 6.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfbf00000-0xfbffffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1000, dev=0x0001, revid=0x12 bus=1, slot=2, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 map[10]: type 4, range 32, base 0xd000, size 8, enabled pcib1: requested I/O range 0xd000-0xd0ff: in range map[14]: type 1, range 32, base 0xfbfff800, size 8, enabled pcib1: requested memory range 0xfbfff800-0xfbfff8ff: good pcib1: matched entry for 1.2.INTA (src \\_SB_.LNKC:0) pci_link2: Picked IRQ 16 with weight 0 pcib1: slot 2 INTA routed to irq 16 via \\_SB_.LNKC sym0: <810a> port 0xd000-0xd0ff mem 0xfbfff800-0xfbfff8ff irq 16 at device 2.0 on pci1 sym0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfbfff800 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: open drain IRQ line driver sym0: using LOAD/STORE-based firmware. ioapic0: routing intpin 16 (PCI IRQ 16) to vector 55 sym0: [GIANT-LOCKED] sym0: [ITHREAD] pcm0: mem 0xfbef4000-0xfbef7fff irq 21 at device 6.1 on pci0 pcm0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfbef4000 pcm0: [MPSAFE] pcm0: [ITHREAD] nfe0: port 0xb000-0xb007 mem 0xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 miibus0: on nfe0 ciphy0: PHY 1 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:16:17:95:d9:7c nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 pcib3: at device 12.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci3: on pcib3 pci3: physical bus=3 pcib4: at device 13.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: physical bus=4 pcib5: at device 14.0 on pci0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: physical bus=5 pcib6: at device 15.0 on pci0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xe000-0xefff pcib6: memory decode 0xfc000000-0xfebfffff pcib6: prefetched decode 0xd0000000-0xdfffffff pci6: on pcib6 pci6: physical bus=6 found-> vendor=0x10de, dev=0x0392, revid=0xa1 bus=6, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 0xfd000000, size 24, enabled pcib6: requested memory range 0xfd000000-0xfdffffff: good map[14]: type 3, range 64, base 0xd0000000, size 28, enabled pcib6: requested memory range 0xd0000000-0xdfffffff: good map[1c]: type 1, range 64, base 0xfc000000, size 24, enabled pcib6: requested memory range 0xfc000000-0xfcffffff: good map[24]: type 4, range 32, base 0xec00, size 7, enabled pcib6: requested I/O range 0xec00-0xec7f: in range pcib6: matched entry for 6.0.INTA (src \\_SB_.LNEB:0) pci_link5: Picked IRQ 17 with weight 0 pcib6: slot 0 INTA routed to irq 17 via \\_SB_.LNEB nvidia0: port 0xec00-0xec7f mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 17 at device 0.0 on pci6 nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xfd000000 nvidia0: Reserved 0x10000000 bytes for rid 0x14 type 3 at 0xd0000000 nvidia0: Reserved 0x1000000 bytes for rid 0x1c type 3 at 0xfc000000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 56 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] acpi_button0: on acpi0 speaker0: port 0x61 on acpi0 sio0: irq maps: 0xca1 0xcb1 0xca1 0xca1 sio0: irq maps: 0xca1 0xcb1 0xca1 0xca1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] acpi_hpet0: iomem 0xfed00000-0xfed00fff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 7 hz: 25000000 opts: leg_route Timecounter "HPET" frequency 25000000 Hz quality 2000 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 59 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xca1 0xca1 0xca1 0xca1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 134097 -> 100000 procfs registered lapic: Divisor 2, Frequency 100515863 hz Timecounter "TSC" frequency 2211348871 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire [... SNIP ...] ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 1 [...SNIP...] --------------090700070103090904040807-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 17:28:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 821FE16A401 for ; Mon, 2 Apr 2007 17:28:59 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id D669413C4BA for ; Mon, 2 Apr 2007 17:28:58 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so712ugh for ; Mon, 02 Apr 2007 10:28:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=hWr+KUf7loD+gdP8ZTPUAvWbyt6a56Dj35k7psBZtRnt58Ex0759RDgsE0QRwArEkbhPXyiC7BRoThKj7Mij/89ERxDMaQFKjmvXURvBJYu4ImMu682ORgNBqAc15VlxU9rwrjmyzoeOFQzbvVX0y51c0MR3B7bORTWjMkdjS0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=egOR1cbqt7lFfwezGYiyG73858rIYwikYaS1+9iFyJwmi1wBH3Lujb3IMVAcRhJqsMVycSeP/qxmZWATlFzczA+R9+rBODRi3XGcA/ZpRCRttkWXjlyTiLFVqj3MsdFQ5kcD0Elo8oFJyTHs9bhDLOuXdM07VW4mEIRlHQFjM28= Received: by 10.67.115.17 with SMTP id s17mr10132ugm.1175534936720; Mon, 02 Apr 2007 10:28:56 -0700 (PDT) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id x33sm5181ugc.2007.04.02.10.28.56; Mon, 02 Apr 2007 10:28:56 -0700 (PDT) Message-ID: <46113D53.8060505@gmail.com> Date: Mon, 02 Apr 2007 19:28:51 +0200 From: Rene Ladan User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Garrett Cooper References: <46106567.8060109@u.washington.edu> In-Reply-To: <46106567.8060109@u.washington.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Anything (general) needing testing in -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 17:28:59 -0000 Garrett Cooper schreef: > Hello all, > I got my Core 2 Duo box hooked up with vmware, and I was wondering if > there were any general items that needed to be tested in -CURRENT that I > could help with. I'd like to run FreeBSD natively but I'm running into > some issues with driver support (stupid me for purchasing an ATI card You can always use the ATI card with VESA (which is just fast enough to play DVDs) > and Creative X-Fi card :(..). > -Garrett Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 17:47:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E98816A405 for ; Mon, 2 Apr 2007 17:47:50 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from email.aon.at (nat-warsl417-01.aon.at [195.3.96.119]) by mx1.freebsd.org (Postfix) with ESMTP id 4A49213C458 for ; Mon, 2 Apr 2007 17:47:48 +0000 (UTC) (envelope-from c47g@gmx.at) Received: (qmail 17736 invoked from network); 2 Apr 2007 17:47:48 -0000 Received: from unknown (HELO email.aon.at) ([172.18.5.75]) (envelope-sender ) by fallback01.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Apr 2007 17:47:48 -0000 Received: (qmail 30109 invoked from network); 2 Apr 2007 17:47:45 -0000 Received: from m3607p012.adsl.highway.telekom.at (HELO bones) ([88.117.98.204]) (envelope-sender ) by smarthub72.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Apr 2007 17:47:45 -0000 From: Christian Gusenbauer To: freebsd-current@freebsd.org Date: Mon, 2 Apr 2007 19:48:14 +0200 User-Agent: KMail/1.9.6 References: <200703302050.31758.c47g@gmx.at> In-Reply-To: <200703302050.31758.c47g@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1382189.io5Lzd4VDd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704021948.21735.c47g@gmx.at> Subject: Re: Problems burning CDs with ASUS P5B-E/atapi race condition? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 17:47:50 -0000 --nextPart1382189.io5Lzd4VDd Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! Playing a bit with the ATA debug options, I get the following traces: acd0: WARNING - TEST_UNIT_READY freeing taskqueue zombie requesacd0:=20 req=3D0xc54590c0 PREVENT_ALLOW interrupt this looks like a race condition, because printing one text is interrupted = by=20 another one, coming out of the ata driver. Or did I miss something? I attach part of the log. Complete log's available on request. Many thanks, Christian. (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0=20 atapi_action: hcb@0xc5468280: 12 1 80 0 ff 0=20 acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request=20 directly acd0: req=3D0xc54590c0 PREVENT_ALLOW queued acd0: req=3D0xc54590c0 PREVENT_ALLOW wait for completion acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE begin transaction acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE wait for completion acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE interrupt acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE end transaction acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE finish directly acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE completed entered acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE completed callback/wak= eup acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE begin transaction acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE wait for completion acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE interrupt acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE end transaction acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE finish directly acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE completed entered acd0: req=3D0xc5459000 SETFEATURES SET TRANSFER MODE completed callback/wak= eup (noperiph:ata4:0:-1:-1): xpt_async (noperiph:ata4:0:0:0): xpt_compile_path (noperiph:ata4:0:0:0): xpt_release_path acd0: FAILURE - INQUIRY timed out atapi_cb: hcb@0xc5468280 sense =3D 00: sk =3D 0 acd0: cmd INQUIRY status 00 result 05 error 00 (probe0:ata4:0:0:0): xpt_done (probe0:ata4:0:0:0): camisr (probe0:ata4:0:0:0): probedone (probe0:ata4:0:0:0): xpt_action (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0=20 atapi_action: hcb@0xc5468100: 12 1 80 0 ff 0=20 acd0: req=3D0xc54590c0 PREVENT_ALLOW starting acd0: req=3D0xc54590c0 PREVENT_ALLOW begin transaction acd0: WARNING - TEST_UNIT_READY freeing taskqueue zombie requesacd0:=20 req=3D0xc54590c0 PREVENT_ALLOW interrupt acd0: req=3D0xc54590c0 PREVENT_ALLOW end transaction acd0: req=3D0xc54590c0 PREVENT_ALLOW finish taskqueue_swi t acd0: req=3D0xc54590c0 PREVENT_ALLOW completed entered acd0: req=3D0xc54590c0 REQUEST_SENSE autoissue request sense acd0: req=3D0xc54590c0 REQUEST_SENSE queued acd0: req=3D0xc54590c0 REQUEST_SENSE starting acd0: req=3D0xc54590c0 REQUEST_SENSE begin transaction acd0: req=3D0xc54590c0 REQUEST_SENSE interrupt acd0: req=3D0xc54590c0 REQUEST_SENSE end transaction acd0: req=3D0xc54590c0 PREVENT_ALLOW interrupt acd0: req=3D0xc54590c0 PREVENT_ALLOW end transaction acd0: req=3D0xc54590c0 PREVENT_ALLOW finish taskqueue_swi acd0: req=3D0xc54590c0 PREVENT_ALLOW completed entered acd0: req=3D0xc54590c0 PREVENT_ALLOW completed callback/wakeup acd0: req=3D0xc54593c0 TEST_UNIT_READY queued acd0: req=3D0xc54593c0 TEST_UNIT_READY wait for completion acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE begin transaction acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE wait for completion acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE interrupt acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE end transaction acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE finish directly acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE completed entered acd0: req=3D0xc5459480 SETFEATURES SET TRANSFER MODE completed callback/wak= eup acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE begin transaction acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE wait for completion acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE interrupt acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE end transaction acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE finish directly acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE completed entered acd0: req=3D0xc5459540 SETFEATURES SET TRANSFER MODE completed callback/wak= eup (noperiph:ata4:0:-1:-1): xpt_async (noperiph:ata4:0:0:0): xpt_compile_path (noperiph:ata4:0:0:0): xpt_release_path acd0: req=3D0xc54593c0 TEST_UNIT_READY starting acd0: req=3D0xc54593c0 TEST_UNIT_READY begin transaction acd0: FAILURE - INQUIRY timed outacd0: req=3D0xc54593c0 TEST_UNIT_READY=20 interrupt acd0: req=3D0xc54593c0 TEST_UNIT_READY end transaction acd0: req=3D0xc54593c0 TEST_UNIT_READY finish taskqueue_swi atapi_cb: hcb@0xc5468100 sense =3D 00: sk =3D 0 acd0: cmd INQUIRY status 00 result 05 error 00 (probe0:ata4:0:0:0): xpt_done (probe0:ata4:0:0:0): camisr (probe0:ata4:0:0:0): probedone (probe0:ata4:0:0:0): xpt_action (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0=20 atapi_action: hcb@0xc54680c0: 12 1 80 0 ff 0=20 acd0: req=3D0xc54593c0 TEST_UNIT_READY completed entered acd0: req=3D0xc54593c0 REQUEST_SENSE autoissue request sense acd0: req=3D0xc54593c0 REQUEST_SENSE queued On Friday, 30. March 2007, Christian Gusenbauer wrote: > Hi! > > I'm having some problems burning CDs and DVDs with -current on a > new ASUS P5B-E board with an Intel Core 2 Duo. The IDE DVD drive, a Plext= or > PX708A is connected to the JMicron JMB363 controller. > > First of all, there's a problem detecting the atapicam based cd0 device. = As > long as hw.ata.atapi_dma is set to 1, the boot hangs while the kernel > searches for the device. Many commands time out like: > > (probe0:ata4:0:0:0): xpt_schedule > (probe0:ata4:0:0:0): xpt_setup_ccb > (probe0:ata4:0:0:0): probestart > (probe0:ata4:0:0:0): xpt_action > (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 > atapi_action: hcb@0xc4a47c80: 12 1 80 0 ff 0 > (noperiph:ata4:0:-1:-1): xpt_async > (noperiph:ata4:0:0:0): xpt_compile_path > (noperiph:ata4:0:0:0): xpt_release_path > acd0: FAILURE - INQUIRY timed out > atapi_cb: hcb@0xc4a47c80 sense =3D 00: sk =3D 0 > acd0: cmd INQUIRY status 00 result 05 error 00 > (probe0:ata4:0:0:0): xpt_done > (probe0:ata4:0:0:0): camisr > (probe0:ata4:0:0:0): probedone > (probe0:ata4:0:0:0): xpt_action > (probe0:ata4:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 > atapi_action: hcb@0xc4a47c40: 12 1 80 0 ff 0 > acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request > directly > (noperiph:ata4:0:-1:-1): xpt_async > (noperiph:ata4:0:0:0): xpt_compile_path > (noperiph:ata4:0:0:0): xpt_release_path > acd0: FAILURE - INQUIRY timed out > atapi_cb: hcb@0xc4a47c40 sense =3D 00: sk =3D 0 > acd0: cmd INQUIRY status 00 result 05 error 00 > (probe0:ata4:0:0:0): xpt_done > > Nevertheless, after about 20 minutes both devices, an acd0 and a cd0 are > recognized. I can mount a CD using both acd0 and cd0 and reading from the > CD is no problem. But when I try to burn a CD or DVD with burncd or > cdrecord, after a while the drive's LED stops blinking and the process th= en > hangs indefinitly. > > If I turn dma off (hw.ata.atapi_dma=3D"0" setting in loader.conf), the dr= ives > are correctly detected and there are no hangs (no timeouts) during boot. > Mounting and reading from the CD is no problem, but burning doesn't work > either :-(. > > Any ideas? > > Thanks in advance, > Christian. --nextPart1382189.io5Lzd4VDd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQBGEUHl73Wh/GTgh8wRAtDtAJ4omYX4RZg4UJSmQKZptmApx1DlpwCdHr4V cbbS6xivqe+zVCaTNlrWh78= =2ybd -----END PGP SIGNATURE----- --nextPart1382189.io5Lzd4VDd-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 00:05:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B91416A403; Tue, 3 Apr 2007 00:05:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C44D913C46A; Tue, 3 Apr 2007 00:05:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l3304gM2040251; Mon, 2 Apr 2007 18:04:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Apr 2007 18:04:46 -0600 (MDT) Message-Id: <20070402.180446.1573371202.imp@bsdimp.com> To: anderson@freebsd.org From: "M. Warner Losh" In-Reply-To: <461084EA.1000706@freebsd.org> References: <461084EA.1000706@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Apr 2007 18:04:43 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: pccard flash card reader - no longer works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 00:05:58 -0000 In message: <461084EA.1000706@freebsd.org> Eric Anderson writes: : I've been using the same card reader for ages, with various cf cards. : Yesterday, I noticed it no longer works. I know it worked around March : 3rd-ish. Here's what I get: : : : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : 0xecb00000-0xecbfffff: good : Mar 31 21:10:50 neutrino kernel: pccard0: CIS version PCCARD 2.0 or 2.1 : Mar 31 21:10:50 neutrino kernel: pccard0: CIS info: Vendor, CF_Card, : Mar 31 21:10:50 neutrino kernel: pccard0: Manufacturer code 0xa, product 0x0 : Mar 31 21:10:50 neutrino kernel: pccard0: function 0: fixed disk, ccr : addr 200 mask f : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : 0: memory card; irq mask 0; mwait_required rdybsy_active powerdown : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; rdybsy_active io8 : io16 irqshare irqpulse irqlevel p : owerdown : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; : rdybsy_active io8 io16 irqshare irqpuls : e irqlevel powerdown : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; : rdybsy_active io8 io16 irqshare irqpuls : e irqlevel powerdown : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : 0xecb00000-0xecbfffff: good : Mar 31 21:10:50 neutrino kernel: ata2: at port : 0x910-0x91f irq 19 function 0 config 1 on pccard0 : Mar 31 21:10:50 neutrino kernel: ata2: reset tp1 mask=00 ostat0=ff ostat1=00 : Mar 31 21:10:50 neutrino kernel: ata2: [MPSAFE] : Mar 31 21:10:50 neutrino kernel: ata2: [ITHREAD] : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : 0xecb00000-0xecbfffff: good : : : The flash card works fine if I plug it in via a USB<->CF adapter. : : Any ideas? When did this last work? My quick test here shows it working on my laptop. Warner From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 02:06:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B50EC16A406 for ; Tue, 3 Apr 2007 02:06:54 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFBA13C455 for ; Tue, 3 Apr 2007 02:06:54 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.13.8/8.13.8) with ESMTP id l331jv0u037116 for ; Mon, 2 Apr 2007 21:45:57 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.13.8/8.13.8/Submit) id l331jvnM037115 for current@freebsd.org; Mon, 2 Apr 2007 21:45:57 -0400 (EDT) (envelope-from mwlucas) Date: Mon, 2 Apr 2007 21:45:57 -0400 From: "Michael W. Lucas" To: current@freebsd.org Message-ID: <20070403014557.GA36989@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Mon, 02 Apr 2007 21:45:57 -0400 (EDT) Cc: Subject: pc cards not working in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 02:06:54 -0000 Hi, i386 -current, brand new laptop, csup'd 1 Apr 2007, GENERIC kernel. My cheap wi0 card worked fine on snap13, but when I insert it now I get: Apr 2 21:30:38 stretchlimo kernel: CIS is too long -- truncating Apr 2 21:30:38 stretchlimo kernel: pccard0: Card has no functions! Apr 2 21:30:38 stretchlimo kernel: cbb0: PC Card card activation failed I see that this cropped up around March 22, but it looks like jhb had committed a patch to fix this (see http://lists.freebsd.org/pipermail/freebsd-current/2007-March/070075.html). Once again, I seem to be special. Lucky me! Any suggestions? ==ml -- Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 22:27:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5D16A406 for ; Mon, 2 Apr 2007 22:27:45 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (omval.tednet.nl [213.154.224.17]) by mx1.freebsd.org (Postfix) with ESMTP id A260213C459 for ; Mon, 2 Apr 2007 22:27:44 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (localhost [127.0.0.1]) by omval.tednet.nl (8.13.8/8.13.8) with ESMTP id l32LHFWi079695 for ; Mon, 2 Apr 2007 23:17:15 +0200 (CEST) (envelope-from ted@omval.tednet.nl) Received: (from ted@localhost) by omval.tednet.nl (8.13.8/8.13.8/Submit) id l32LHFUt079690 for freebsd-current@freebsd.org; Mon, 2 Apr 2007 23:17:15 +0200 (CEST) (envelope-from ted) Message-Id: <200704022117.l32LHFUt079690@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Mon, 2 Apr 2007 23:17:15 +0200 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on omval.tednet.nl X-Mailman-Approved-At: Tue, 03 Apr 2007 02:13:49 +0000 Subject: Acer 3623 with acpi version 20070320 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 22:27:45 -0000 Until revision 1.68 of acpi_ec.c ACPI worked on my Acer 3623 laptop, although lots of AE_NO_HARDWARE_RESPONSE messages were produced. I used a custom DSDT file, and a few patches to suppress the error messages. Starting with revision 1.69 of acpi_ec.c things like battery status stopped working. The import of 20070320 made no change. I found that the Acer does not like the EC_GET_CSR in EcWaitEvent to happen too quickly after an EC_SET_DATA or EC_SET_CSR command. Polling repeatedly makes thing worse as I found out playing with the tunables debug.acpi.ec.poll_time and debug.acpi.ec.timeout: the system freezes while slowly spitting out AE_NO_HARDWARE_RESPONSE messages. What did improve things was to insert a delay before EC_GET_CSR in EcWaitEvent. There is already code to do that, but it is disabled by #if 0 and the delay is coupled to EC_POLL_DELAY. Playing with a tunable delay here showed that with AcpiOsStall( 2200 ); the number of AE_NO_HARDWARE_RESPONSE messages started dropping. With 2300 us delay these messages occur only occasionally, and battery-status works again. With 2500 us delay there are no more error messages and everything works fine. I have debug.acpi.ec.poll_time and debug.acpi.ec.timeout back to default, and debug.acpi.ec.burst: 1. I also found that now I do not need the custom DSDT file anymore. regards, -- ted From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 00:14:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E1AE16A401 for ; Tue, 3 Apr 2007 00:14:05 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id D621E13C457 for ; Tue, 3 Apr 2007 00:14:04 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l330E3BT061684 for ; Mon, 2 Apr 2007 19:14:04 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <46119C4B.3020200@centtech.com> Date: Mon, 02 Apr 2007 19:14:03 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <460FDEF2.2060203@centtech.com> <20070401180125.GE25661@garage.freebsd.pl> In-Reply-To: <20070401180125.GE25661@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2998/Mon Apr 2 16:34:29 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com X-Mailman-Approved-At: Tue, 03 Apr 2007 02:13:59 +0000 Subject: Re: geom_journal panic: wrong offset 500107860990 for sectorsize 512 - RESOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 00:14:05 -0000 On 04/01/07 13:01, Pawel Jakub Dawidek wrote: > On Sun, Apr 01, 2007 at 11:33:54AM -0500, Eric Anderson wrote: >> After running: >> >> gjournal load >> gjournal label -s 4G /dev/mirror/data >> >> I got this panic, and now every time I load geom_journal.ko, the system panics this same way. >> >> GEOM_JOURNAL: Journal 4239489025: mirror/data contains data. >> GEOM_JOURNAL: Journal 4239489025: mirror/data contains journal. >> GEOM_JOURNAL: Journal mirror/data clean. >> panic: wrong offset 500107860990 for sectorsize 512 >> >> I have a crash dump to look at if needed. >> Looks something like this: >> #8 0xc06e0f13 in kdb_enter (msg=0x12
) at cpufunc.h:60 >> #9 0xc06c2334 in panic (fmt=0xc0943b8b "wrong offset %jd for sectorsize %u") at /usr/src/sys/kern/kern_shutdown.c:547 >> #10 0xc0685316 in g_io_request (bp=0xc2edaad4, cp=0xc2485140) at /usr/src/sys/geom/geom_io.c:356 >> #11 0xc0685aae in g_write_data (cp=0xc2485140, offset=Unhandled dwarf expression opcode 0x93) at /usr/src/sys/geom/geom_io.c:643 >> >> >> This is running -CURRENT's latest snapshot (from March). > > Could you give me full backtrace? I don't see who calls g_write_data() > exactly. > This has been resolved. Turns out, that you should not use size modifiers like 'G' or 'M' when using the -s option to gjournal. Thanks Pawel for the help!! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 03:21:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 596E616A404 for ; Tue, 3 Apr 2007 03:21:50 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E719113C455 for ; Tue, 3 Apr 2007 03:21:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.61]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l332qa09023167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 12:22:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Tue, 3 Apr 2007 12:22:23 +0930 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1970715.5KuDOZtftD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704031222.25410.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Subject: Cache flush warnings due to geom_journal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 03:21:50 -0000 --nextPart1970715.5KuDOZtftD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I had to replace the HD in my laptop recently and decided to give gjournal a whirl.. So far it seems to work very well, thanks Pawel! One thing I have noticed is that I get occasional messages saying a flush command timed out, ie ad0: FAILURE - FLUSHCACHE timed out GEOM_JOURNAL: Flush cache of ad0s2e: error=3D5. Has anyone else seen these? The drive is a WD Scorpio 60GB PATA connected t= o=20 an Intel ICH4 chipset. atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 =2E.. ad0: 57231MB at ata0-master UDMA100 Maybe the timeout for the command needs to be increased slightly? (NFI what the units are.. seconds?) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1970715.5KuDOZtftD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBGEcFp5ZPcIHs/zowRAiqSAJ9/DztvQU+x+1fDYCbh5LQPvm2eeQCgmhVn GMyunlfuLrvuI/epuJ0g4Vc= =mrQ9 -----END PGP SIGNATURE----- --nextPart1970715.5KuDOZtftD-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 04:56:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA79E16A402 for ; Tue, 3 Apr 2007 04:56:33 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9550413C4AE for ; Tue, 3 Apr 2007 04:56:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l334uSfq011304 for ; Mon, 2 Apr 2007 23:56:28 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4611DE78.7050405@freebsd.org> Date: Mon, 02 Apr 2007 23:56:24 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <460FDEF2.2060203@centtech.com> <20070401180125.GE25661@garage.freebsd.pl> <46119C4B.3020200@centtech.com> In-Reply-To: <46119C4B.3020200@centtech.com> Content-Type: multipart/mixed; boundary="------------040408000408040400050209" X-Virus-Scanned: ClamAV 0.88.4/3003/Mon Apr 2 22:15:48 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Subject: Re: geom_journal panic: wrong offset 500107860990 for sectorsize 512 - RESOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 04:56:33 -0000 This is a multi-part message in MIME format. --------------040408000408040400050209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/02/07 19:14, Eric Anderson wrote: > On 04/01/07 13:01, Pawel Jakub Dawidek wrote: >> On Sun, Apr 01, 2007 at 11:33:54AM -0500, Eric Anderson wrote: >>> After running: >>> >>> gjournal load >>> gjournal label -s 4G /dev/mirror/data >>> >>> I got this panic, and now every time I load geom_journal.ko, the system panics this same way. >>> >>> GEOM_JOURNAL: Journal 4239489025: mirror/data contains data. >>> GEOM_JOURNAL: Journal 4239489025: mirror/data contains journal. >>> GEOM_JOURNAL: Journal mirror/data clean. >>> panic: wrong offset 500107860990 for sectorsize 512 >>> >>> I have a crash dump to look at if needed. >>> Looks something like this: >>> #8 0xc06e0f13 in kdb_enter (msg=0x12
) at cpufunc.h:60 >>> #9 0xc06c2334 in panic (fmt=0xc0943b8b "wrong offset %jd for sectorsize %u") at /usr/src/sys/kern/kern_shutdown.c:547 >>> #10 0xc0685316 in g_io_request (bp=0xc2edaad4, cp=0xc2485140) at /usr/src/sys/geom/geom_io.c:356 >>> #11 0xc0685aae in g_write_data (cp=0xc2485140, offset=Unhandled dwarf expression opcode 0x93) at /usr/src/sys/geom/geom_io.c:643 >>> >>> >>> This is running -CURRENT's latest snapshot (from March). >> Could you give me full backtrace? I don't see who calls g_write_data() >> exactly. >> > > > This has been resolved. Turns out, that you should not use size > modifiers like 'G' or 'M' when using the -s option to gjournal. Thanks > Pawel for the help!! > > Eric > > Here is a patch that adds that functionality. Can be found here: http://www.googlebit.com/freebsd/patches/gjournal_size_expression.patch and attached. WARNING: This patch could explode, cause bodily harm, etc. Well, maybe not.. but you get the point. :) Eric --------------040408000408040400050209 Content-Type: text/x-patch; name="gjournal_size_expression.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gjournal_size_expression.patch" Index: class/journal/geom_journal.c =================================================================== RCS file: /alt/ncvs/src/sbin/geom/class/journal/geom_journal.c,v retrieving revision 1.2 diff -u -r1.2 geom_journal.c --- class/journal/geom_journal.c 1 Nov 2006 09:22:33 -0000 1.2 +++ class/journal/geom_journal.c 3 Apr 2007 04:49:28 -0000 @@ -66,7 +66,7 @@ { 'c', "checksum", NULL, G_TYPE_BOOL }, { 'f', "force", NULL, G_TYPE_BOOL }, { 'h', "hardcode", NULL, G_TYPE_BOOL }, - { 's', "jsize", &default_jsize, G_TYPE_NUMBER }, + { 's', "jsize", &default_jsize, G_TYPE_STRING }, G_OPT_SENTINEL }, "[-cfhv] [-s jsize] dataprov [jprov]" @@ -174,7 +174,7 @@ } data = gctl_get_ascii(req, "arg0"); - jsize = gctl_get_intmax(req, "jsize"); + jsize = gctl_get_numexpr(req, "jsize"); journal = NULL; switch (nargs) { case 1: Index: misc/subr.c =================================================================== RCS file: /alt/ncvs/src/sbin/geom/misc/subr.c,v retrieving revision 1.7 diff -u -r1.7 subr.c --- misc/subr.c 25 Jan 2007 11:35:27 -0000 1.7 +++ misc/subr.c 3 Apr 2007 04:50:44 -0000 @@ -377,6 +377,70 @@ return (*p); } +/* + * Convert an expression of the following forms to a uintmax_t. + * 1) A positive decimal number. + * 2) A positive decimal number followed by a 'b' or 'B' (mult by 512). + * 3) A positive decimal number followed by a 'k' or 'K' (mult by 1 << 10). + * 4) A positive decimal number followed by a 'm' or 'M' (mult by 1 << 20). + * 5) A positive decimal number followed by a 'g' or 'G' (mult by 1 << 30). + * 5) A positive decimal number followed by a 'w' or 'W' (mult by sizeof int). + */ +intmax_t +gctl_get_numexpr(struct gctl_req *req, const char *pfmt, ...) +{ + const char *val; + va_list ap; + uintmax_t num, mult, prevnum; + char *expr; + + va_start(ap, pfmt); + val = gctl_get_param(req, 0, pfmt, ap); + + num = strtouq(val, &expr, 0); + + if (expr == val) /* No valid digits. */ + printf("illegal numeric value\n"); + + mult = 0; + switch (*expr) { + case 'B': + case 'b': + mult = 512; + break; + case 'K': + case 'k': + mult = 1 << 10; + break; + case 'M': + case 'm': + mult = 1 << 20; + break; + case 'G': + case 'g': + mult = 1 << 30; + break; + case 'W': + case 'w': + mult = sizeof(int); + break; + default: + ; + } + + if (mult != 0) { + prevnum = num; + num *= mult; + /* Check for overflow. */ + if (num / mult != prevnum) + printf("overflow in argument\n"); + expr++; + } + + va_end(ap); + return (num); +} + const char * gctl_get_ascii(struct gctl_req *req, const char *pfmt, ...) { Index: misc/subr.h =================================================================== RCS file: /alt/ncvs/src/sbin/geom/misc/subr.h,v retrieving revision 1.8 diff -u -r1.8 subr.h --- misc/subr.h 25 Jan 2007 11:35:27 -0000 1.8 +++ misc/subr.h 3 Apr 2007 04:21:36 -0000 @@ -44,6 +44,7 @@ void gctl_error(struct gctl_req *req, const char *error, ...) __printflike(2, 3); int gctl_get_int(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); intmax_t gctl_get_intmax(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); +intmax_t gctl_get_numexpr(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); const char *gctl_get_ascii(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); int gctl_change_param(struct gctl_req *req, const char *name, int len, const void *value); --------------040408000408040400050209-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 05:13:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC6E916A406 for ; Tue, 3 Apr 2007 05:13:18 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id C026513C45D for ; Tue, 3 Apr 2007 05:13:16 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l335DFmh014223; Tue, 3 Apr 2007 00:13:15 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4611E26A.7010905@freebsd.org> Date: Tue, 03 Apr 2007 00:13:14 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: "M. Warner Losh" References: <461084EA.1000706@freebsd.org> <20070402.180446.1573371202.imp@bsdimp.com> In-Reply-To: <20070402.180446.1573371202.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3003/Mon Apr 2 22:15:48 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: pccard flash card reader - no longer works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 05:13:19 -0000 On 04/02/07 19:04, M. Warner Losh wrote: > In message: <461084EA.1000706@freebsd.org> > Eric Anderson writes: > : I've been using the same card reader for ages, with various cf cards. > : Yesterday, I noticed it no longer works. I know it worked around March > : 3rd-ish. Here's what I get: > : > : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : 0xecb00000-0xecbfffff: good > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS version PCCARD 2.0 or 2.1 > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS info: Vendor, CF_Card, > : Mar 31 21:10:50 neutrino kernel: pccard0: Manufacturer code 0xa, product 0x0 > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0: fixed disk, ccr > : addr 200 mask f > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : 0: memory card; irq mask 0; mwait_required rdybsy_active powerdown > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; rdybsy_active io8 > : io16 irqshare irqpulse irqlevel p > : owerdown > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; > : rdybsy_active io8 io16 irqshare irqpuls > : e irqlevel powerdown > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; > : rdybsy_active io8 io16 irqshare irqpuls > : e irqlevel powerdown > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : 0xecb00000-0xecbfffff: good > : Mar 31 21:10:50 neutrino kernel: ata2: at port > : 0x910-0x91f irq 19 function 0 config 1 on pccard0 > : Mar 31 21:10:50 neutrino kernel: ata2: reset tp1 mask=00 ostat0=ff ostat1=00 > : Mar 31 21:10:50 neutrino kernel: ata2: [MPSAFE] > : Mar 31 21:10:50 neutrino kernel: ata2: [ITHREAD] > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : 0xecb00000-0xecbfffff: good > : > : > : The flash card works fine if I plug it in via a USB<->CF adapter. > : > : Any ideas? > > When did this last work? My quick test here shows it working on my > laptop. > > Warner I know it worked at the very beginning of the month (around March 2nd-ish). If there's a particular date to go back to, let me know and I can give it a try. Eric From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 05:36:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3CC516A414; Tue, 3 Apr 2007 05:36:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF8013C46E; Tue, 3 Apr 2007 05:36:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l335YZwi042315; Mon, 2 Apr 2007 23:34:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Apr 2007 23:34:39 -0600 (MDT) Message-Id: <20070402.233439.-1548241370.imp@bsdimp.com> To: anderson@freebsd.org From: "M. Warner Losh" In-Reply-To: <4611E26A.7010905@freebsd.org> References: <461084EA.1000706@freebsd.org> <20070402.180446.1573371202.imp@bsdimp.com> <4611E26A.7010905@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Apr 2007 23:34:35 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: pccard flash card reader - no longer works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 05:36:07 -0000 In message: <4611E26A.7010905@freebsd.org> Eric Anderson writes: : On 04/02/07 19:04, M. Warner Losh wrote: : > In message: <461084EA.1000706@freebsd.org> : > Eric Anderson writes: : > : I've been using the same card reader for ages, with various cf cards. : > : Yesterday, I noticed it no longer works. I know it worked around March : > : 3rd-ish. Here's what I get: : > : : > : : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : > : 0xecb00000-0xecbfffff: good : > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS version PCCARD 2.0 or 2.1 : > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS info: Vendor, CF_Card, : > : Mar 31 21:10:50 neutrino kernel: pccard0: Manufacturer code 0xa, product 0x0 : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0: fixed disk, ccr : > : addr 200 mask f : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : > : 0: memory card; irq mask 0; mwait_required rdybsy_active powerdown : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : > : 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; rdybsy_active io8 : > : io16 irqshare irqpulse irqlevel p : > : owerdown : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : > : 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; : > : rdybsy_active io8 io16 irqshare irqpuls : > : e irqlevel powerdown : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry : > : 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; : > : rdybsy_active io8 io16 irqshare irqpuls : > : e irqlevel powerdown : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : > : 0xecb00000-0xecbfffff: good : > : Mar 31 21:10:50 neutrino kernel: ata2: at port : > : 0x910-0x91f irq 19 function 0 config 1 on pccard0 : > : Mar 31 21:10:50 neutrino kernel: ata2: reset tp1 mask=00 ostat0=ff ostat1=00 : > : Mar 31 21:10:50 neutrino kernel: ata2: [MPSAFE] : > : Mar 31 21:10:50 neutrino kernel: ata2: [ITHREAD] : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range : > : 0xecb00000-0xecbfffff: good : > : : > : : > : The flash card works fine if I plug it in via a USB<->CF adapter. : > : : > : Any ideas? : > : > When did this last work? My quick test here shows it working on my : > laptop. : > : > Warner : : : I know it worked at the very beginning of the month (around March : 2nd-ish). : : If there's a particular date to go back to, let me know and I can give : it a try. If you know that April 1 didn't work, but March 2nd did, you might try around March 15th. I don't know what broke things, so need a little clue. Warner From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 05:58:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1AFF16A404 for ; Tue, 3 Apr 2007 05:58:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9212513C45E for ; Tue, 3 Apr 2007 05:58:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1560592ana for ; Mon, 02 Apr 2007 22:58:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fgOSuIWWGYJWdrBLGI8wAQoyT0acogbOp72yWJBnd1dQimfk8nXC7gWOwjZhYk166IcAJSOo/F361TEkrKmmgilWttrg7YiqnlXIJJ39Qa0DoT+diGY71B6kTJjgUf8vvoScSBp9cgqwlFWrVmTds35tT1KXmsEVQFZkt0DFXyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ms7IwREQqP3FAryc2Z/lVRTO6+ibXz0lXXUJiCAj4WBnOEZQl0vxXIKqzG5YY7OmmKaUbpHqBy8AH96ZYCD0KzqAnmqWC5s0hb7VTAYTrVcGpeRYG/j80CORW5/JWnBs3VBHrOkfgcpHe8Og6tkOmZrnTkqmZ9r8gf9wFDFS9Jc= Received: by 10.100.7.18 with SMTP id 18mr4044866ang.1175578231011; Mon, 02 Apr 2007 22:30:31 -0700 (PDT) Received: by 10.100.48.8 with HTTP; Mon, 2 Apr 2007 22:30:30 -0700 (PDT) Message-ID: <11167f520704022230l5ca20144u13a5706157628f99@mail.gmail.com> Date: Tue, 3 Apr 2007 00:30:30 -0500 From: "Sam Fourman Jr." To: yal@yal.hopto.org In-Reply-To: <3763.87.18.101.132.1175524536.squirrel@yal.hopto.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3763.87.18.101.132.1175524536.squirrel@yal.hopto.org> Cc: freebsd-current@freebsd.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 05:58:55 -0000 I just wanted to report that I have used this Driver Everyday for over a month http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz someone posted awhile back I have Tried several Driver even newer ones and they all fail for me it works well and it does support wep I have tested it with FreeBSD 6.2 STABLE (March 2007 snapshot) to install Just extract the driver #make #make install then edit your /boot/loader.conf and you are ready to go I haven't seen any updates to the wpi driver in awhile and I wanted to ask what others thought of this driver Would it not be great to have this in -current. for what it is worth I am using a Lenovo 3000 N 768-dku notebook also would someone be able to mirror this Driver Sam Fourman Jr. On 4/2/07, yal wrote: > Hi, > > Are there any schedules for a new official driver for the Intel 3945? > I've been unable to run the old beta wpi driver on -CURRENT for weeks now! > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 08:22:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34F5D16A404 for ; Tue, 3 Apr 2007 08:22:14 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id E626B13C468 for ; Tue, 3 Apr 2007 08:22:13 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1595775ana for ; Tue, 03 Apr 2007 01:22:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CNFXc23Cn1bMgVPITS0zU36dZgG3zD4ImSCHvOrPCpM247DRlVsv4y3j/Fr3KkrcY9p7dEIWP9L0zsbYSIJbwRes2WqE02GdmR0VPwZlzJiVCz2R2JWiiOFgC5n6rxdyuIqwqJH4uJKSmvdXuYGMqR4Xy1v4sMxC0qy2YAVk7Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jJUrHk4md5GwfGj2pCJnt+e+jKXjgNcVEoFnA3R34mfc+eye7u+slFNd7CysHB7n6KYUTMcpS5ex+Xyb9C9YiuGecLr4qrHed1JNQsiVm/iyXrk+6XTY57Xmb6Ax49/g7Kh+YUEvvOB6RV7SYXX9uCFnH6OoRpfyltt3AlweF/U= Received: by 10.100.125.5 with SMTP id x5mr4137967anc.1175588532507; Tue, 03 Apr 2007 01:22:12 -0700 (PDT) Received: by 10.100.48.8 with HTTP; Tue, 3 Apr 2007 01:22:12 -0700 (PDT) Message-ID: <11167f520704030122k7c2e5082pf5cf882e2ce30c97@mail.gmail.com> Date: Tue, 3 Apr 2007 03:22:12 -0500 From: "Sam Fourman Jr." To: Vince In-Reply-To: <46120C3F.2070802@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3763.87.18.101.132.1175524536.squirrel@yal.hopto.org> <11167f520704022230l5ca20144u13a5706157628f99@mail.gmail.com> <46120C3F.2070802@unsane.co.uk> Cc: freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 08:22:14 -0000 Thank you for your Feedback I never Tried it in -current I ran 6.2 Stable, Benjamin Close is working on a Driver however he hasn't updated his site in over a month. Sam Fourman Jr. On 4/3/07, Vince wrote: > It doesnt seem to compile in current (as of yesterday anyway) however. I > believe that Benjamin Close is working on a newer driver at > http://www.clearchain.com/wiki/Wpi This one (well the version in > perforce anyway) compiles but doesnt attach correctly. Hopefully > Benjamin will have time to work on it again soon. > > > Vince > > > Sam Fourman Jr. wrote: > > I just wanted to report that I have used this Driver Everyday for over a > > month > > http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz > > > > someone posted awhile back I have Tried several Driver even newer ones > > and they all fail for me > > > > it works well and it does support wep I have tested it with FreeBSD > > 6.2 STABLE (March 2007 snapshot) > > > > to install Just extract the driver > > #make > > #make install > > then edit your /boot/loader.conf > > and you are ready to go > > > > I haven't seen any updates to the wpi driver in awhile and I wanted > > to ask what others thought of this driver Would it not be great to > > have this in -current. > > > > for what it is worth I am using a Lenovo 3000 N 768-dku notebook > > > > also would someone be able to mirror this Driver > > > > > > Sam Fourman Jr. > > > > > > On 4/2/07, yal wrote: > >> Hi, > >> > >> Are there any schedules for a new official driver for the Intel 3945? > >> I've been unable to run the old beta wpi driver on -CURRENT for weeks > >> now! > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 09:16:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 133B916A401 for ; Tue, 3 Apr 2007 09:16:43 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 920D513C458 for ; Tue, 3 Apr 2007 09:16:42 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1746002wra for ; Tue, 03 Apr 2007 02:16:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=MxS4QjbW+p4WqICuUv3yVdu77ZExqucGnEfUizgZJKq7992QK13qgKAaheTMd3pBMb67KqHP1pBMMfWWpeLQtlc3rAo/9rqjm+0KPgXCj58/2WDf7V0qLR/EILjydfjSOwdtNl133uuHN2rDsGU+6mW5lEgQxbotek6uEFWSFBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=c58RGE2ERgyfxrjuLs1Xwy31/tq6wTZ4OP4x6SzNVsrJvH9SPbdm0kRn5sg2xtLxigscRQYZa9IlVeUFtx2ojF6V5jhjiqN2yXpONVzQsDgDMOzShBn4BNLnH6VQYo4QaEDEgSmpE5TJNEHQUEuYBHpKT4rIUqBTRhzB9TcLYSk= Received: by 10.114.52.1 with SMTP id z1mr2144544waz.1175591801329; Tue, 03 Apr 2007 02:16:41 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Tue, 3 Apr 2007 02:16:41 -0700 (PDT) Message-ID: Date: Tue, 3 Apr 2007 13:16:41 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 91ef71ebdbd3a5a3 Cc: Subject: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 09:16:43 -0000 While porting mtpaint I stumbled upon a hacked up configure script which has a test like this: ld -o /dev/null If you run this under root the net result is you don't have /dev/null anymore. I fixed the configure script, writing to temp files instead of /dev/null, but the question is, how can I survive the situation. Without /dev/null very little works. You can mount a second devfs over the first one, but half of the programs running in the background (e.g. wmii) are still freaked out bad. So is there a way to revive the system without a reboot? (hint: /etc/rc.d/dev* scripts refuse to work without /dev/null) From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 09:29:52 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9344A16A401 for ; Tue, 3 Apr 2007 09:29:52 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5179813C465 for ; Tue, 3 Apr 2007 09:29:52 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1432162wxc for ; Tue, 03 Apr 2007 02:29:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Fuf/P+/o3oRYEn7XIg6r9avMsoad6kfCvokm7npd4TTYDyzsqcGQZvncrhpzkVCSJL2BphWje9b5UH8rTlAAkiLlXzdv5s5BS/3eVIlYUHCmEbx9oZfPBFzCet33grzwdxIJkPD4GzhCLznbVHKHRf3osW8vwgFxw+2LovT0ai8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gvd7SZeN70jG4IYx2aj0/KKa4ZNS4/+q9HKXDLwgyP4uTTwnKE8p7R/0dGI/O1xjWFGQ+vKwKMzY6Rp0BH1g5SxofcHcHMNrVgcurf9xqS8W7p+v+RiVUM2LoF6wRMKcqDwkVxZ4fOJEpwlYRRiyAE3rQ6K4hn5ZIV8aCvwB6uA= Received: by 10.114.12.9 with SMTP id 9mr2178306wal.1175592591072; Tue, 03 Apr 2007 02:29:51 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Tue, 3 Apr 2007 02:29:51 -0700 (PDT) Message-ID: Date: Tue, 3 Apr 2007 13:29:51 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "FreeBSD Current" , "Chin-San Huang" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: d8b29aad8a342bb5 Cc: Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 09:29:52 -0000 It appears chinsan blogged about this, but I can't understand much. I see you can work around this with mknod, which is nice. http://chinsan2.twbbs.org/wp/2007/02/05/20/ Chinsan, can I go ahead and commit the port? I have it in good working order. From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 09:50:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DE7416A402 for ; Tue, 3 Apr 2007 09:50:00 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by mx1.freebsd.org (Postfix) with ESMTP id F042D13C458 for ; Tue, 3 Apr 2007 09:49:59 +0000 (UTC) (envelope-from yal@yal.hopto.org) Received: from koala.unime.lan (87.18.101.132) by vsmtp4.tin.it (7.2.072.1) id 460BC759005EBF7B for freebsd-current@freebsd.org; Tue, 3 Apr 2007 11:49:58 +0200 Received: from koala.unime.lan (localhost [127.0.0.1]) by koala.unime.lan (8.13.8/8.13.8) with ESMTP id l339kIKF013035; Tue, 3 Apr 2007 11:46:18 +0200 (CEST) (envelope-from yal@yal.hopto.org) Received: (from www@localhost) by koala.unime.lan (8.13.8/8.13.8/Submit) id l339kGD2013034; Tue, 3 Apr 2007 11:46:16 +0200 (CEST) (envelope-from yal@yal.hopto.org) X-Authentication-Warning: koala.unime.lan: www set sender to yal@yal.hopto.org using -f Received: from 192.167.105.85 (SquirrelMail authenticated user yal) by yal.hopto.org with HTTP; Tue, 3 Apr 2007 11:46:16 +0200 (CEST) Message-ID: <3674.192.167.105.85.1175593576.squirrel@yal.hopto.org> Date: Tue, 3 Apr 2007 11:46:16 +0200 (CEST) From: "yal" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Sam Fourman Jr." Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yal@yal.hopto.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 09:50:00 -0000 Hi, may be Florent Thoumie could help us better understand what's going on. And for how long native support for intel 3945abg wifi cards will be unavailable on FreeBSD 7. Bergamini's wpi module won't be loaded by the new -CURRENT kernels. -- -- San Jose, CA March 7, 2007 -- The inclusion of firmware for popular Intel wireless devices means that users of FreeBSD will have native wireless support for many Centrino-branded Intel PRO/Wireless devices without downloading additional software. This approval includes firmware for the Intel 2100, 2200BG, 2225BG, 2915ABG, and the 3945ABG devices. "These changes have already been committed to the development branch of the FreeBSD source code repository except for firmware for the 3945ABG, which is expected to happen fairly soon once that driver is ready for inclusion," said Florent Thoumie, a FreeBSD developer working on this project. In order to use the firmware provided by Intel, FreeBSD users must first agree with the license. FreeBSD developers have added a simple mechanism to the operating system to agree to the license by defining an easy-to-use system variable. -- -- On Tue, April 3, 2007 10:22, Sam Fourman Jr. wrote: > Thank you for your Feedback > > I never Tried it in -current I ran 6.2 Stable, Benjamin Close is > working on a Driver however he hasn't updated his site in over a From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 10:10:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64A3916A405; Tue, 3 Apr 2007 10:10:40 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id EA5EB13C4AD; Tue, 3 Apr 2007 10:10:39 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l339xuca098462; Tue, 3 Apr 2007 11:59:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l339xn1w051495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 11:59:49 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l339xnsA001308; Tue, 3 Apr 2007 11:59:49 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l339xner001307; Tue, 3 Apr 2007 11:59:49 +0200 (CEST) (envelope-from ticso) Date: Tue, 3 Apr 2007 11:59:49 +0200 From: Bernd Walter To: Andrew Pantyukhin Message-ID: <20070403095948.GL80382@cicely12.cicely.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 10:10:40 -0000 On Tue, Apr 03, 2007 at 01:16:41PM +0400, Andrew Pantyukhin wrote: > While porting mtpaint I stumbled upon a hacked up > configure script which has a test like this: > > ld -o /dev/null > > If you run this under root the net result is you > don't have /dev/null anymore. > > I fixed the configure script, writing to temp files > instead of /dev/null, but the question is, how can > I survive the situation. > > Without /dev/null very little works. You can mount > a second devfs over the first one, but half of the > programs running in the background (e.g. wmii) are > still freaked out bad. > > So is there a way to revive the system without a > reboot? (hint: /etc/rc.d/dev* scripts refuse to > work without /dev/null) mknod -c 0 0 /dev/null -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 11:04:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 657BB16A407; Tue, 3 Apr 2007 11:04:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id B6DD913C4B7; Tue, 3 Apr 2007 11:04:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D3AAE48804; Tue, 3 Apr 2007 13:04:33 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0AC0E45684; Tue, 3 Apr 2007 13:04:28 +0200 (CEST) Date: Tue, 3 Apr 2007 13:04:26 +0200 From: Pawel Jakub Dawidek To: Eric Anderson Message-ID: <20070403110426.GD40062@garage.freebsd.pl> References: <460FDEF2.2060203@centtech.com> <20070401180125.GE25661@garage.freebsd.pl> <46119C4B.3020200@centtech.com> <4611DE78.7050405@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AbQceqfdZEv+FvjW" Content-Disposition: inline In-Reply-To: <4611DE78.7050405@freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: geom_journal panic: wrong offset 500107860990 for sectorsize 512 - RESOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 11:04:35 -0000 --AbQceqfdZEv+FvjW Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 02, 2007 at 11:56:24PM -0500, Eric Anderson wrote: > Here is a patch that adds that functionality. Can be found here: >=20 > http://www.googlebit.com/freebsd/patches/gjournal_size_expression.patch >=20 > and attached. Thanks for the patch. I'd prefer to have such functionality as a part of libutil. Simlar to humanize_number(3), but the other way around. Some comments below. > + * Convert an expression of the following forms to a uintmax_t. > + * 1) A positive decimal number. > + * 2) A positive decimal number followed by a 'b' or 'B' (mult by 512). Why? If I give '-s 1024B' it means I want 1024 bytes, not 1024*512 bytes. I would multiply by 512 if I receive number of sectors or something. My suggestion is to accept 'b' and 'B', but ignore it (or multiply by 1). > + * 3) A positive decimal number followed by a 'k' or 'K' (mult by 1 << 1= 0). > + * 4) A positive decimal number followed by a 'm' or 'M' (mult by 1 << 2= 0). > + * 5) A positive decimal number followed by a 'g' or 'G' (mult by 1 << 3= 0). I'd add 't' and 'T' as well. > + * 5) A positive decimal number followed by a 'w' or 'W' (mult by sizeof= int). I suggest dropping it, I don't really see a use for it... > + */ > +intmax_t > +gctl_get_numexpr(struct gctl_req *req, const char *pfmt, ...) > +{ > + const char *val; > + va_list ap; > + uintmax_t num, mult, prevnum; > + char *expr; > + > + va_start(ap, pfmt); > + val =3D gctl_get_param(req, 0, pfmt, ap); > + > + num =3D strtouq(val, &expr, 0); > + > + if (expr =3D=3D val) /* No valid digits. */ > + printf("illegal numeric value\n"); > + > + mult =3D 0; > + switch (*expr) { > + case 'B': > + case 'b': > + mult =3D 512; > + break; > + case 'K': > + case 'k': > + mult =3D 1 << 10; > + break; > + case 'M': > + case 'm': > + mult =3D 1 << 20; > + break; > + case 'G': > + case 'g': > + mult =3D 1 << 30; > + break; > + case 'W': > + case 'w': > + mult =3D sizeof(int); > + break; > + default: > + ; > + } > + > + if (mult !=3D 0) { Maybe just set mult to 1 by default and drop this check? > + prevnum =3D num; > + num *=3D mult; > + /* Check for overflow. */ > + if (num / mult !=3D prevnum) > + printf("overflow in argument\n"); > + expr++; > + } --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --AbQceqfdZEv+FvjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGEjS6ForvXbEpPzQRAv8PAJ9VE9tu7Ds5z+NXp4dpkDFiV9bfZQCfalRB AdS1WlNOR9oTO926z5mJtqo= =WMPQ -----END PGP SIGNATURE----- --AbQceqfdZEv+FvjW-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 08:11:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA8EA16A40F for ; Tue, 3 Apr 2007 08:11:48 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id AECBB13C4BA for ; Tue, 3 Apr 2007 08:11:47 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l338BfSR012846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 09:11:43 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <46120C3F.2070802@unsane.co.uk> Date: Tue, 03 Apr 2007 09:11:43 +0100 From: Vince User-Agent: Thunderbird 1.5.0.10 (X11/20070327) MIME-Version: 1.0 To: "Sam Fourman Jr." References: <3763.87.18.101.132.1175524536.squirrel@yal.hopto.org> <11167f520704022230l5ca20144u13a5706157628f99@mail.gmail.com> In-Reply-To: <11167f520704022230l5ca20144u13a5706157628f99@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 03 Apr 2007 11:29:09 +0000 Cc: freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 08:11:49 -0000 It doesnt seem to compile in current (as of yesterday anyway) however. I believe that Benjamin Close is working on a newer driver at http://www.clearchain.com/wiki/Wpi This one (well the version in perforce anyway) compiles but doesnt attach correctly. Hopefully Benjamin will have time to work on it again soon. Vince Sam Fourman Jr. wrote: > I just wanted to report that I have used this Driver Everyday for over a > month > http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz > > someone posted awhile back I have Tried several Driver even newer ones > and they all fail for me > > it works well and it does support wep I have tested it with FreeBSD > 6.2 STABLE (March 2007 snapshot) > > to install Just extract the driver > #make > #make install > then edit your /boot/loader.conf > and you are ready to go > > I haven't seen any updates to the wpi driver in awhile and I wanted > to ask what others thought of this driver Would it not be great to > have this in -current. > > for what it is worth I am using a Lenovo 3000 N 768-dku notebook > > also would someone be able to mirror this Driver > > > Sam Fourman Jr. > > > On 4/2/07, yal wrote: >> Hi, >> >> Are there any schedules for a new official driver for the Intel 3945? >> I've been unable to run the old beta wpi driver on -CURRENT for weeks >> now! >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 10:51:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D16E16A405 for ; Tue, 3 Apr 2007 10:51:41 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id A3B4513C45A for ; Tue, 3 Apr 2007 10:51:40 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l33ApaAI014857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 11:51:37 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <461231BA.8030805@unsane.co.uk> Date: Tue, 03 Apr 2007 11:51:38 +0100 From: Vince User-Agent: Thunderbird 1.5.0.10 (X11/20070327) MIME-Version: 1.0 To: yal@yal.hopto.org References: <3674.192.167.105.85.1175593576.squirrel@yal.hopto.org> In-Reply-To: <3674.192.167.105.85.1175593576.squirrel@yal.hopto.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 03 Apr 2007 11:31:19 +0000 Cc: "Sam Fourman Jr." , freebsd-current@freebsd.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 10:51:41 -0000 yal wrote: > Hi, > > may be Florent Thoumie could help us better understand what's going on. > And for how long native support for intel 3945abg wifi cards will be > unavailable on FreeBSD 7. > Bergamini's wpi module won't be loaded by the new -CURRENT kernels. > I have the feeling Florent has his work cut out with other projects such as modular X and other ports related work, (although I see he did some work on the perforce wpi driver.) I think the project he was working on was getting the firmwares relicensed rather than developing the wpi driver directly. Of course i'd be happy to be proved wrong. Vince > -- -- > San Jose, CA March 7, 2007 -- The inclusion of firmware for popular Intel > wireless devices means that users of FreeBSD will have native wireless > support for many Centrino-branded Intel PRO/Wireless devices without > downloading additional software. This approval includes firmware for the > Intel 2100, 2200BG, 2225BG, 2915ABG, and the 3945ABG devices. > > "These changes have already been committed to the development branch of > the FreeBSD source code repository except for firmware for the 3945ABG, > which is expected to happen fairly soon once that driver is ready for > inclusion," said Florent Thoumie, a FreeBSD developer working on this > project. > > In order to use the firmware provided by Intel, FreeBSD users must first > agree with the license. FreeBSD developers have added a simple mechanism > to the operating system to agree to the license by defining an easy-to-use > system variable. > > -- -- > > On Tue, April 3, 2007 10:22, Sam Fourman Jr. wrote: >> Thank you for your Feedback >> >> I never Tried it in -current I ran 6.2 Stable, Benjamin Close is >> working on a Driver however he hasn't updated his site in over a From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 13:43:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED4A016A40D for ; Tue, 3 Apr 2007 13:43:05 +0000 (UTC) (envelope-from chinsan.tw@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id AB2B813C484 for ; Tue, 3 Apr 2007 13:43:05 +0000 (UTC) (envelope-from chinsan.tw@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1683251ana for ; Tue, 03 Apr 2007 06:43:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ivGl5YiM+Kv9ZeqHm5l2wGRCJYaCZAtLjFSTc6KdN0DavIcZCLK/Hh8B9z9czqsSb2HsqDEaLKQPkYDheNT4/h5g8R8H5UVgowKJ3DH9a7nw3ci3jpF+hDp8LFgKNiyY5Vo/XUj35S2I7RcUl8Jrd4s7iUNQlXvNiBcqPoq/Kl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n/Yu2gIYULxwj/iVrZfOW1rLeL8xTp8KemzUj7UexSBApSGfeAvjhkbRH0e07c7ExZ74l8tZ+lQKhKFCoLknFYw8WlrfCJatpb6jvRdC5/Ui0r2KnCRQY1YspKXXtAFgZo+mxGnzM0nbNnYtJNvKNmM74m4Pdk//u+nihydaNxM= Received: by 10.100.121.12 with SMTP id t12mr4312689anc.1175606322216; Tue, 03 Apr 2007 06:18:42 -0700 (PDT) Received: by 10.100.112.8 with HTTP; Tue, 3 Apr 2007 06:18:42 -0700 (PDT) Message-ID: <1f27304c0704030618o4b9567e9kb2d9bf2407c5e253@mail.gmail.com> Date: Tue, 3 Apr 2007 21:18:42 +0800 From: chinsan To: "Andrew Pantyukhin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Mailman-Approved-At: Tue, 03 Apr 2007 13:51:55 +0000 Cc: Chin-San Huang , FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 13:43:06 -0000 2007/4/3, Andrew Pantyukhin : > It appears chinsan blogged about this, but I can't > understand much. I see you can work around this with > mknod, which is nice. It's very easy to solve whit mknod(8). ex: mknod /dev/null c 0 26 > http://chinsan2.twbbs.org/wp/2007/02/05/20/ > > Chinsan, can I go ahead and commit the port? I > have it in good working order. Please go ahead and commit them, thanks! - chinsan From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 14:32:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B98716A404 for ; Tue, 3 Apr 2007 14:32:41 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 8B34213C484 for ; Tue, 3 Apr 2007 14:32:39 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 29185 invoked from network); 3 Apr 2007 14:32:38 -0000 Received: from unknown (HELO ?192.168.2.5?) (192.168.2.5) by andxor.it with SMTP; 3 Apr 2007 14:32:38 -0000 Message-ID: <46126585.8080204@FreeBSD.org> Date: Tue, 03 Apr 2007 16:32:37 +0200 From: Alex Dupre User-Agent: Mozilla Thunderbird 1.5.0.10 (X11/20070317) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 14:32:41 -0000 Hello, I found an incorrect behavior of the targ device on -CURRENT: closing the descriptor doesn't return. On -STABLE it works. I think to have identified the problem (or at least the change that exposed it) in the conditional msleep() call added into kern_conf.c to destroy_devl() in rev. 1.119. This is a simple testcase: #include #include int main(int argc, char *argv[]) { int targ_fd = open("/dev/targ0", O_RDWR); if (targ_fd < 0) err(1, "Do you have 'device targ' in your kernel?"); close(targ_fd); } -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 15:33:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14C4016A405; Tue, 3 Apr 2007 15:33:15 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id CE2A213C43E; Tue, 3 Apr 2007 15:33:14 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l33FXCEP024462; Tue, 3 Apr 2007 10:33:12 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461273B8.3050106@freebsd.org> Date: Tue, 03 Apr 2007 10:33:12 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <460FDEF2.2060203@centtech.com> <20070401180125.GE25661@garage.freebsd.pl> <46119C4B.3020200@centtech.com> <4611DE78.7050405@freebsd.org> <20070403110426.GD40062@garage.freebsd.pl> In-Reply-To: <20070403110426.GD40062@garage.freebsd.pl> Content-Type: multipart/mixed; boundary="------------000108020003090802050502" X-Virus-Scanned: ClamAV 0.88.4/3007/Tue Apr 3 07:26:03 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: geom_journal panic: wrong offset 500107860990 for sectorsize 512 - RESOLVED X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 15:33:15 -0000 This is a multi-part message in MIME format. --------------000108020003090802050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/03/07 06:04, Pawel Jakub Dawidek wrote: > On Mon, Apr 02, 2007 at 11:56:24PM -0500, Eric Anderson wrote: >> Here is a patch that adds that functionality. Can be found here: >> >> http://www.googlebit.com/freebsd/patches/gjournal_size_expression.patch >> >> and attached. > > Thanks for the patch. I'd prefer to have such functionality as a part of > libutil. Simlar to humanize_number(3), but the other way around. > Some comments below. Like this: http://www.googlebit.com/freebsd/patches/libutil-unhumanized.patch (and attached) >> + * Convert an expression of the following forms to a uintmax_t. >> + * 1) A positive decimal number. >> + * 2) A positive decimal number followed by a 'b' or 'B' (mult by 512). > > Why? If I give '-s 1024B' it means I want 1024 bytes, not 1024*512 > bytes. I would multiply by 512 if I receive number of sectors or > something. My suggestion is to accept 'b' and 'B', but ignore it (or > multiply by 1). Yes, true. B should mean bytes, not blocks.. [FIXED] >> + * 3) A positive decimal number followed by a 'k' or 'K' (mult by 1 << 10). >> + * 4) A positive decimal number followed by a 'm' or 'M' (mult by 1 << 20). >> + * 5) A positive decimal number followed by a 'g' or 'G' (mult by 1 << 30). > > I'd add 't' and 'T' as well. [ADDED] >> + * 5) A positive decimal number followed by a 'w' or 'W' (mult by sizeof int). > > I suggest dropping it, I don't really see a use for it... [REMOVED] New gjournal patch is here: http://www.googlebit.com/freebsd/patches/gjournal_size_expression-libutil.patch (and attached) It now also needs the libutil patch above. The man page for the unhumanize_number function is crude, so it should be looked over also. Comments please!! Eric --------------000108020003090802050502 Content-Type: text/x-patch; name="gjournal_size_expression-libutil.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gjournal_size_expression-libutil.patch" Index: class/journal/Makefile =================================================================== RCS file: /alt/ncvs/src/sbin/geom/class/journal/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- class/journal/Makefile 10 Feb 2007 17:59:46 -0000 1.2 +++ class/journal/Makefile 3 Apr 2007 12:41:17 -0000 @@ -6,7 +6,7 @@ SRCS+= geom_journal_ufs.c DPADD= ${LIBMD} ${LIBUFS} -LDADD= -lmd -lufs +LDADD= -lmd -lufs -lutil CFLAGS+=-I${.CURDIR}/../../../../sys Index: class/journal/geom_journal.c =================================================================== RCS file: /alt/ncvs/src/sbin/geom/class/journal/geom_journal.c,v retrieving revision 1.2 diff -u -r1.2 geom_journal.c --- class/journal/geom_journal.c 1 Nov 2006 09:22:33 -0000 1.2 +++ class/journal/geom_journal.c 3 Apr 2007 04:49:28 -0000 @@ -66,7 +66,7 @@ { 'c', "checksum", NULL, G_TYPE_BOOL }, { 'f', "force", NULL, G_TYPE_BOOL }, { 'h', "hardcode", NULL, G_TYPE_BOOL }, - { 's', "jsize", &default_jsize, G_TYPE_NUMBER }, + { 's', "jsize", &default_jsize, G_TYPE_STRING }, G_OPT_SENTINEL }, "[-cfhv] [-s jsize] dataprov [jprov]" @@ -174,7 +174,7 @@ } data = gctl_get_ascii(req, "arg0"); - jsize = gctl_get_intmax(req, "jsize"); + jsize = gctl_get_numexpr(req, "jsize"); journal = NULL; switch (nargs) { case 1: Index: misc/subr.c =================================================================== RCS file: /alt/ncvs/src/sbin/geom/misc/subr.c,v retrieving revision 1.7 diff -u -r1.7 subr.c --- misc/subr.c 25 Jan 2007 11:35:27 -0000 1.7 +++ misc/subr.c 3 Apr 2007 13:10:41 -0000 @@ -42,6 +42,7 @@ #include #include #include +#include #include "misc/subr.h" @@ -377,6 +378,21 @@ return (*p); } +intmax_t +gctl_get_numexpr(struct gctl_req *req, const char *pfmt, ...) +{ + char *val; + int64_t num; + va_list ap; + + va_start(ap, pfmt); + val = gctl_get_param(req, 0, pfmt, ap); + + num = unhumanize_number((char *)val); +printf("was: %s now: %jd\n", val, num); + return (num); +} + const char * gctl_get_ascii(struct gctl_req *req, const char *pfmt, ...) { Index: misc/subr.h =================================================================== RCS file: /alt/ncvs/src/sbin/geom/misc/subr.h,v retrieving revision 1.8 diff -u -r1.8 subr.h --- misc/subr.h 25 Jan 2007 11:35:27 -0000 1.8 +++ misc/subr.h 3 Apr 2007 04:21:36 -0000 @@ -44,6 +44,7 @@ void gctl_error(struct gctl_req *req, const char *error, ...) __printflike(2, 3); int gctl_get_int(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); intmax_t gctl_get_intmax(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); +intmax_t gctl_get_numexpr(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); const char *gctl_get_ascii(struct gctl_req *req, const char *pfmt, ...) __printflike(2, 3); int gctl_change_param(struct gctl_req *req, const char *name, int len, const void *value); --------------000108020003090802050502 Content-Type: text/x-patch; name="libutil-unhumanized.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libutil-unhumanized.patch" Index: Makefile =================================================================== RCS file: /alt/ncvs/src/lib/libutil/Makefile,v retrieving revision 1.63 diff -u -r1.63 Makefile --- Makefile 27 Jul 2006 12:36:46 -0000 1.63 +++ Makefile 3 Apr 2007 13:34:31 -0000 @@ -12,7 +12,7 @@ login_auth.c login_cap.c login_class.c login_crypt.c login_ok.c \ login_times.c login_tty.c logout.c logwtmp.c \ pidfile.c property.c pty.c pw_util.c realhostname.c stub.c \ - trimdomain.c uucplock.c + trimdomain.c unhumanize_number.c uucplock.c INCS= libutil.h login_cap.h CFLAGS+= -DLIBC_SCCS @@ -27,7 +27,7 @@ login_cap.3 login_class.3 login_times.3 login_ok.3 \ _secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \ realhostname_sa.3 trimdomain.3 fparseln.3 humanize_number.3 \ - pidfile.3 + unhumanize_number.3 pidfile.3 MAN+= login.conf.5 auth.conf.5 MLINKS+= kld.3 kld_isloaded.3 kld.3 kld_load.3 MLINKS+= property.3 properties_read.3 property.3 properties_free.3 Index: libutil.h =================================================================== RCS file: /alt/ncvs/src/lib/libutil/libutil.h,v retrieving revision 1.42 diff -u -r1.42 libutil.h --- libutil.h 18 Feb 2006 11:25:28 -0000 1.42 +++ libutil.h 3 Apr 2007 13:05:16 -0000 @@ -81,6 +81,7 @@ struct termios *_termp, struct winsize *_winp); int humanize_number(char *_buf, size_t _len, int64_t _number, const char *_suffix, int _scale, int _flags); +int64_t unhumanize_number(char *_buf); const char *uu_lockerr(int _uu_lockresult); int uu_lock(const char *_ttyname); int uu_unlock(const char *_ttyname); --- /dev/null Tue Apr 3 10:24:54 2007 +++ unhumanize_number.c Tue Apr 3 08:10:34 2007 @@ -0,0 +1,91 @@ +/*- + * Copyright (c) 2007 + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include + +#include +#include +#include +#include +#include +#include +#include + + +/* + * Convert an expression of the following forms to a int64_t. + * 1) A positive decimal number. + * 2) A positive decimal number followed by a 'b' or 'B' (mult by 1). + * 3) A positive decimal number followed by a 'k' or 'K' (mult by 1 << 10). + * 4) A positive decimal number followed by a 'm' or 'M' (mult by 1 << 20). + * 5) A positive decimal number followed by a 'g' or 'G' (mult by 1 << 30). + * 6) A positive decimal number followed by a 't' or 'T' (mult by 1 << 40). + */ +int64_t +unhumanize_number(char *val) +{ + int64_t *prevnum, number; + int64_t mult; + char *expr; + + number = strtoumax(val, &expr, 0); + + if (expr == val) /* No valid digits. */ + printf("illegal numeric value\n"); + + mult = 0; + switch (*expr) { + case 'B': + case 'b': + mult = 1; + break; + case 'K': + case 'k': + mult = 1 << 10; + break; + case 'M': + case 'm': + mult = 1 << 20; + break; + case 'G': + case 'g': + mult = 1 << 30; + break; + case 'T': + case 't': + mult = 1 << 30; + mult *= 1024; + break; + default: + ; + } + + if (mult != 0) { + number *= mult; + } + + return (number); +} --- /dev/null Tue Apr 3 10:24:54 2007 +++ unhumanize_number.3 Tue Apr 3 08:35:18 2007 @@ -0,0 +1,50 @@ +.\" +.\" +.Dd April 3, 2007 +.Dt UNHUMANIZE_NUMBER 3 +.Os +.Sh NAME +.Nm unhumanize_number +.Nd format a number from human readable form +.Sh LIBRARY +.Lb libutil +.Sh SYNOPSIS +.In libutil.h +.Ft int64_t +.Fo unhumanize_number +.Fa "char *buf" +.Fc +.Sh DESCRIPTION +The +.Fn unhumanize_number +function unformats the +.Fa buffer . +and returns a signed 64-bit quantity. +.Pp +The +.Fn unhumanize_number +function +follows the SI power of two convention. +.Pp +The prefixes are: +.Bl -column "Prefix" "Description" "1000000000000000000" -offset indent +.It Sy "Prefix" Ta Sy "Description" Ta Sy "Multiplier" +.It Li k Ta No kilo Ta 1024 +.It Li M Ta No mega Ta 1048576 +.It Li G Ta No giga Ta 1073741824 +.It Li T Ta No tera Ta 1099511627776 +.It Li P Ta No peta Ta 1125899906842624 +.It Li E Ta No exa Ta 1152921504606846976 +.El + +.Sh RETURN VALUES +The +.Fn unhumanize_number +function returns the number calculated from the suffix appended +to the +.Fa buffer +.Sh HISTORY +The +.Fn unhumanize_number +function first appeared in +.Fx 7.0 . --------------000108020003090802050502-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 16:17:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4ED1A16A4CF; Tue, 3 Apr 2007 16:17:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 07BA113C4BD; Tue, 3 Apr 2007 16:17:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l33GGxfT067039; Tue, 3 Apr 2007 10:17:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46127DF4.5080703@samsco.org> Date: Tue, 03 Apr 2007 10:16:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Alex Dupre References: <46126585.8080204@FreeBSD.org> In-Reply-To: <46126585.8080204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 03 Apr 2007 10:17:04 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 16:17:08 -0000 Alex Dupre wrote: > Hello, > I found an incorrect behavior of the targ device on -CURRENT: closing > the descriptor doesn't return. On -STABLE it works. I think to have > identified the problem (or at least the change that exposed it) in the > conditional msleep() call added into kern_conf.c to destroy_devl() in > rev. 1.119. > > This is a simple testcase: > > > #include > #include > > int > main(int argc, char *argv[]) > { > int targ_fd = open("/dev/targ0", O_RDWR); > > if (targ_fd < 0) > err(1, "Do you have 'device targ' in your kernel?"); > > close(targ_fd); > } > Are there any other console messages from the targ driver? Can you turn on CAMDEBUG and send us the trace of what is going on? Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 16:50:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4C7116A4E9 for ; Tue, 3 Apr 2007 16:50:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 38EEC13C44C for ; Tue, 3 Apr 2007 16:50:09 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HYmCQ-0008VA-9F; Tue, 03 Apr 2007 18:49:38 +0200 Message-ID: <461285A6.5010805@gwdg.de> Date: Tue, 03 Apr 2007 18:49:42 +0200 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070318) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070312045116.GA83433@cdnetworks.co.kr> <45F5C914.3000805@gwdg.de> <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> <46113CF2.6090009@gwdg.de> <20070403035845.GB7223@cdnetworks.co.kr> In-Reply-To: <20070403035845.GB7223@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 16:50:12 -0000 Pyun YongHyeon schrieb: > On Mon, Apr 02, 2007 at 07:27:14PM +0200, Rainer Hurling wrote: > > Pyun YongHyeon schrieb: > > >On Sat, Mar 31, 2007 at 05:01:18PM +0200, Rainer Hurling wrote: > > > > Thank you Pyun YongHyeon for the newest patch. I am running it with > > > > if_nfe.c and if_nfereg.h from 03/21/2007 and if_nfevar.h from > > > 03/19/2007 > on FreeBSD 7.0-CURRENT (i386) from today. > > > > > > > > boot -v gives me: > > > > nfe0: port 0xb000-0xb007 mem > > > > xfbef3000-0xfbef3fff,0xfbefa800-0xfbefa8ff,0 > > > > xfbefa400-0xfbefa40f irq 22 at device 8.0 on pci0 > > > > nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfbef3000 > > > > miibus0: on nfe0 > > > > ciphy0: PHY 1 on miibus0 > > > > ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > > > 1000baseT-FDX, auto > > > > nfe0: bpf attached > > > > nfe0: Ethernet address: 00:16:17:95:d9:7c > > > > nfe0: [MPSAFE] > > > > nfe0: [FILTER] > > > > > > > > > > > > Now there are no more warning from miibus0 :-) > > > > > > > > > >Thanks for testing. > > > > > > > Unfortunately at bigger network transfers I still observe the > > > previously > described watchdog timeouts: > > > > > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > nfe0: watchdog timeout (missed Tx interrupts) -- recovering > > > > ... > > > > > > > > During these timeouts I am not able to use my network ;-( > > > > > > > > I would be happy if I could help solving this problem. Let me know if I > > > > can test anything. > > > > > > > > > >Does nfe(4) use shared interrupt with other devices? > > >(Check 'vmstat -i' output.) > > > > > > #vmstat -i > > interrupt total rate > > irq1: atkbd0 10848 1 > > irq12: psm0 79500 7 > > irq14: ata0 102455 10 > > irq16: sym0 14 0 > > irq17: nvidia0 632579 61 > > irq21: pcm0 ohci0 30994 3 > > irq22: nfe0 ehci0 36673 3 > ^^^^^^^^^^ > > You use shared interrupt. :-( Yes, that's it. Both units are on the mainboard. In "man ehci(4)" I found: ------- BUGS The driver is not finished and is quite buggy. There is currently no support for isochronous transfers. ------- Possibly this could cause the observed "dropouts" of nfe0 from a few seconds till several minutes? > > > irq23: atapci1 143425 14 > > cpu0: timer 20480047 1999 > > cpu1: timer 20466044 1998 > > Total 41982579 4099 > > > > > > >Since the watchdog timeout error indicates you've had missing Tx > > >completion interrupts I guess you've lost Tx completion interrupts > > >under high systems loads. One of major changes in new nfe(4) was > > >switching to so-called adaptive polling and it is known to give better > > >performance. However it can loose interrupts under high system loads > > >(e.g. buildworld) and I guess there are two ways to fix the issue. > > > > > >1. Add MSI/MSI-X support. > > > I think this is the cleanest solution to the issue. But old > > > hardwares which has no MSI/MSI-X support and buggy PCI bridges may > > > have issues dealing with MSI/MSI-X. In addition, there is no public > > > documentation available for NVIDIA NICs and lack of MSI/MSI-X capable > > > hardwares make me hard to add MSI/MSI-X support. AFAIK, Shigeaki > > > Tagashira is working on supporting MSI/MSI-X.(CCed) > > > > dmesg shows on my MCP55 system: > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pcib0: HT Bridge at 0:5:0 has non-default MSI window 0xc02000a > > pcib0: HT Bridge at 0:5:1 has non-default MSI window 0x602000a > > pcib0: HT Bridge at 0:6:1 has non-default MSI window 0x0 > > pcib0: HT Bridge at 0:8:0 has non-default MSI window 0x75011 > > I'm not sure what non-default MSI window have influence on MSI > support code. Maybe jhb has better idea.(CCed) It was just a guess. > > pci0: at device 0.0 (no driver attached) > > > > A more comprehensive info of 'boot -v' you can find as attachement. I > > snipped a few lines because they are not necessary in this context (cpu, > > pcm0, ad, acd, ...). > > > > >2. polling(4) > > > Because polling(4) does not rely on timed-delivery of Tx interrupts > > > it would help in your case. > > > > Is polling in classical sense the right way for this new driver with > > 'adaptive polling'? > > > > I think you could be right when assuming inadequate MSI/MSI-X support > > for the MCP55 chipset. > > > > Personally I don't like polling(4) due to latency issues but it > seems that there is no easy way to work-around until nfe(4) get > working MSI/MSI-X support. > Alternatively, if you don't use USB at all you can completely > disable USBs and can avoid the use of shared interrupt with USB > devices. Is there a knob or option in driver nfe(4) I can use to try classical polling or any 'lower' mode of operation? Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 17:09:15 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3F216A403; Tue, 3 Apr 2007 17:09:15 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6895813C458; Tue, 3 Apr 2007 17:09:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l33GjRkc013694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 09:45:28 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46128475.9060602@FreeBSD.org> Date: Tue, 03 Apr 2007 09:44:37 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Pantyukhin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 17:09:15 -0000 Patch ld(1) to detect the condition and don't unlink the device node? -Maxim Andrew Pantyukhin wrote: > While porting mtpaint I stumbled upon a hacked up > configure script which has a test like this: > > ld -o /dev/null > > If you run this under root the net result is you > don't have /dev/null anymore. > > I fixed the configure script, writing to temp files > instead of /dev/null, but the question is, how can > I survive the situation. > > Without /dev/null very little works. You can mount > a second devfs over the first one, but half of the > programs running in the background (e.g. wmii) are > still freaked out bad. > > So is there a way to revive the system without a > reboot? (hint: /etc/rc.d/dev* scripts refuse to > work without /dev/null) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 17:17:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF4A316A402 for ; Tue, 3 Apr 2007 17:17:23 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0A513C45A for ; Tue, 3 Apr 2007 17:17:22 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 59865 invoked from network); 3 Apr 2007 16:50:41 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 3 Apr 2007 16:50:41 -0000 Message-ID: <461285E0.8000008@FreeBSD.org> Date: Tue, 03 Apr 2007 18:50:40 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Scott Long References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> In-Reply-To: <46127DF4.5080703@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 17:17:23 -0000 Scott Long wrote: > Are there any other console messages from the targ driver? Can you > turn on CAMDEBUG and send us the trace of what is going on? CAMDEBUG is already on, but simply opening/closing the targ device, without sending any ioctl to enable it, shouldn't produce any CAM message. I traced the kernel thread and I found that it doesn't return from the destroy_devl() function: csw->d_purge is NULL and dev->si_threadcount is '1'. The thread enters the following block (kern_conf.c, row 690) and never exits. while (dev->si_threadcount != 0) { /* Use unique dummy wait ident */ msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); } -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 18:17:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36D3516A406 for ; Tue, 3 Apr 2007 18:17:09 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 80D0F13C4B0 for ; Tue, 3 Apr 2007 18:17:08 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id D2FA038C24; Tue, 3 Apr 2007 20:17:06 +0200 (CEST) Date: Tue, 3 Apr 2007 20:17:06 +0200 From: Lars Engels To: "Michael W. Lucas" Message-ID: <20070403181704.GA33352@e.0x20.net> References: <20070403014557.GA36989@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20070403014557.GA36989@bewilderbeast.blackhelicopters.org> X-Editor: VIM - Vi IMproved 7.0 X-Operation-System: FreeBSD 5.5-RELEASE User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: pc cards not working in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 18:17:09 -0000 --ADZbWkCsHQ7r3kzd Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 02, 2007 at 09:45:57PM -0400, Michael W. Lucas wrote: >=20 > Hi, >=20 > i386 -current, brand new laptop, csup'd 1 Apr 2007, GENERIC kernel. >=20 > My cheap wi0 card worked fine on snap13, but when I insert it now I get: >=20 > Apr 2 21:30:38 stretchlimo kernel: CIS is too long -- truncating > Apr 2 21:30:38 stretchlimo kernel: pccard0: Card has no functions! > Apr 2 21:30:38 stretchlimo kernel: cbb0: PC Card card activation failed >=20 > I see that this cropped up around March 22, but it looks like jhb had > committed a patch to fix this (see > http://lists.freebsd.org/pipermail/freebsd-current/2007-March/070075.html= ). > Once again, I seem to be special. Lucky me! >=20 > Any suggestions? On my laptop I am also having issues with the recognition of pcmcia cards. Many weeks ago I tried several cards and 16-bit (pccard) cards worked but 32-bit ones (cardbus) did not. Thanks to a thread on mobile@ I was able to get those cards being recognized by changing the subbus number with pciconf. However this only worked with a 7-current kernel from january. With a recent one _nothing_ happens when I insert a card (16 or 32 bit) into the slot. No kernel message, no cracks from the speaker, nothing... Does someone has an explanation for this? Is it related to Michael's problem? Attached you find both kernel's dmesg outputs. Lars --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename=cardbus_debug Content-Transfer-Encoding: quoted-printable =3D=3D=3D sysctl =3D=3D=3D hw.cbb.start_memory: 2281701376 hw.cbb.start_16_io: 256 hw.cbb.start_32_io: 4096 hw.cbb.debug: 1 dev.cbb.0.%desc: RF5C476 PCI-CardBus Bridge dev.cbb.0.%driver: cbb dev.cbb.0.%location: slot=3D9 function=3D0 handle=3D\_SB_.PCI0.PCIB.CDB0 dev.cbb.0.%pnpinfo: vendor=3D0x1180 device=3D0x0476 subvendor=3D0x144d subd= evice=3D0xc504 class=3D0x060700 dev.cbb.0.%parent: pci5 dev.cbb.0.pribus: 5 dev.cbb.0.secbus: 6 dev.cbb.0.subbus: 7 dev.cardbus.0.%parent: cbb0 dev.pccard.0.%parent: cbb0 =3D=3D=3D dmesg of _not_ working kernel=3D=3D=3D Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #1: Sat Mar 31 18:27:38 CEST 2007 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.51-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Stepping =3D 8 Features=3D0xbfe9fbff Features2=3D0xc189> Cores per package: 2 real memory =3D 1063845888 (1014 MB) avail memory =3D 1027465216 (979 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI: RSDP @ 0x0xf7660/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x3f696086/0x0040 (v 1 PTLTD Capell00 0x06040000 LTP 0x00= 000000) ACPI: FACP @ 0x0x3f69ae20/0x0074 (v 1 INTEL CALISTGA 0x06040000 LOHR 0x00= 00005A) ACPI: DSDT @ 0x0x3f696c94/0x418C (v 1 INTEL CALISTGA 0x06040000 INTL 0x20= 050624) ACPI: FACS @ 0x0x3f69bfc0/0x0040 ACPI: APIC @ 0x0x3f69ae94/0x0068 (v 1 INTEL CALISTGA 0x06040000 LOHR 0x00= 00005A) ACPI: HPET @ 0x0x3f69aefc/0x0038 (v 1 INTEL CALISTGA 0x06040000 LOHR 0x00= 00005A) ACPI: MCFG @ 0x0x3f69af34/0x003C (v 1 INTEL CALISTGA 0x06040000 LOHR 0x00= 00005A) ACPI: APIC @ 0x0x3f69af70/0x0068 (v 1 PTLTD APIC 0x06040000 LTP 0x00= 000000) ACPI: BOOT @ 0x0x3f69afd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00= 000001) ACPI: SSDT @ 0x0x3f6960c6/0x04F6 (v 1 PmRef CpuPm 0x00003000 INTL 0x20= 050624) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=3D513036kB. ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 ACPI: SSDT @ 0x0x3f6969ba/0x0251 (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20= 050624) ACPI: SSDT @ 0x0x3f6965bc/0x0379 (v 1 PmRef Cpu0Cst 0x00003001 INTL 0x20= 050624) est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0x3f696c0b/0x0089 (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20= 050624) ACPI: SSDT @ 0x0x3f696935/0x0085 (v 1 PmRef Cpu1Cst 0x00003000 INTL 0x20= 050624) est1: on cpu1 p4tcc1: on cpu1 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817f= fff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 o= n pci0 pcm0: mem 0xd8240000-0xd824= 3fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8444000-0xd84443f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered rum0: on uhub4 rum0: Ralink 802.11 bg WLAN, rev 2.00/0.01, addr 2 rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, address 00:19:5b:6d:a4:da rum0: firmware loaded: name: rt2573, size:2048 rum0: using obsoleted if_watchdog interface rum0: Ethernet address: 00:19:5b:6d:a4:da rum0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps rum0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 = at device 5.0 on pci5 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: using obsoleted if_watchdog interface bfe0: Ethernet address: 00:00:f0:7f:da:00 bfe0: [GIANT-LOCKED] bfe0: [ITHREAD] cbb0: at device 9.0 on pci5 cbb0: Found memory at e0000000 cbb0: Secondary bus is 0 cbb0: Setting primary bus to 5 cbb0: Secondary bus set to 6 subbus 7 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [GIANT-LOCKED] fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:20:0f:ab:79 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:0f:ab:79 fwe0: Ethernet address: 02:00:f0:0f:ab:79 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci5: at device 9.2 (no driver attached) pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 2000 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub2 Timecounters tick every 1.000 msec Status is 0x6000003 ad0: 69042MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 pcm0: pcm0: GEOM_LABEL: Label for provider ad0s2 is ntfs/Windows. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s3a =3D=3D=3D dmesg of working kernel =3D=3D=3D FreeBSD maggie.bsd-geek.de 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jan 14 0= 0:10:36 CET 2007 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/MAGGIE i= 386 Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #1: Sun Jan 14 00:10:36 CET 2007 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/MAGGIE WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. WARNING: MPSAFE network stack disabled, expect reduced performance. link_elf: symbol _sleep undefined KLD file pwc.ko - could not finalize loading ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.52-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Stepping =3D 8 Features=3D0xbfe9fbff Features2=3D0xc189> Cores per package: 2 real memory =3D 1063845888 (1014 MB) avail memory =3D 1031655424 (983 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=3D515084kB. kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817f= fff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] AGP at 0xd8100000 0MB info: [drm] Initialized i915 1.5.0 20060119 vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 o= n pci0 pcm0: mem 0xd8240000-0xd824= 3fff irq 22 at device 27.0 on pci0 pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8444000-0xd84443f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered usb4: handing over full speed device on port 5 to usb2 uhub4: port 5, device disappeared after reset pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 = at device 5.0 on pci5 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: using obsoleted if_watchdog interface bfe0: Ethernet address: 00:00:f0:7f:da:00 bfe0: [GIANT-LOCKED] cbb0: at device 9.0 on pci5 cbb0: Found memory at 80000000 cbb0: Secondary bus is 0 cbb0: Setting primary bus to 5 cbb0: Secondary bus set to 6 subbus 7 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:20:0f:ab:79 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:0f:ab:79 fwe0: Ethernet address: 02:00:f0:0f:ab:79 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci5: at device 9.2 (no driver attached) pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 2000 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub2 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, = default to accept, logging disabled Status is 0x30000006 ad0: 69042MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 pcm0: pcm0: SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed Trying to mount root from ufs:/dev/ad0s3a --Kj7319i9nmIyA2yE-- --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGEpogKc512sD3afgRAp54AKDA5Xw9jM6hCFo5gBZpUX6WCCwcpgCgyCNs FmsRpnraVjXtJ6XElqvhXpc= =eKSP -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 18:31:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A5DB16A46F for ; Tue, 3 Apr 2007 18:31:30 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 58B1C13C46A for ; Tue, 3 Apr 2007 18:31:30 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 03 Apr 2007 11:27:31 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l33IVTBC066508; Tue, 3 Apr 2007 11:31:29 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l33IVT7B066507; Tue, 3 Apr 2007 11:31:29 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200704031831.l33IVT7B066507@ambrisko.com> In-Reply-To: <46120C3F.2070802@unsane.co.uk> To: Vince Date: Tue, 3 Apr 2007 11:31:29 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: "Sam Fourman Jr." , freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 18:31:30 -0000 Vince writes: | It doesnt seem to compile in current (as of yesterday anyway) however. I | believe that Benjamin Close is working on a newer driver at | http://www.clearchain.com/wiki/Wpi This one (well the version in | perforce anyway) compiles but doesnt attach correctly. Hopefully | Benjamin will have time to work on it again soon. It also leaks mbuf clusters which I have a fix for. It attaches for me but has trouble RX packets over time when loaded. I haven't isolated the problem but I have an guess to test out. It looks like the packets are getting corrupted. Doug A. From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 18:35:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6150116A485 for ; Tue, 3 Apr 2007 18:35:28 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 208A313C4BB for ; Tue, 3 Apr 2007 18:35:28 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1795488ana for ; Tue, 03 Apr 2007 11:35:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hb7Xc5tM0gDSdB1fD1tVaEY3E+Mr7FD5grTnFiP2ulEoH1YOf7pYMesRfrlVIWaPmCG030ztNooVf/0FHKq9ANMnD0o0xsSxHqSfh0/ATAaCLcFHUdB5XyobeKesqR55aJfXIfjHaR1MZZV+jAAHHmdmj7dZzdNJBF1zFuAFB34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wjv9lvdLFeC3dJb+Fr0ws8SzfM4O/Y/CMJsnShf1dwKc3Fk2LNCaUAQGtF6TMwa6MMyYYtldzw57mms0/NCXzcL+temKCzsCHKePFej0d6BoWDerOBliwxQnEHEfZLV43WjPkIWVI64ocWPdpGy1lky6dLwVEP5bWRDWUCDy4ds= Received: by 10.100.168.13 with SMTP id q13mr4684011ane.1175625326300; Tue, 03 Apr 2007 11:35:26 -0700 (PDT) Received: by 10.100.48.8 with HTTP; Tue, 3 Apr 2007 11:35:26 -0700 (PDT) Message-ID: <11167f520704031135q3392bbben4f07f17768e0f3b7@mail.gmail.com> Date: Tue, 3 Apr 2007 13:35:26 -0500 From: "Sam Fourman Jr." To: "Doug Ambrisko" In-Reply-To: <200704031831.l33IVT7B066507@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46120C3F.2070802@unsane.co.uk> <200704031831.l33IVT7B066507@ambrisko.com> Cc: Vince , freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 18:35:28 -0000 do you have a diff that fixes the leaks? Sam Fourman Jr. On 4/3/07, Doug Ambrisko wrote: > Vince writes: > | It doesnt seem to compile in current (as of yesterday anyway) however. I > | believe that Benjamin Close is working on a newer driver at > | http://www.clearchain.com/wiki/Wpi This one (well the version in > | perforce anyway) compiles but doesnt attach correctly. Hopefully > | Benjamin will have time to work on it again soon. > > It also leaks mbuf clusters which I have a fix for. It attaches for > me but has trouble RX packets over time when loaded. I haven't isolated > the problem but I have an guess to test out. It looks like the packets are > getting corrupted. > > Doug A. > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 18:43:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3325C16A406 for ; Tue, 3 Apr 2007 18:43:08 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0347B13C480 for ; Tue, 3 Apr 2007 18:43:07 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 03 Apr 2007 11:39:09 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l33Ih7wB067182; Tue, 3 Apr 2007 11:43:07 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l33Ih7l3067181; Tue, 3 Apr 2007 11:43:07 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200704031843.l33Ih7l3067181@ambrisko.com> In-Reply-To: <11167f520704031135q3392bbben4f07f17768e0f3b7@mail.gmail.com> To: "Sam Fourman Jr." Date: Tue, 3 Apr 2007 11:43:07 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Vince , freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 18:43:08 -0000 Sam Fourman Jr. writes: | do you have a diff that fixes the leaks? Note he is working on a new version that deals with the new firmware that has a different API. ==== //depot/user/benjsc/wpi/sys/dev/wpi/if_wpi.c#16 - /data/home/ambrisko/p4/wpi/sys/dev/wpi/if_wpi.c ==== @@ -107,7 +107,10 @@ #ifdef WPI_DEBUG #define DPRINTF(x) do { if (wpi_debug != 0) printf x; } while (0) #define DPRINTFN(n, x) do { if (wpi_debug & n) printf x; } while (0) +/* int wpi_debug = 0xfffffffe; +*/ +int wpi_debug = 0; SYSCTL_INT(_debug, OID_AUTO, wpi, CTLFLAG_RW, &wpi_debug, 0, "wpi debug level"); enum { @@ -589,14 +592,14 @@ free( sc->sc_boot, M_DEVBUF ); - for (ac = 0; ac < 4; ac++) - wpi_free_tx_ring(sc, &sc->txq[ac]); - wpi_free_tx_ring(sc, &sc->cmdq); - wpi_free_tx_ring(sc, &sc->svcq); - wpi_free_rx_ring(sc, &sc->rxq); - wpi_free_rpool(sc); - wpi_free_shared(sc); } + for (ac = 0; ac < 4; ac++) + wpi_free_tx_ring(sc, &sc->txq[ac]); + wpi_free_tx_ring(sc, &sc->cmdq); + wpi_free_tx_ring(sc, &sc->svcq); + wpi_free_rx_ring(sc, &sc->rxq); + wpi_free_rpool(sc); + wpi_free_shared(sc); bus_teardown_intr(dev, sc->irq, sc->sc_ih); bus_release_resource(dev, SYS_RES_IRQ, sc->irq_rid, sc->irq); @@ -833,7 +836,11 @@ for (i = 0; i < WPI_RX_RING_COUNT; i++) { data = &ring->data[i]; +/* data->m = m_getcl(M_DONTWAIT, MT_DATA, 0); +*/ + data->m = NULL; + MGETHDR(data->m, M_DONTWAIT, MT_DATA); if (data->m == NULL) { device_printf(sc->sc_dev, "could not allocate rx mbuf\n"); @@ -850,8 +857,14 @@ } /* attach RxBuffer to mbuf */ + data->m->m_data = rbuf->vaddr; + data->m->m_len = data->m->m_pkthdr.len = WPI_RBUF_SIZE; +/* MEXTADD(data->m, rbuf->vaddr, WPI_RBUF_SIZE,wpi_free_rbuf, rbuf,EXT_NET_DRV,EXT_EXTREF); +*/ + MEXTADD(data->m, rbuf->vaddr, WPI_RBUF_SIZE, wpi_free_rbuf, + rbuf, 0, EXT_NET_DRV); if ((data->m->m_flags & M_EXT) == 0) { m_freem(data->m); return (ENOBUFS); @@ -1489,7 +1502,7 @@ struct wpi_rbuf *rbuf; struct ieee80211_frame *wh; struct ieee80211_node *ni; - struct mbuf *m, *mnew; + struct mbuf *m, *mnew = NULL; DPRINTFN(WPI_DEBUG_FUNC,("wpi_rx_intr\n")); @@ -1519,7 +1532,10 @@ return; } #endif +/* mnew = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); +*/ + MGETHDR(mnew, M_DONTWAIT, MT_DATA); if (mnew == NULL) { ifp->if_ierrors++; return; @@ -1532,7 +1548,13 @@ } /* attach Rx buffer to mbuf */ +/* MEXTADD(mnew,rbuf->vaddr,WPI_RBUF_SIZE,wpi_free_rbuf,rbuf,EXT_NET_DRV,EXT_EXTREF); +*/ + mnew->m_data = rbuf->vaddr; + mnew->m_len = mnew->m_pkthdr.len = WPI_RBUF_SIZE; + MEXTADD(mnew, rbuf->vaddr, WPI_RBUF_SIZE, wpi_free_rbuf, rbuf, + 0, EXT_NET_DRV); m = data->m; data->m = mnew; From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 19:15:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 696FA16A404 for ; Tue, 3 Apr 2007 19:15:02 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id F0E0F13C46E for ; Tue, 3 Apr 2007 19:15:01 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id l33IvwSN073610 for ; Tue, 3 Apr 2007 20:57:58 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2007 20:58:58 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ports do not start at 7 current as of today Thread-Index: Acd2IiJQc+75mnumRwK6SthMGCd8EQ== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 19:15:02 -0000 My installed ports (apache22, samba, cupsd, postgresql and ezjail) do = not start at boot time anymore. This is the output from rcorder /usr/local/etc/rc.d/* rcorder: file `/usr/local/etc/rc.d/ezjail.sh' is before unknown = provision `securelevel' rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/cupsd' has no = providers. /usr/local/etc/rc.d/cupsd rcorder: requirement `resolv' in file `/usr/local/etc/rc.d/samba' has no = providers. rcorder: requirement `ldconfig' in file `/usr/local/etc/rc.d/samba' has = no providers. rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/samba' has no = providers. rcorder: requirement `SERVERS' in file `/usr/local/etc/rc.d/samba' has = no providers. rcorder: requirement `NETWORKING' in file `/usr/local/etc/rc.d/samba' = has no providers. /usr/local/etc/rc.d/samba rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/postgresql' = has no providers. /usr/local/etc/rc.d/postgresql rcorder: requirement `sshd' in file `/usr/local/etc/rc.d/ezjail.sh' has = no providers. rcorder: requirement `cleanvar' in file `/usr/local/etc/rc.d/ezjail.sh' = has no providers. rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/ezjail.sh' has = no providers. /usr/local/etc/rc.d/ezjail.sh rcorder: requirement `cleanvar' in file `/usr/local/etc/rc.d/apache22' = has no providers. rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/apache22' has = no providers. /usr/local/etc/rc.d/apache22 I can start them without a problem by hand after the machine has = finisched booting. Have i missed something. regards, Johan From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 20:32:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A214716A409 for ; Tue, 3 Apr 2007 20:32:29 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD0913C4BA for ; Tue, 3 Apr 2007 20:32:28 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so437609ugh for ; Tue, 03 Apr 2007 13:32:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mwqCWv7Zp8U0hVdbhIEMs/iGTleREGDSNNTYHvOb+IFKZYoWI9E7xXj7BEcSgL+jCgzsjeZJnOCoch7HK0CD9p9J1xad8klHYvZg1sY00jbS+h98iCkiW62AuWQvpR1yzAVZNKacWb+Ib5c39P6s7x+BO7LyjYglOui/TwIQTXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j+v0GveHZ8asHFJq7BM/gzbqIvKUKHVeBjylahv8Wr5htFxb96v1iIY8p8oZB3d8Q72zWFMfIdpkiUBVrM7iac4sJkubTOp44Xq9OFLyWcQUEzXJg4h5+ZTiAJOTnpmU6iWctnCV6EU2LDOyCmYKX3LPJEtvdr/RsPepCQoS5Mk= Received: by 10.114.13.1 with SMTP id 1mr2428847wam.1175632346777; Tue, 03 Apr 2007 13:32:26 -0700 (PDT) Received: by 10.114.25.18 with HTTP; Tue, 3 Apr 2007 13:32:26 -0700 (PDT) Message-ID: <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> Date: Tue, 3 Apr 2007 13:32:26 -0700 From: "Matthew Jacob" To: "Alex Dupre" In-Reply-To: <461285E0.8000008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 20:32:29 -0000 Yeah- I've seen this too. On 4/3/07, Alex Dupre wrote: > Scott Long wrote: > > Are there any other console messages from the targ driver? Can you > > turn on CAMDEBUG and send us the trace of what is going on? > > CAMDEBUG is already on, but simply opening/closing the targ device, > without sending any ioctl to enable it, shouldn't produce any CAM > message. I traced the kernel thread and I found that it doesn't return > from the destroy_devl() function: csw->d_purge is NULL and > dev->si_threadcount is '1'. The thread enters the following block > (kern_conf.c, row 690) and never exits. > > > while (dev->si_threadcount != 0) { > /* Use unique dummy wait ident */ > msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > } > > > -- > Alex Dupre > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 21:35:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F15416A404; Tue, 3 Apr 2007 21:35:03 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E75C713C448; Tue, 3 Apr 2007 21:35:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l33LYpdm070116; Tue, 3 Apr 2007 15:34:56 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4612C873.1020505@samsco.org> Date: Tue, 03 Apr 2007 15:34:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Matthew Jacob References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> In-Reply-To: <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 03 Apr 2007 15:34:56 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, Alex Dupre Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 21:35:03 -0000 My guess is that the kninit() in targopen isn't being cleaned up from in targclose. I'm not terribly familiar in how the knote API works, though. Scott Matthew Jacob wrote: > Yeah- I've seen this too. > > On 4/3/07, Alex Dupre wrote: >> Scott Long wrote: >> > Are there any other console messages from the targ driver? Can you >> > turn on CAMDEBUG and send us the trace of what is going on? >> >> CAMDEBUG is already on, but simply opening/closing the targ device, >> without sending any ioctl to enable it, shouldn't produce any CAM >> message. I traced the kernel thread and I found that it doesn't return >> from the destroy_devl() function: csw->d_purge is NULL and >> dev->si_threadcount is '1'. The thread enters the following block >> (kern_conf.c, row 690) and never exits. >> >> >> while (dev->si_threadcount != 0) { >> /* Use unique dummy wait ident */ >> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); >> } >> >> >> -- >> Alex Dupre >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" >> From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 22:01:46 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2511516A402; Tue, 3 Apr 2007 22:01:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B869813C483; Tue, 3 Apr 2007 22:01:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3435147226; Tue, 3 Apr 2007 18:01:45 -0400 (EDT) Date: Tue, 3 Apr 2007 18:01:45 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20070401155910.O75869@fledge.watson.org> Message-ID: <20070403175953.A25236@fledge.watson.org> References: <20070401155910.O75869@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org, Andrzej Tobola Subject: Re: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 22:01:46 -0000 On Sun, 1 Apr 2007, Robert Watson wrote: > The attached patch moves file descriptor locks from being a custom > mutex/sleep lock implemented using msleep() to an sx lock. With the new sx > lock optimizations in place, this is now sensible, avoiding both a custom > lock type and significantly improving performance. Kris has reported 2x-4x > improvement in transactions/sec with MySQL using this patch, as it greatly > reduces the cost of lock contention during file descriptor lookup for > threaded applications, and also moves to shared locking to avoid exclusive > acquisition for read-only operations (the vast majority in most workloads). > Patch is below, but you can also download from: > > http://www.watson.org/~robert/freebsd/netperf/20070401a-filedesc-sx.diff > > I'm currently waiting for the sx lock changes to settle for a few days > before committing, so will plan to commit this around Wednesday/Thursday of > this week (unless serious problems arise). Andrzej has pointed out that shortly after I posted the patch, it came into conflict with changes in VFS. I've updated the patch and posted it at: http://www.watson.org/~robert/freebsd/netperf/20070403-filedesc-sx.diff Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 22:26:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D31716A403; Tue, 3 Apr 2007 22:26:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DD71913C448; Tue, 3 Apr 2007 22:26:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l33MQiHl070411; Tue, 3 Apr 2007 16:26:49 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4612D49C.8040100@samsco.org> Date: Tue, 03 Apr 2007 16:26:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Matthew Jacob References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> <4612C873.1020505@samsco.org> In-Reply-To: <4612C873.1020505@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 03 Apr 2007 16:26:50 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 22:26:53 -0000 Actually, I think it's a wildly incorrect use of the clone API. I'll take a look at in the in next few days and try to commit something that works. Scott Scott Long wrote: > My guess is that the kninit() in targopen isn't being cleaned up from in > targclose. I'm not terribly familiar in how the knote API works, > though. > > Scott > > > Matthew Jacob wrote: >> Yeah- I've seen this too. >> >> On 4/3/07, Alex Dupre wrote: >>> Scott Long wrote: >>> > Are there any other console messages from the targ driver? Can you >>> > turn on CAMDEBUG and send us the trace of what is going on? >>> >>> CAMDEBUG is already on, but simply opening/closing the targ device, >>> without sending any ioctl to enable it, shouldn't produce any CAM >>> message. I traced the kernel thread and I found that it doesn't return >>> from the destroy_devl() function: csw->d_purge is NULL and >>> dev->si_threadcount is '1'. The thread enters the following block >>> (kern_conf.c, row 690) and never exits. >>> >>> >>> while (dev->si_threadcount != 0) { >>> /* Use unique dummy wait ident */ >>> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); >>> } >>> >>> >>> -- >>> Alex Dupre >>> _______________________________________________ >>> freebsd-scsi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" >>> > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 23:12:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9646E16A406 for ; Tue, 3 Apr 2007 23:12:20 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7B813C48C for ; Tue, 3 Apr 2007 23:12:20 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so9014wra for ; Tue, 03 Apr 2007 16:12:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tq87wcP92KCJ9xXgvYW1exZgQyq52R5JmcZBYefJkpcpzgOA/qzxbpB80tMR+LiFC3UogZWuaarBHoHIbk9nMm5DpJ30G9uRRp782aiihnMI+yAGDzsTXZKXO1szWP4L0CcJOAnwdFVUfFb2GhV/+UgeKHdUatxw/TBXY8XtTlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KRyccpZHEA6VcfjHbRZLZBU+9zJTO5euj3WhKDqMFdVI2slX/u0U4RP+Wk/++0Iy5iB6rCPz0jH/fMSpcarfNPVtwz9H8HMoEmr/+Nnz6w8rvCU/1Thb7CCpENe8ZZ48DBt49cYoALIM7P83abZslU5rgVpSex7/hSURhuG4+AQ= Received: by 10.115.106.7 with SMTP id i7mr2450060wam.1175641939033; Tue, 03 Apr 2007 16:12:19 -0700 (PDT) Received: by 10.114.25.18 with HTTP; Tue, 3 Apr 2007 16:12:18 -0700 (PDT) Message-ID: <7579f7fb0704031612m2b9ba127w2b411e4eecd706fa@mail.gmail.com> Date: Tue, 3 Apr 2007 16:12:18 -0700 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <4612C873.1020505@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> <4612C873.1020505@samsco.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, Alex Dupre Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 23:12:20 -0000 Neither am I. I had to fool around with this at one point to get it to work and it's probably gotten broken again as other parts of the kernel get more lock clean. Sigh. On 4/3/07, Scott Long wrote: > My guess is that the kninit() in targopen isn't being cleaned up from in > targclose. I'm not terribly familiar in how the knote API works, > though. > > Scott > > > Matthew Jacob wrote: > > Yeah- I've seen this too. > > > > On 4/3/07, Alex Dupre wrote: > >> Scott Long wrote: > >> > Are there any other console messages from the targ driver? Can you > >> > turn on CAMDEBUG and send us the trace of what is going on? > >> > >> CAMDEBUG is already on, but simply opening/closing the targ device, > >> without sending any ioctl to enable it, shouldn't produce any CAM > >> message. I traced the kernel thread and I found that it doesn't return > >> from the destroy_devl() function: csw->d_purge is NULL and > >> dev->si_threadcount is '1'. The thread enters the following block > >> (kern_conf.c, row 690) and never exits. > >> > >> > >> while (dev->si_threadcount != 0) { > >> /* Use unique dummy wait ident */ > >> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > >> } > >> > >> > >> -- > >> Alex Dupre > >> _______________________________________________ > >> freebsd-scsi@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > >> > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 23:12:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 033B116A408 for ; Tue, 3 Apr 2007 23:12:58 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBDB13C45E for ; Tue, 3 Apr 2007 23:12:57 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so9177wra for ; Tue, 03 Apr 2007 16:12:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tjoL3E9mEDa5ManOCQjAsh+puZ0ILuN+l/EN/yS/kAQyb6yIJNvwsEZzA+PI6S2hkMriEVXrbtAtL8bP+h88+iHkomiwrfPTp31kG6fQrq6mPv397qkq6vYWvvfQbPgqwTBbQe8oAG2Pso7/Uq0iYXuP2RE7TXqPB4WOuWXmD9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gk0oDdQdwm009G2oKxC5ZlGuLQv10sIx/4Qb/cdjO/C/p/gpL3pl5XT8a3GNw/KiSbM/zIv5opZEISKOO81FIufmgTpIf//CpLluyoj+an4uKWBJqPpxo+bsUtOD+Tzt/MkvkpAKTE2pgk/h6JGR7efO3/Rx/9ENdMzvJTlTuDM= Received: by 10.115.61.1 with SMTP id o1mr2467707wak.1175641976590; Tue, 03 Apr 2007 16:12:56 -0700 (PDT) Received: by 10.114.25.18 with HTTP; Tue, 3 Apr 2007 16:12:56 -0700 (PDT) Message-ID: <7579f7fb0704031612q354b1b57u9a36378736e235df@mail.gmail.com> Date: Tue, 3 Apr 2007 16:12:56 -0700 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <7579f7fb0704031612m2b9ba127w2b411e4eecd706fa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> <4612C873.1020505@samsco.org> <7579f7fb0704031612m2b9ba127w2b411e4eecd706fa@mail.gmail.com> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, Alex Dupre Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 23:12:58 -0000 I mean to say I'll put it on my list, but if others have a quick insight into fixing it that would be mucho appreciated. On 4/3/07, Matthew Jacob wrote: > Neither am I. I had to fool around with this at one point to get it to > work and it's probably gotten broken again as other parts of the > kernel get more lock clean. Sigh. > > On 4/3/07, Scott Long wrote: > > My guess is that the kninit() in targopen isn't being cleaned up from in > > targclose. I'm not terribly familiar in how the knote API works, > > though. > > > > Scott > > > > > > Matthew Jacob wrote: > > > Yeah- I've seen this too. > > > > > > On 4/3/07, Alex Dupre wrote: > > >> Scott Long wrote: > > >> > Are there any other console messages from the targ driver? Can you > > >> > turn on CAMDEBUG and send us the trace of what is going on? > > >> > > >> CAMDEBUG is already on, but simply opening/closing the targ device, > > >> without sending any ioctl to enable it, shouldn't produce any CAM > > >> message. I traced the kernel thread and I found that it doesn't return > > >> from the destroy_devl() function: csw->d_purge is NULL and > > >> dev->si_threadcount is '1'. The thread enters the following block > > >> (kern_conf.c, row 690) and never exits. > > >> > > >> > > >> while (dev->si_threadcount != 0) { > > >> /* Use unique dummy wait ident */ > > >> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > > >> } > > >> > > >> > > >> -- > > >> Alex Dupre > > >> _______________________________________________ > > >> freebsd-scsi@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > >> > > > > > From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 00:32:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34F8D16A505 for ; Wed, 4 Apr 2007 00:32:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC2B13C457 for ; Wed, 4 Apr 2007 00:32:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so500782ugh for ; Tue, 03 Apr 2007 17:32:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=UVB6SXRol3qM3jbGu+nsX7igKDdroIf0sBLOSbUWw2Kz8mnCcA1f9nM5Hy4grB9TKttGLh55EdlHklGuiiPVnKS7vAix0g8jQSR13x9uKxVUckd6Xc+dIYI5bColC+zAuxnhX2kloy/4T5DeyOJihZEOmurJoHpxyuGNu39vaUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ik62XNa2usjmE+3GWG9ujIy1TTx/uVZzQ8AafjV6ZxvEZqOunWJbC/s15efTug3+rCYJdYoCDWMJ/MtNLq9oQtIMLhMc1HtSqFL46gE6qYCWfZwwmG1BpOuwJe47dmH/dNpmnAdZI3u1zeXsz8JB42/nABLuU5B5X0gnRlMazL8= Received: by 10.114.197.1 with SMTP id u1mr2470waf.1175646722546; Tue, 03 Apr 2007 17:32:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id t1sm289832poh.2007.04.03.17.31.59; Tue, 03 Apr 2007 17:32:00 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l340WHxg011790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 09:32:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l340WFO2011789; Wed, 4 Apr 2007 09:32:15 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 4 Apr 2007 09:32:15 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070404003215.GA11525@cdnetworks.co.kr> References: <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> <46113CF2.6090009@gwdg.de> <20070403035845.GB7223@cdnetworks.co.kr> <461285A6.5010805@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461285A6.5010805@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 00:32:06 -0000 On Tue, Apr 03, 2007 at 06:49:42PM +0200, Rainer Hurling wrote: [...] > > In "man ehci(4)" I found: > > ------- > BUGS > The driver is not finished and is quite buggy. > There is currently no support for isochronous transfers. > ------- > > Possibly this could cause the observed "dropouts" of nfe0 from a few > seconds till several minutes? > I'm not familiar with ehci(4) but I think it has nothing to do with missing Tx completion interrupts observed on nfe(4). > > Is there a knob or option in driver nfe(4) I can use to try classical > polling or any 'lower' mode of operation? > Add 'options DEVICE_POLLING' into kernel configuration file and rebuild your kernel. Use ifconfig(8) to enable/disable polling(4) feature. See polling(4) for more detailed description and tuning parameters. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 01:39:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D5E216A401; Wed, 4 Apr 2007 01:39:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7280913C4B0; Wed, 4 Apr 2007 01:39:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l341dPj0000834; Tue, 3 Apr 2007 21:39:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l341dPiB060572; Tue, 3 Apr 2007 21:39:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C14373039; Tue, 3 Apr 2007 21:39:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070404013925.8C14373039@freebsd-current.sentex.ca> Date: Tue, 3 Apr 2007 21:39:25 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 01:39:26 -0000 TB --- 2007-04-04 00:29:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-04 00:29:50 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-04-04 00:29:50 - cleaning the object tree TB --- 2007-04-04 00:30:19 - checking out the source tree TB --- 2007-04-04 00:30:19 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-04-04 00:30:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-04 00:38:23 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-04 00:38:23 - cd /src TB --- 2007-04-04 00:38:23 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 4 00:38:24 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 4 01:32:17 UTC 2007 TB --- 2007-04-04 01:32:17 - generating LINT kernel config TB --- 2007-04-04 01:32:17 - cd /src/sys/pc98/conf TB --- 2007-04-04 01:32:17 - /usr/bin/make -B LINT TB --- 2007-04-04 01:32:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-04 01:32:17 - cd /src TB --- 2007-04-04 01:32:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 4 01:32:17 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sx.c /src/sys/kern/kern_sx.c: In function `_sx_sunlock': /src/sys/kern/kern_sx.c:276: error: `x' undeclared (first use in this function) /src/sys/kern/kern_sx.c:276: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_sx.c:276: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-04 01:39:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-04 01:39:25 - ERROR: failed to build lint kernel TB --- 2007-04-04 01:39:25 - tinderbox aborted TB --- 0.68 user 2.88 system 4174.50 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 22:29:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10BB916A401 for ; Tue, 3 Apr 2007 22:29:08 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id 8E37B13C4BA for ; Tue, 3 Apr 2007 22:29:07 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-AV: E=Sophos;i="4.14,366,1170595800"; d="scan'208";a="105856364" Received: from ppp37-253.lns4.adl2.internode.on.net (HELO mail.clearchain.com) ([121.44.37.253]) by ipmail02.adl2.internode.on.net with ESMTP; 04 Apr 2007 07:43:50 +0930 Received: from [192.168.155.249] ([192.168.155.249]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id l33MDhwT048853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 07:43:49 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <4612D192.1020406@clearchain.com> Date: Wed, 04 Apr 2007 07:43:38 +0930 From: Benjamin Close User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Doug Ambrisko References: <200704031843.l33Ih7l3067181@ambrisko.com> In-Reply-To: <200704031843.l33Ih7l3067181@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90/3007/Tue Apr 3 21:56:03 2007 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.155.1]); Wed, 04 Apr 2007 07:43:50 +0930 (CST) X-Mailman-Approved-At: Wed, 04 Apr 2007 02:15:09 +0000 Cc: "Sam Fourman Jr." , Vince , freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 22:29:08 -0000 Doug Ambrisko wrote: > Sam Fourman Jr. writes: > | do you have a diff that fixes the leaks? > > Note he is working on a new version that deals with the new firmware > that has a different API. > > The new firmware version should be hitting p4 in a day or so, then the cleanup will begin. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 04:23:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1AE416A401 for ; Wed, 4 Apr 2007 04:23:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6A813C43E for ; Wed, 4 Apr 2007 04:23:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l344Nlrf062264; Tue, 3 Apr 2007 23:23:47 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46132852.8090005@freebsd.org> Date: Tue, 03 Apr 2007 23:23:46 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: "M. Warner Losh" References: <461084EA.1000706@freebsd.org> <20070402.180446.1573371202.imp@bsdimp.com> <4611E26A.7010905@freebsd.org> <20070402.233439.-1548241370.imp@bsdimp.com> In-Reply-To: <20070402.233439.-1548241370.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3010/Tue Apr 3 20:57:44 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-current@freebsd.org Subject: Re: pccard flash card reader - no longer works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 04:23:50 -0000 On 04/03/07 00:34, M. Warner Losh wrote: > In message: <4611E26A.7010905@freebsd.org> > Eric Anderson writes: > : On 04/02/07 19:04, M. Warner Losh wrote: > : > In message: <461084EA.1000706@freebsd.org> > : > Eric Anderson writes: > : > : I've been using the same card reader for ages, with various cf cards. > : > : Yesterday, I noticed it no longer works. I know it worked around March > : > : 3rd-ish. Here's what I get: > : > : > : > : > : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : > : 0xecb00000-0xecbfffff: good > : > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS version PCCARD 2.0 or 2.1 > : > : Mar 31 21:10:50 neutrino kernel: pccard0: CIS info: Vendor, CF_Card, > : > : Mar 31 21:10:50 neutrino kernel: pccard0: Manufacturer code 0xa, product 0x0 > : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0: fixed disk, ccr > : > : addr 200 mask f > : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : > : 0: memory card; irq mask 0; mwait_required rdybsy_active powerdown > : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : > : 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; rdybsy_active io8 > : > : io16 irqshare irqpulse irqlevel p > : > : owerdown > : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : > : 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; > : > : rdybsy_active io8 io16 irqshare irqpuls > : > : e irqlevel powerdown > : > : Mar 31 21:10:50 neutrino kernel: pccard0: function 0, config table entry > : > : 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; > : > : rdybsy_active io8 io16 irqshare irqpuls > : > : e irqlevel powerdown > : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : > : 0xecb00000-0xecbfffff: good > : > : Mar 31 21:10:50 neutrino kernel: ata2: at port > : > : 0x910-0x91f irq 19 function 0 config 1 on pccard0 > : > : Mar 31 21:10:50 neutrino kernel: ata2: reset tp1 mask=00 ostat0=ff ostat1=00 > : > : Mar 31 21:10:50 neutrino kernel: ata2: [MPSAFE] > : > : Mar 31 21:10:50 neutrino kernel: ata2: [ITHREAD] > : > : Mar 31 21:10:50 neutrino kernel: pcib6: pccard0 requested memory range > : > : 0xecb00000-0xecbfffff: good > : > : > : > : > : > : The flash card works fine if I plug it in via a USB<->CF adapter. > : > : > : > : Any ideas? > : > > : > When did this last work? My quick test here shows it working on my > : > laptop. > : > > : > Warner > : > : > : I know it worked at the very beginning of the month (around March > : 2nd-ish). > : > : If there's a particular date to go back to, let me know and I can give > : it a try. > > If you know that April 1 didn't work, but March 2nd did, you might try > around March 15th. I don't know what broke things, so need a little > clue. > > Warner I'll try the binary search method as soon as I can find some time.. Eric From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 07:42:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E85FA16A402 for ; Wed, 4 Apr 2007 07:42:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id C8A7413C483 for ; Wed, 4 Apr 2007 07:42:35 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 458318639; Wed, 04 Apr 2007 09:42:29 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 4 Apr 2007 09:42:08 +0200 User-Agent: KMail/1.9.5 References: <20070401155910.O75869@fledge.watson.org> <20070403175953.A25236@fledge.watson.org> In-Reply-To: <20070403175953.A25236@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704040942.08839.hselasky@c2i.net> Cc: performance@freebsd.org, Robert Watson , current@freebsd.org, Andrzej Tobola Subject: Re: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 07:42:37 -0000 On Wednesday 04 April 2007 00:01, Robert Watson wrote: > On Sun, 1 Apr 2007, Robert Watson wrote: > > The attached patch moves file descriptor locks from being a custom > > mutex/sleep lock implemented using msleep() to an sx lock. With the new > > sx lock optimizations in place, this is now sensible, avoiding both a > > custom lock type and significantly improving performance. Kris has > > reported 2x-4x improvement in transactions/sec with MySQL using this > > patch, as it greatly reduces the cost of lock contention during file > > descriptor lookup for threaded applications, and also moves to shared > > locking to avoid exclusive acquisition for read-only operations (the vast > > majority in most workloads). Patch is below, but you can also download > > from: > > > > http://www.watson.org/~robert/freebsd/netperf/20070401a-filedesc-sx.diff > > > > I'm currently waiting for the sx lock changes to settle for a few days > > before committing, so will plan to commit this around Wednesday/Thursday > > of this week (unless serious problems arise). > > Andrzej has pointed out that shortly after I posted the patch, it came into > conflict with changes in VFS. I've updated the patch and posted it at: > > http://www.watson.org/~robert/freebsd/netperf/20070403-filedesc-sx.diff Just a small comment: @@ -60,10 +60,7 @@ u_short fd_cmask; /* mask for file creation */ u_short fd_refcnt; /* thread reference count */ u_short fd_holdcnt; /* hold count on structure + mutex */ - - struct mtx fd_mtx; /* protects members of this struct */ - int fd_locked; /* long lock flag */ - int fd_wanted; /* "" */ + struct sx fd_sx; /* protects members of this struct */ struct kqlist fd_kqlist; /* list of kqueues on this filedesc */ int fd_holdleaderscount; /* block fdfree() for shared close() */ int fd_holdleaderswakeup; /* fdfree() needs wakeup */ Maybe it is better if you order the elements by size. Then you don't waste so many extra bytes on platforms where the fields must be aligned. struct { struct sx fd_sx; struct kqlist fd_kqlist; int ...; u_short ....; }; --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 07:48:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78CA216A405 for ; Wed, 4 Apr 2007 07:48:22 +0000 (UTC) (envelope-from le@freebsd.org) Received: from grace.univie.ac.at (grace.univie.ac.at [131.130.3.115]) by mx1.freebsd.org (Postfix) with ESMTP id 0957913C4BC for ; Wed, 4 Apr 2007 07:48:22 +0000 (UTC) (envelope-from le@freebsd.org) Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.66) (envelope-from ) id 1HZ0E8-0004Ou-OM; Wed, 04 Apr 2007 09:48:20 +0200 Received: from korben.prv.univie.ac.at ([131.130.7.98]) by joan.univie.ac.at with esmtps (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HZ0E8-0002Gw-8U; Wed, 04 Apr 2007 09:48:20 +0200 Message-ID: <46135841.1010902@freebsd.org> Date: Wed, 04 Apr 2007 09:48:17 +0200 From: Lukas Ertl User-Agent: Thunderbird 1.5.0.10 (X11/20070319) MIME-Version: 1.0 To: Johan Hendriks References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, des@freebsd.org Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 07:48:22 -0000 Johan Hendriks wrote: > My installed ports (apache22, samba, cupsd, postgresql and ezjail) do not start at boot time anymore. > > This is the output from rcorder /usr/local/etc/rc.d/* > > rcorder: file `/usr/local/etc/rc.d/ezjail.sh' is before unknown provision `securelevel' > rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/cupsd' has no providers. > /usr/local/etc/rc.d/cupsd > rcorder: requirement `resolv' in file `/usr/local/etc/rc.d/samba' has no providers. > rcorder: requirement `ldconfig' in file `/usr/local/etc/rc.d/samba' has no providers. > rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/samba' has no providers. > rcorder: requirement `SERVERS' in file `/usr/local/etc/rc.d/samba' has no providers. > rcorder: requirement `NETWORKING' in file `/usr/local/etc/rc.d/samba' has no providers. > /usr/local/etc/rc.d/samba > rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/postgresql' has no providers. > /usr/local/etc/rc.d/postgresql > rcorder: requirement `sshd' in file `/usr/local/etc/rc.d/ezjail.sh' has no providers. > rcorder: requirement `cleanvar' in file `/usr/local/etc/rc.d/ezjail.sh' has no providers. > rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/ezjail.sh' has no providers. > /usr/local/etc/rc.d/ezjail.sh > rcorder: requirement `cleanvar' in file `/usr/local/etc/rc.d/apache22' has no providers. > rcorder: requirement `LOGIN' in file `/usr/local/etc/rc.d/apache22' has no providers. > /usr/local/etc/rc.d/apache22 > > I can start them without a problem by hand after the machine has finisched booting. I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? regards, le -- Lukas Ertl http://mailbox.univie.ac.at/~le/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 07:51:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBFCC16A406; Wed, 4 Apr 2007 07:51:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0C1613C46C; Wed, 4 Apr 2007 07:51:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5479846DE2; Wed, 4 Apr 2007 03:51:10 -0400 (EDT) Date: Wed, 4 Apr 2007 03:51:10 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200704040942.08839.hselasky@c2i.net> Message-ID: <20070404034930.W25236@fledge.watson.org> References: <20070401155910.O75869@fledge.watson.org> <20070403175953.A25236@fledge.watson.org> <200704040942.08839.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, performance@freebsd.org, current@freebsd.org, Andrzej Tobola Subject: Re: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 07:51:11 -0000 On Wed, 4 Apr 2007, Hans Petter Selasky wrote: > Just a small comment: > > @@ -60,10 +60,7 @@ > u_short fd_cmask; /* mask for file creation */ > u_short fd_refcnt; /* thread reference count */ > u_short fd_holdcnt; /* hold count on structure + mutex */ > - > - struct mtx fd_mtx; /* protects members of this struct */ > - int fd_locked; /* long lock flag */ > - int fd_wanted; /* "" */ > + struct sx fd_sx; /* protects members of this struct */ > struct kqlist fd_kqlist; /* list of kqueues on this filedesc */ > int fd_holdleaderscount; /* block fdfree() for shared close() */ > int fd_holdleaderswakeup; /* fdfree() needs wakeup */ > > Maybe it is better if you order the elements by size. Then you don't waste > so many extra bytes on platforms where the fields must be aligned. This seems reasonable; I'll merge the patch as-is first, minimizing the patch size of the change against filedesc.h, and then investigate what you suggest as a followup. Thanks for the comment! Generally speaking, we probably should be doing a structure size/layout review for things like in-memory inodes, vnodes, sockets, file descriptors, files, threads, etc, where small changes in memory overhead can make significant overall changes in memory use and cache efficiency. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 07:51:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBFCC16A406; Wed, 4 Apr 2007 07:51:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0C1613C46C; Wed, 4 Apr 2007 07:51:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5479846DE2; Wed, 4 Apr 2007 03:51:10 -0400 (EDT) Date: Wed, 4 Apr 2007 03:51:10 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200704040942.08839.hselasky@c2i.net> Message-ID: <20070404034930.W25236@fledge.watson.org> References: <20070401155910.O75869@fledge.watson.org> <20070403175953.A25236@fledge.watson.org> <200704040942.08839.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, performance@freebsd.org, current@freebsd.org, Andrzej Tobola Subject: Re: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 07:51:11 -0000 On Wed, 4 Apr 2007, Hans Petter Selasky wrote: > Just a small comment: > > @@ -60,10 +60,7 @@ > u_short fd_cmask; /* mask for file creation */ > u_short fd_refcnt; /* thread reference count */ > u_short fd_holdcnt; /* hold count on structure + mutex */ > - > - struct mtx fd_mtx; /* protects members of this struct */ > - int fd_locked; /* long lock flag */ > - int fd_wanted; /* "" */ > + struct sx fd_sx; /* protects members of this struct */ > struct kqlist fd_kqlist; /* list of kqueues on this filedesc */ > int fd_holdleaderscount; /* block fdfree() for shared close() */ > int fd_holdleaderswakeup; /* fdfree() needs wakeup */ > > Maybe it is better if you order the elements by size. Then you don't waste > so many extra bytes on platforms where the fields must be aligned. This seems reasonable; I'll merge the patch as-is first, minimizing the patch size of the change against filedesc.h, and then investigate what you suggest as a followup. Thanks for the comment! Generally speaking, we probably should be doing a structure size/layout review for things like in-memory inodes, vnodes, sockets, file descriptors, files, threads, etc, where small changes in memory overhead can make significant overall changes in memory use and cache efficiency. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:12:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA10916A401; Wed, 4 Apr 2007 08:12:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6466813C465; Wed, 4 Apr 2007 08:12:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HZ0b2-000C6b-Uq; Wed, 04 Apr 2007 11:12:00 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: Your message of Tue, 03 Apr 2007 16:26:36 -0600 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Apr 2007 11:12:00 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:12:03 -0000 I stumbled on the same problem when porting iSCSI to current, calling dev_destroy() hangs because si_threadcount is not zero, Tai-hwa Liang came up with a patch, which fixes the close(), but causes panics when rebooting. danny > Actually, I think it's a wildly incorrect use of the clone API. I'll > take a look at in the in next few days and try to commit something that > works. > > Scott > > > Scott Long wrote: > > My guess is that the kninit() in targopen isn't being cleaned up from in > > targclose. I'm not terribly familiar in how the knote API works, > > though. > > > > Scott > > > > > > Matthew Jacob wrote: > >> Yeah- I've seen this too. > >> > >> On 4/3/07, Alex Dupre wrote: > >>> Scott Long wrote: > >>> > Are there any other console messages from the targ driver? Can you > >>> > turn on CAMDEBUG and send us the trace of what is going on? > >>> > >>> CAMDEBUG is already on, but simply opening/closing the targ device, > >>> without sending any ioctl to enable it, shouldn't produce any CAM > >>> message. I traced the kernel thread and I found that it doesn't return > >>> from the destroy_devl() function: csw->d_purge is NULL and > >>> dev->si_threadcount is '1'. The thread enters the following block > >>> (kern_conf.c, row 690) and never exits. > >>> > >>> > >>> while (dev->si_threadcount != 0) { > >>> /* Use unique dummy wait ident */ > >>> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > >>> } > >>> > >>> > >>> -- > >>> Alex Dupre > >>> _______________________________________________ > >>> freebsd-scsi@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > >>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > >>> > > > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:35:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C56116A401 for ; Wed, 4 Apr 2007 08:35:45 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id A740513C43E for ; Wed, 4 Apr 2007 08:35:44 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l348ZeFv032855; Wed, 4 Apr 2007 12:35:40 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l348ZeXp032854; Wed, 4 Apr 2007 12:35:40 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 12:35:40 +0400 From: Andrey Chernov To: Lukas Ertl Message-ID: <20070404083540.GA32773@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org, des@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46135841.1010902@freebsd.org> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Johan Hendriks , des@freebsd.org, freebsd-current@freebsd.org Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:35:45 -0000 On Wed, Apr 04, 2007 at 09:48:17AM +0200, Lukas Ertl wrote: > Johan Hendriks wrote: > > This is the output from rcorder /usr/local/etc/rc.d/* > > > > rcorder: file `/usr/local/etc/rc.d/ezjail.sh' is before unknown provision `securelevel' > > rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/cupsd' has no providers. About rcorder's part - this was so even before des@ change. Use this call form instead: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:42:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAC2816A40B; Wed, 4 Apr 2007 08:42:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5E35113C448; Wed, 4 Apr 2007 08:42:37 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 458318639; Wed, 04 Apr 2007 09:42:29 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 4 Apr 2007 09:42:08 +0200 User-Agent: KMail/1.9.5 References: <20070401155910.O75869@fledge.watson.org> <20070403175953.A25236@fledge.watson.org> In-Reply-To: <20070403175953.A25236@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704040942.08839.hselasky@c2i.net> Cc: performance@freebsd.org, Robert Watson , current@freebsd.org, Andrzej Tobola Subject: Re: filedesc_sx patch (20070401a) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:42:38 -0000 On Wednesday 04 April 2007 00:01, Robert Watson wrote: > On Sun, 1 Apr 2007, Robert Watson wrote: > > The attached patch moves file descriptor locks from being a custom > > mutex/sleep lock implemented using msleep() to an sx lock. With the new > > sx lock optimizations in place, this is now sensible, avoiding both a > > custom lock type and significantly improving performance. Kris has > > reported 2x-4x improvement in transactions/sec with MySQL using this > > patch, as it greatly reduces the cost of lock contention during file > > descriptor lookup for threaded applications, and also moves to shared > > locking to avoid exclusive acquisition for read-only operations (the vast > > majority in most workloads). Patch is below, but you can also download > > from: > > > > http://www.watson.org/~robert/freebsd/netperf/20070401a-filedesc-sx.diff > > > > I'm currently waiting for the sx lock changes to settle for a few days > > before committing, so will plan to commit this around Wednesday/Thursday > > of this week (unless serious problems arise). > > Andrzej has pointed out that shortly after I posted the patch, it came into > conflict with changes in VFS. I've updated the patch and posted it at: > > http://www.watson.org/~robert/freebsd/netperf/20070403-filedesc-sx.diff Just a small comment: @@ -60,10 +60,7 @@ u_short fd_cmask; /* mask for file creation */ u_short fd_refcnt; /* thread reference count */ u_short fd_holdcnt; /* hold count on structure + mutex */ - - struct mtx fd_mtx; /* protects members of this struct */ - int fd_locked; /* long lock flag */ - int fd_wanted; /* "" */ + struct sx fd_sx; /* protects members of this struct */ struct kqlist fd_kqlist; /* list of kqueues on this filedesc */ int fd_holdleaderscount; /* block fdfree() for shared close() */ int fd_holdleaderswakeup; /* fdfree() needs wakeup */ Maybe it is better if you order the elements by size. Then you don't waste so many extra bytes on platforms where the fields must be aligned. struct { struct sx fd_sx; struct kqlist fd_kqlist; int ...; u_short ....; }; --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:51:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39A9516A408 for ; Wed, 4 Apr 2007 08:51:13 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id E151C13C4C3 for ; Wed, 4 Apr 2007 08:51:12 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so107216wra for ; Wed, 04 Apr 2007 01:51:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IfNjoWQSvcMaL2KtAKZ6FiZb2RhKBDo42Hci1pOd/fQxd9SwuYvRznvN3HFTevN2jjM1y1xQEa7hgJ//urmA7RlOHKcW3GvGBMnzHVaTGQMTOV+pHrHtSEE4817o5zB+tP+79OxOwPyHoeGd9v4C9wPB3Y4pbsm/zCyKQ3BKG/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DYSJ7Zrt5NMtx5AnCYGhxp4TqQ/hmpANvQddotoKpKPUxVIn4RTObP3xUTytv2/g2ReoR7QAzv7djs/V8cP/XnnEtBjRnIwtoDEXHFhQG3GdB+DZLzl9yPk4XPT6y2Zz0NC3fcpBtRh1Gu8teTAAFz8GjhXTP2txGQFkxrxLO5E= Received: by 10.115.77.1 with SMTP id e1mr145715wal.1175676671918; Wed, 04 Apr 2007 01:51:11 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Wed, 4 Apr 2007 01:51:11 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 12:51:11 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Maxim Sobolev" In-Reply-To: <46128475.9060602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46128475.9060602@FreeBSD.org> X-Google-Sender-Auth: b5ff697ca4c39fc0 Cc: FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:51:13 -0000 On 4/3/07, Maxim Sobolev wrote: > Patch ld(1) to detect the condition and don't unlink the device node? Yes, but there has to be a generic solution, so that we don't reinvent the wheel for every one of the thousands apps that may do this. Isn't there some safety-net wrapper function that refuses to remove device nodes and maybe some other types of files? From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:55:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D215416A404; Wed, 4 Apr 2007 08:55:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF0A13C4B0; Wed, 4 Apr 2007 08:55:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HZ1Go-000DYB-KZ; Wed, 04 Apr 2007 11:55:10 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Apr 2007 11:55:10 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org Subject: diskless/rm causing deadlock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:55:11 -0000 I stumbled on this in -current, but it's also true for 6.2. /(root) is mounted diskless, doing rm of a file in /, even as a lowly mortal will hang the network, and hence everything. on a 6.1 system, it works as expected. badwolf> rm /usr/ports rm: /usr/ports: Read-only file system i'll try to hunt this down, but some pointers where to start might be helpfull danny From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 09:17:14 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40F1E16A401; Wed, 4 Apr 2007 09:17:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EDD0E13C45E; Wed, 4 Apr 2007 09:17:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 69E1747736; Wed, 4 Apr 2007 05:17:13 -0400 (EDT) Date: Wed, 4 Apr 2007 05:17:13 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20070404051355.P25236@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org Subject: HEADS UP: filedesc_sx patch in CVS HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 09:17:14 -0000 I've committed the below to the tree; Kris has performed quite a lot of performance and stability testing, but since he tends to run with specific workloads, I wouldn't be surprised if there are minor (and hopefully quickly corrected) issues reported. If you experience hangs or other problems, please make sure to run with INVARIANTS and WITNESS, which will help with debugging. This patch represents a significant part of the performance improvements for improved scalability on 7-CURRENT with respect to threaded databases, and is only possible because of the long hours of work Attilio, Kris, John, and others have put in preparing the sxlock optimizations this patch depends on, as well as reviewing and testing the patch. Please let me know if you experience any problems. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Wed, 4 Apr 2007 09:11:34 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/compat/linux linux_file.c src/sys/compat/svr4 svr4_filio.c src/sys/dev/streams streams.c src/sys/fs/devfs devfs_vnops.c src/sys/fs/fdescfs fdesc_vfsops.c fdesc_vnops.c src/sys/fs/fifofs fifo_vnops.c src/sys/fs/unionfs union_subr.c ... rwatson 2007-04-04 09:11:34 UTC FreeBSD src repository Modified files: sys/compat/linux linux_file.c sys/compat/svr4 svr4_filio.c sys/dev/streams streams.c sys/fs/devfs devfs_vnops.c sys/fs/fdescfs fdesc_vfsops.c fdesc_vnops.c sys/fs/fifofs fifo_vnops.c sys/fs/unionfs union_subr.c sys/kern kern_descrip.c kern_event.c kern_fork.c subr_witness.c sys_generic.c uipc_mqueue.c uipc_syscalls.c uipc_usrreq.c vfs_cache.c vfs_lookup.c vfs_mount.c vfs_syscalls.c sys/netsmb smb_dev.c sys/opencrypto cryptodev.c sys/security/audit audit_bsm_klib.c sys/sys filedesc.h Log: Replace custom file descriptor array sleep lock constructed using a mutex and flags with an sxlock. This leads to a significant and measurable performance improvement as a result of access to shared locking for frequent lookup operations, reduced general overhead, and reduced overhead in the event of contention. All of these are imported for threaded applications where simultaneous access to a shared file descriptor array occurs frequently. Kris has reported 2x-4x transaction rate improvements on 8-core MySQL benchmarks; smaller improvements can be expected for many workloads as a result of reduced overhead. - Generally eliminate the distinction between "fast" and regular acquisisition of the filedesc lock; the plan is that they will now all be fast. Change all locking instances to either shared or exclusive locks. - Correct a bug (pointed out by kib) in fdfree() where previously msleep() was called without the mutex held; sx_sleep() is now always called with the sxlock held exclusively. - Universally hold the struct file lock over changes to struct file, rather than the filedesc lock or no lock. Always update the f_ops field last. A further memory barrier is required here in the future (discussed with jhb). - Improve locking and reference management in linux_at(), which fails to properly acquire vnode references before using vnode pointers. Annotate improper use of vn_fullpath(), which will be replaced at a future date. In fcntl(), we conservatively acquire an exclusive lock, even though in some cases a shared lock may be sufficient, which should be revisited. The dropping of the filedesc lock in fdgrowtable() is no longer required as the sxlock can be held over the sleep operation; we should consider removing that (pointed out by attilio). Tested by: kris Discussed with: jhb, kris, attilio, jeff Revision Changes Path 1.103 +17 -4 src/sys/compat/linux/linux_file.c 1.35 +4 -4 src/sys/compat/svr4/svr4_filio.c 1.55 +2 -2 src/sys/dev/streams/streams.c 1.143 +3 -1 src/sys/fs/devfs/devfs_vnops.c 1.56 +2 -2 src/sys/fs/fdescfs/fdesc_vfsops.c 1.104 +5 -5 src/sys/fs/fdescfs/fdesc_vnops.c 1.136 +3 -1 src/sys/fs/fifofs/fifo_vnops.c 1.91 +2 -2 src/sys/fs/unionfs/union_subr.c 1.307 +174 -170 src/sys/kern/kern_descrip.c 1.109 +9 -9 src/sys/kern/kern_event.c 1.270 +2 -2 src/sys/kern/kern_fork.c 1.228 +0 -2 src/sys/kern/subr_witness.c 1.155 +11 -12 src/sys/kern/sys_generic.c 1.21 +10 -11 src/sys/kern/uipc_mqueue.c 1.250 +14 -9 src/sys/kern/uipc_syscalls.c 1.201 +10 -9 src/sys/kern/uipc_usrreq.c 1.108 +4 -4 src/sys/kern/vfs_cache.c 1.100 +2 -2 src/sys/kern/vfs_lookup.c 1.252 +2 -2 src/sys/kern/vfs_mount.c 1.436 +26 -25 src/sys/kern/vfs_syscalls.c 1.32 +3 -3 src/sys/netsmb/smb_dev.c 1.33 +3 -1 src/sys/opencrypto/cryptodev.c 1.6 +2 -2 src/sys/security/audit/audit_bsm_klib.c 1.76 +15 -61 src/sys/sys/filedesc.h From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 09:26:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3383916A402 for ; Wed, 4 Apr 2007 09:26:43 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id C7FE013C448 for ; Wed, 4 Apr 2007 09:26:42 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id l349Qf0O068436; Wed, 4 Apr 2007 11:26:41 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 11:27:41 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBB512@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ports do not start at 7 current as of today Thread-Index: Acd2lKwtvyKJe3W4TBeNq3wbYdg0uAABl+yA From: "Johan Hendriks" To: "Andrey Chernov" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: RE: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 09:26:43 -0000 -----Oorspronkelijk bericht----- Van: Andrey Chernov [mailto:ache@freebsd.org]=20 Verzonden: woensdag 4 april 2007 10:36 Aan: Lukas Ertl CC: Johan Hendriks; freebsd-current@freebsd.org; des@freebsd.org Onderwerp: Re: ports do not start at 7 current as of today On Wed, Apr 04, 2007 at 09:48:17AM +0200, Lukas Ertl wrote: > Johan Hendriks wrote: > > This is the output from rcorder /usr/local/etc/rc.d/* > >=20 > > rcorder: file `/usr/local/etc/rc.d/ezjail.sh' is before unknown provision `securelevel' > > rcorder: requirement `DAEMON' in file `/usr/local/etc/rc.d/cupsd' has no providers. About rcorder's part - this was so even before des@ change.=20 Use this call form instead: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* --=20 http://ache.pp.ru/ The output of rcorder /etc/rc.d/* /usr/local/etc/rc.d/* gives no errors indeed. But still my ports do not start. I cvsuped today and did a buildworld just jet. Regards, Johan From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 10:03:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF13516A402 for ; Wed, 4 Apr 2007 10:03:55 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 1AF8513C457 for ; Wed, 4 Apr 2007 10:03:54 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 76170 invoked from network); 4 Apr 2007 10:03:51 -0000 Received: from unknown (HELO ?192.168.2.5?) (192.168.2.5) by andxor.it with SMTP; 4 Apr 2007 10:03:51 -0000 Message-ID: <46137807.4060203@FreeBSD.org> Date: Wed, 04 Apr 2007 12:03:51 +0200 From: Alex Dupre User-Agent: Mozilla Thunderbird 1.5.0.10 (X11/20070317) MIME-Version: 1.0 To: Scott Long References: <46126585.8080204@FreeBSD.org> <46127DF4.5080703@samsco.org> <461285E0.8000008@FreeBSD.org> <7579f7fb0704031332o64d0637coe17770971d5a6e29@mail.gmail.com> <4612C873.1020505@samsco.org> <4612D49C.8040100@samsco.org> In-Reply-To: <4612D49C.8040100@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Jacob , freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: targclose doesn't return X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 10:03:56 -0000 Scott Long ha scritto: > Actually, I think it's a wildly incorrect use of the clone API. Hmm, I don't think scsi_target uses the clone API. Yes, probably it should or at least it will be better, but the problem will remain. From what I've understood we cannot call destroy_dev directly from d_close. The solutions I see are: - use the destroy_dev_sched function posted by Kostik - remove the device externally, after closing it (like other clonable devices already do) The latter approach probably needs some redesign of the scsi_target code, while the first should be simpler if it works as expected (perhaps we should handle in a different way an open() to a closed but not already destroyed device, dunno). > I'll > take a look at in the in next few days and try to commit something that > works. Thanks for your support. I'm available to help (as much as I'm able) and test patches. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 10:13:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F3EC16A403 for ; Wed, 4 Apr 2007 10:13:24 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 7597713C469 for ; Wed, 4 Apr 2007 10:13:23 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34ADMMu037527; Wed, 4 Apr 2007 14:13:22 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34ADMrL037526; Wed, 4 Apr 2007 14:13:22 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 14:13:21 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20070404101321.GA37396@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Cc: ports@freebsd.org Subject: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 10:13:24 -0000 Try to install and run www/apache13 port. With recent -current you'll get similar error for each module first listed in config: Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/mod_env.so into server: /usr/local/libexec /apache/mod_env.so: Undefined symbol "ap_palloc" Perhaps it is Apache configuration problem since old-compiled apache (Dec 9) runs normally. Perhaps Apache config find some new defines which not works as expected. I am not expert in dlopen() at all. Please look someone who knows. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 10:31:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20A0116A402; Wed, 4 Apr 2007 10:31:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1280813C45E; Wed, 4 Apr 2007 10:31:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 65AD61A4D8E; Wed, 4 Apr 2007 03:12:22 -0700 (PDT) Date: Wed, 4 Apr 2007 03:12:22 -0700 From: Alfred Perlstein To: Howard Su Message-ID: <20070404101222.GU61362@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 10:31:58 -0000 * Howard Su [070404 01:20] wrote: > Following the suggestion in idea page, I proposed the attached patch. > I didn't change any kernel part because I think PTRACE(2) is > functional although man page didn't document it. > > I tested the patch under i386 and amd64 box. The help on testing and > code review will be appreciated. wow, well done! any draw backs to using ptrace over procfs? have you tested performance? -Alfred From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 10:52:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E01516A403; Wed, 4 Apr 2007 10:52:40 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 981D313C44B; Wed, 4 Apr 2007 10:52:39 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34AqZQs038390; Wed, 4 Apr 2007 14:52:35 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34AqZdK038389; Wed, 4 Apr 2007 14:52:35 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 14:52:35 +0400 From: Andrey Chernov To: Lukas Ertl Message-ID: <20070404105235.GA38359@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org, des@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46135841.1010902@freebsd.org> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Johan Hendriks , des@freebsd.org, freebsd-current@freebsd.org Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 10:52:40 -0000 On Wed, Apr 04, 2007 at 09:48:17AM +0200, Lukas Ertl wrote: > I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. > Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? Yes, I observe the same problem too. It appearse like problem with ${early_late_divider} set with new des@ changes - all scripts are just skipped because of it. Backing out rc only not helps. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 11:13:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 213DC16A401; Wed, 4 Apr 2007 11:13:14 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 9A77A13C4BE; Wed, 4 Apr 2007 11:13:13 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34BD9Va038836; Wed, 4 Apr 2007 15:13:09 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34BD9Ye038835; Wed, 4 Apr 2007 15:13:09 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 15:13:09 +0400 From: Andrey Chernov To: Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org, des@freebsd.org Message-ID: <20070404111309.GA38798@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org, des@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> <20070404105235.GA38359@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070404105235.GA38359@nagual.pp.ru> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 11:13:14 -0000 On Wed, Apr 04, 2007 at 02:52:35PM +0400, Andrey Chernov wrote: > On Wed, Apr 04, 2007 at 09:48:17AM +0200, Lukas Ertl wrote: > > I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. > > Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? > > Yes, I observe the same problem too. It appearse like problem with > ${early_late_divider} set with new des@ changes - all scripts are just > skipped because of it. Backing out rc only not helps. Should be fixed in rc.conf v1.310, please try -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 08:46:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7F5F16A405 for ; Wed, 4 Apr 2007 08:46:35 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4D60513C480 for ; Wed, 4 Apr 2007 08:46:34 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so614326ugh for ; Wed, 04 Apr 2007 01:46:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=PwcS/3+crE41IApwj0LH+s9FxwfoWpe2uifQukB6QewUSNjmMVW3ep4CM4RcREtujnm6yBubKySDoEzVS1Ov3Tsed53IpSQiXH9/00JlQmwe243psD/fjIUYrNJ6fuSwXZ84sgKaLVrEO163GNVsq3el02LtFOqVFmTntZ0yrFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=S9lIzF981sVZ2KJ999exKIU8ItjyvvS+za6vG91E4ilE0o16KfLBpZ6OR2QleRDm3ioSQLbjEHheXhkw2SXOvW9gjksnHrGeJrfXvXn0taCA1FtwYFnJGgGHATxmR3mBWmh2CtTqQCw1In4/61o0ZuDzA6N9vWxHHhAQJN4yW9Q= Received: by 10.114.39.16 with SMTP id m16mr126460wam.1175674700198; Wed, 04 Apr 2007 01:18:20 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Wed, 4 Apr 2007 01:18:20 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 16:18:20 +0800 From: "Howard Su" To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_27400_23796817.1175674700136" X-Mailman-Approved-At: Wed, 04 Apr 2007 11:22:06 +0000 Cc: alfred@freebsd.org Subject: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 08:46:36 -0000 ------=_Part_27400_23796817.1175674700136 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Following the suggestion in idea page, I proposed the attached patch. I didn't change any kernel part because I think PTRACE(2) is functional although man page didn't document it. I tested the patch under i386 and amd64 box. The help on testing and code review will be appreciated. To test, please try the following commands: 1. truss ps basic stuff 2. truss -o output ps output the result to file 3. truss -f -o output sh -c "ps" test follow fork 4. start TOP(1) in another session, the truss -p -- -Howard ------=_Part_27400_23796817.1175674700136 Content-Type: text/plain; name=truss_patch.diff; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f03i5k1f Content-Disposition: attachment; filename="truss_patch.diff" PT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL01ha2VmaWxlIzkg KHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5iaW4vdHJ1c3MvTWFr ZWZpbGUjMSAodGV4dCtrbykgPT09PSBpZGVudGljYWwKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVl YnNkL3NyYy91c3IuYmluL3RydXNzL2FtZDY0LWZic2QuYyM2ICh0ZXh0K2tvKSAtIC8vZGVwb3Qv dXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL2FtZDY0LWZic2QuYyM0ICh0ZXh0K2tv KSA9PT09IGNvbnRlbnQKQEAgLTQzLDggKzQzLDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgor I2luY2x1ZGUgPHN5cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5j bHVkZSA8bWFjaGluZS9yZWcuaD4KQEAgLTYzLDcgKzYyLDYgQEAKICNpbmNsdWRlICJzeXNjYWxs LmgiCiAjaW5jbHVkZSAiZXh0ZXJuLmgiCiAKLXN0YXRpYyBpbnQgZmQgPSAtMTsKIHN0YXRpYyBp bnQgY3BpZCA9IC0xOwogCiAjaW5jbHVkZSAic3lzY2FsbHMuaCIKQEAgLTExMywyNSArMTExLDE2 IEBACiAKIHZvaWQKIGFtZDY0X3N5c2NhbGxfZW50cnkoc3RydWN0IHRydXNzaW5mbyAqdHJ1c3Np bmZvLCBpbnQgbmFyZ3MpIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAg IGludCBzeXNjYWxsX251bTsKICAgaW50IGksIHJlZzsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwog Ci0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50 ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwotICAgIGZkID0gb3Blbihi dWYsIE9fUkRXUik7Ci0gICAgaWYgKGZkID09IC0xKSB7Ci0gICAgICBmcHJpbnRmKHRydXNzaW5m by0+b3V0ZmlsZSwgIi0tIENBTk5PVCBPUEVOIFJFR0lTVEVSUyAtLVxuIik7Ci0gICAgICByZXR1 cm47Ci0gICAgfQotICAgIGNwaWQgPSB0cnVzc2luZm8tPnBpZDsKLSAgfQorICBjcGlkID0gdHJ1 c3NpbmZvLT5waWQ7CiAKICAgY2xlYXJfZnNjKCk7Ci0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlm IChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVncykpIHsKKyAgaWYg KHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKQorICB7CiAg ICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMg LS1cbiIpOwogICAgIHJldHVybjsKICAgfQpAQCAtMTgxLDggKzE3MCwxMyBAQAogICAgIH0KICAg fQogICBpZiAobmFyZ3MgPiBpKSB7Ci0gICAgbHNlZWsoUHJvY2ZkLCByZWdzLnJfcnNwICsgc2l6 ZW9mKHJlZ2lzdGVyX3QpLCBTRUVLX1NFVCk7Ci0gICAgaWYgKHJlYWQoUHJvY2ZkLCAmZnNjLmFy Z3NbaV0sIChuYXJncy1pKSAqIHNpemVvZihyZWdpc3Rlcl90KSkgPT0gLTEpCisgICAgc3RydWN0 IHB0cmFjZV9pb19kZXNjIGlvcmVxdWVzdDsKKyAgICBpb3JlcXVlc3QucGlvZF9vcCA9IFBJT0Rf UkVBRF9EOworICAgIGlvcmVxdWVzdC5waW9kX29mZnMgPSAodm9pZCAqKShyZWdzLnJfcnNwICsg c2l6ZW9mKHJlZ2lzdGVyX3QpKTsKKyAgICBpb3JlcXVlc3QucGlvZF9hZGRyID0gJmZzYy5hcmdz W2ldOworICAgIGlvcmVxdWVzdC5waW9kX2xlbiA9IChuYXJncyAtIGkpICogc2l6ZW9mKHJlZ2lz dGVyX3QpOworICAgIHB0cmFjZShQVF9JTywgY3BpZCwgKGNhZGRyX3QpJmlvcmVxdWVzdCwgMCk7 CisgICAgaWYgKGlvcmVxdWVzdC5waW9kX2xlbiA9PSAwKQogICAgICAgcmV0dXJuOwogICB9CiAK QEAgLTIyMyw3ICsyMTcsNyBAQAogCSAgICAgIGkgPCAoZnNjLm5hcmdzIC0gMSkgPyAiLCIgOiAi Iik7CiAjZW5kaWYKICAgICAgIGlmIChzYyAmJiAhKHNjLT5hcmdzW2ldLnR5cGUgJiBPVVQpKSB7 Ci0JZnNjLnNfYXJnc1tpXSA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFy Z3MsIDAsIHRydXNzaW5mbyk7CisJZnNjLnNfYXJnc1tpXSA9IHByaW50X2FyZygmc2MtPmFyZ3Nb aV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOwogICAgICAgfQogICAgIH0KICNpZiBERUJVRwpA QCAtMjc5LDI1ICsyNzMsMTYgQEAKIGxvbmcKIGFtZDY0X3N5c2NhbGxfZXhpdChzdHJ1Y3QgdHJ1 c3NpbmZvICp0cnVzc2luZm8sIGludCBzeXNjYWxsX251bSBfX3VudXNlZCkKIHsKLSAgY2hhciBi dWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAgIGxvbmcgcmV0dmFsOwogICBpbnQgaTsKICAg aW50IGVycm9ycDsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0 cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdz IiwgdHJ1c3NpbmZvLT5waWQpOwotICAgIGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBp ZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FO Tk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAg ICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0gIH0KKyAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwog Ci0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlmIChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3Mp KSAhPSBzaXplb2YocmVncykpIHsKKyAgaWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2Fk ZHJfdCkmcmVncywgMCkgPCAwKQorICB7CiAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUs ICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMgLS1cbiIpOwogICAgIHJldHVybiAoLTEpOwogICB9 CkBAIC0zMjgsNyArMzEzLDcgQEAKIAlpZiAoZXJyb3JwKQogCSAgYXNwcmludGYoJnRlbXAsICIw eCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9mZnNldF0pOwogCWVsc2UKLQkgIHRlbXAgPSBw cmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCByZXR2YWwsIHRydXNzaW5m byk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwg dHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0gdGVtcDsKICAgICAgIH0KICAgICB9Cj09PT0g Ly9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVzcy9leHRlcm4uaCMxMCAodGV4 dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9leHRlcm4u aCMyICh0ZXh0K2tvKSA9PT09IGNvbnRlbnQKQEAgLTMyLDggKzMyLDkgQEAKICAqLwogCiBleHRl cm4gaW50IHNldHVwX2FuZF93YWl0KGNoYXIgKiopOwotZXh0ZXJuIGludCBzdGFydF90cmFjaW5n KGludCwgaW50LCBpbnQsIGludCk7CitleHRlcm4gaW50IHN0YXJ0X3RyYWNpbmcoaW50KTsKIGV4 dGVybiB2b2lkIHJlc3RvcmVfcHJvYyhpbnQpOworZXh0ZXJuIHZvaWQgd2FpdGV2ZW50KHN0cnVj dCB0cnVzc2luZm8gKik7CiBleHRlcm4gY29uc3QgY2hhciAqaW9jdGxuYW1lKHJlZ2lzdGVyX3Qg dmFsKTsKIGV4dGVybiBjaGFyICpzdHJzaWcoaW50IHNpZyk7CiAjaWZkZWYgX19hbHBoYV9fCj09 PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVzcy9pMzg2LWZic2QuYyMx NyAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9p Mzg2LWZic2QuYyMzICh0ZXh0K2tvKSA9PT09IGNvbnRlbnQKQEAgLTQzLDkgKzQzLDggQEAKICAq LwogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5j bHVkZSA8c3lzL3Bpb2N0bC5oPgogI2luY2x1ZGUgPHN5cy9zeXNjYWxsLmg+CisjaW5jbHVkZSA8 c3lzL3B0cmFjZS5oPgogCiAjaW5jbHVkZSA8bWFjaGluZS9yZWcuaD4KICNpbmNsdWRlIDxtYWNo aW5lL3BzbC5oPgpAQCAtNjMsNyArNjIsNiBAQAogI2luY2x1ZGUgInN5c2NhbGwuaCIKICNpbmNs dWRlICJleHRlcm4uaCIKIAotc3RhdGljIGludCBmZCA9IC0xOwogc3RhdGljIGludCBjcGlkID0g LTE7CiAKICNpbmNsdWRlICJzeXNjYWxscy5oIgpAQCAtMTEzLDI2ICsxMTEsMTggQEAKIAogdm9p ZAogaTM4Nl9zeXNjYWxsX2VudHJ5KHN0cnVjdCB0cnVzc2luZm8gKnRydXNzaW5mbywgaW50IG5h cmdzKSB7Ci0gIGNoYXIgYnVmWzMyXTsKICAgc3RydWN0IHJlZyByZWdzOwogICBpbnQgc3lzY2Fs bF9udW07CiAgIGludCBpOwogICB1bnNpZ25lZCBpbnQgcGFybV9vZmZzZXQ7CiAgIHN0cnVjdCBz eXNjYWxsICpzYyA9IE5VTEw7Ci0KLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9 IGNwaWQpIHsKLSAgICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBp ZCk7Ci0gICAgZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAg ICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJT IC0tXG4iKTsKLSAgICAgIHJldHVybjsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlk OwotICB9CisgIHN0cnVjdCBwdHJhY2VfaW9fZGVzYyBpb3JlcXVlc3Q7CisgIGNwaWQgPSB0cnVz c2luZm8tPnBpZDsKIAogICBjbGVhcl9mc2MoKTsKLSAgbHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYg KHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkgeworICAKKyAg aWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKQorICB7 CiAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RF UlMgLS1cbiIpOwogICAgIHJldHVybjsKICAgfQpAQCAtMTQ2LDEzICsxMzYsMTEgQEAKICAgc3lz Y2FsbF9udW0gPSByZWdzLnJfZWF4OwogICBzd2l0Y2ggKHN5c2NhbGxfbnVtKSB7CiAgIGNhc2Ug U1lTX3N5c2NhbGw6Ci0gICAgbHNlZWsoUHJvY2ZkLCBwYXJtX29mZnNldCwgU0VFS19TRVQpOwot ICAgIHJlYWQoUHJvY2ZkLCAmc3lzY2FsbF9udW0sIHNpemVvZihpbnQpKTsKKyAgICBzeXNjYWxs X251bSA9IHB0cmFjZShQVF9SRUFEX0QsIGNwaWQsIChjYWRkcl90KXBhcm1fb2Zmc2V0LCAwKTsK ICAgICBwYXJtX29mZnNldCArPSBzaXplb2YoaW50KTsKICAgICBicmVhazsKICAgY2FzZSBTWVNf X19zeXNjYWxsOgotICAgIGxzZWVrKFByb2NmZCwgcGFybV9vZmZzZXQsIFNFRUtfU0VUKTsKLSAg ICByZWFkKFByb2NmZCwgJnN5c2NhbGxfbnVtLCBzaXplb2YoaW50KSk7CisgICAgc3lzY2FsbF9u dW0gPSBwdHJhY2UoUFRfUkVBRF9ELCBjcGlkLCAoY2FkZHJfdClwYXJtX29mZnNldCwgMCk7CiAg ICAgcGFybV9vZmZzZXQgKz0gc2l6ZW9mKHF1YWRfdCk7CiAgICAgYnJlYWs7CiAgIH0KQEAgLTE3 Niw4ICsxNjQsMTIgQEAKICAgICByZXR1cm47CiAKICAgZnNjLmFyZ3MgPSBtYWxsb2MoKDErbmFy Z3MpICogc2l6ZW9mKHVuc2lnbmVkIGxvbmcpKTsKLSAgbHNlZWsoUHJvY2ZkLCBwYXJtX29mZnNl dCwgU0VFS19TRVQpOwotICBpZiAocmVhZChQcm9jZmQsIGZzYy5hcmdzLCBuYXJncyAqIHNpemVv Zih1bnNpZ25lZCBsb25nKSkgPT0gLTEpCisgIGlvcmVxdWVzdC5waW9kX29wID0gUElPRF9SRUFE X0Q7CisgIGlvcmVxdWVzdC5waW9kX29mZnMgPSAodm9pZCAqKXBhcm1fb2Zmc2V0OworICBpb3Jl cXVlc3QucGlvZF9hZGRyID0gZnNjLmFyZ3M7CisgIGlvcmVxdWVzdC5waW9kX2xlbiA9IG5hcmdz ICogc2l6ZW9mKHVuc2lnbmVkIGxvbmcpOworICBwdHJhY2UoUFRfSU8sIGNwaWQsIChjYWRkcl90 KSZpb3JlcXVlc3QsIDApOworICBpZiAoaW9yZXF1ZXN0LnBpb2RfbGVuID09IDApCiAgICAgcmV0 dXJuOwogCiAgIGlmIChmc2MubmFtZSkKQEAgLTIxOCw3ICsyMTAsNyBAQAogCSAgICAgIGkgPCAo ZnNjLm5hcmdzIC0gMSkgPyAiLCIgOiAiIik7CiAjZW5kaWYKICAgICAgIGlmIChzYyAmJiAhKHNj LT5hcmdzW2ldLnR5cGUgJiBPVVQpKSB7Ci0JZnNjLnNfYXJnc1tpXSA9IHByaW50X2FyZyhQcm9j ZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIDAsIHRydXNzaW5mbyk7CisJZnNjLnNfYXJnc1tp XSA9IHByaW50X2FyZygmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOwogICAg ICAgfQogICAgIH0KICNpZiBERUJVRwpAQCAtMjc0LDI4ICsyNjYsMjAgQEAKIGxvbmcKIGkzODZf c3lzY2FsbF9leGl0KHN0cnVjdCB0cnVzc2luZm8gKnRydXNzaW5mbywgaW50IHN5c2NhbGxfbnVt IF9fdW51c2VkKQogewotICBjaGFyIGJ1ZlszMl07CiAgIHN0cnVjdCByZWcgcmVnczsKICAgbG9u ZyByZXR2YWw7CiAgIGludCBpOwogICBpbnQgZXJyb3JwOwogICBzdHJ1Y3Qgc3lzY2FsbCAqc2M7 CiAKLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9IGNwaWQpIHsKLSAgICBzcHJp bnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7Ci0gICAgZmQgPSBvcGVu KGJ1ZiwgT19SRE9OTFkpOwotICAgIGlmIChmZCA9PSAtMSkgewotICAgICAgZnByaW50Zih0cnVz c2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgT1BFTiBSRUdJU1RFUlMgLS1cbiIpOwotICAgICAg cmV0dXJuICgtMSk7Ci0gICAgfQotICAgIGNwaWQgPSB0cnVzc2luZm8tPnBpZDsKLSAgfQorICBj cGlkID0gdHJ1c3NpbmZvLT5waWQ7CiAKLSAgbHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYgKHJlYWQo ZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkgeworICBpZiAocHRyYWNl KFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8IDApCisgIHsKICAgICBmcHJp bnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFEIFJFR0lTVEVSUyAtLVxuIik7 CiAgICAgcmV0dXJuICgtMSk7CiAgIH0KKyAgCiAgIHJldHZhbCA9IHJlZ3Mucl9lYXg7CiAgIGVy cm9ycCA9ICEhKHJlZ3Mucl9lZmxhZ3MgJiBQU0xfQyk7CiAKQEAgLTMyMyw3ICszMDcsNyBAQAog CWlmIChlcnJvcnApCiAJICBhc3ByaW50ZigmdGVtcCwgIjB4JWx4IiwgZnNjLmFyZ3Nbc2MtPmFy Z3NbaV0ub2Zmc2V0XSk7CiAJZWxzZQotCSAgdGVtcCA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+ YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKKwkgIHRlbXAgPSBwcmludF9h cmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgcmV0dmFsLCB0cnVzc2luZm8pOwogCWZzYy5zX2Fy Z3NbaV0gPSB0ZW1wOwogICAgICAgfQogICAgIH0KPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNk L3NyYy91c3IuYmluL3RydXNzL2kzODYtbGludXguYyMxNiAodGV4dCtrbykgLSAvL2RlcG90L3Vz ZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9pMzg2LWxpbnV4LmMjMyAodGV4dCtrbykg PT09PSBjb250ZW50CkBAIC00MSw4ICs0MSw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy90eXBl cy5oPgotI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgotI2luY2x1ZGUgPHN5cy9waW9jdGwuaD4KKyNp bmNsdWRlIDxzeXMvcHRyYWNlLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL3JlZy5oPgogI2luY2x1 ZGUgPG1hY2hpbmUvcHNsLmg+CkBAIC02MCw3ICs1OSw2IEBACiAjaW5jbHVkZSAic3lzY2FsbC5o IgogI2luY2x1ZGUgImV4dGVybi5oIgogCi1zdGF0aWMgaW50IGZkID0gLTE7CiBzdGF0aWMgaW50 IGNwaWQgPSAtMTsKIAogI2luY2x1ZGUgImxpbnV4X3N5c2NhbGxzLmgiCkBAIC0xMDgsMjggKzEw NiwyMCBAQAogCiB2b2lkCiBpMzg2X2xpbnV4X3N5c2NhbGxfZW50cnkoc3RydWN0IHRydXNzaW5m byAqdHJ1c3NpbmZvLCBpbnQgbmFyZ3MpIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVn IHJlZ3M7CiAgIGludCBzeXNjYWxsX251bTsKICAgaW50IGk7CiAgIHN0cnVjdCBzeXNjYWxsICpz YzsKIAotICBpZiAoZmQgPT0gLTEgfHwgdHJ1c3NpbmZvLT5waWQgIT0gY3BpZCkgewotICAgIHNw cmludGYoYnVmLCAiL3Byb2MvJWQvcmVncyIsIHRydXNzaW5mby0+cGlkKTsKLSAgICBmZCA9IG9w ZW4oYnVmLCBPX1JEV1IpOwotICAgIGlmIChmZCA9PSAtMSkgewotICAgICAgZnByaW50Zih0cnVz c2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgT1BFTiBSRUdJU1RFUlMgLS1cbiIpOwotICAgICAg cmV0dXJuOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0gIH0KKyAgY3BpZCA9 IHRydXNzaW5mby0+cGlkOwogCiAgIGNsZWFyX2ZzYygpOwotICBsc2VlayhmZCwgMEwsIDApOwot ICBpZiAocmVhZChmZCwgJnJlZ3MsIHNpemVvZihyZWdzKSkgIT0gc2l6ZW9mKHJlZ3MpKSB7Cisg IAorICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8IDAp CisgIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFEIFJF R0lTVEVSUyAtLVxuIik7CiAgICAgcmV0dXJuOwotICB9CisgIH0gCiAgIHN5c2NhbGxfbnVtID0g cmVncy5yX2VheDsKIAogICBmc2MubnVtYmVyID0gc3lzY2FsbF9udW07CkBAIC0yMDAsNyArMTkw LDcgQEAKIAkgICAgICBpIDwgKGZzYy5uYXJncyAtIDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAg ICAgICBpZiAoc2MgJiYgIShzYy0+YXJnc1tpXS50eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3Nb aV0gPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2lu Zm8pOworCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywg MCwgdHJ1c3NpbmZvKTsKICAgICAgIH0KICAgICB9CiAjaWYgREVCVUcKQEAgLTI2NCwyOCArMjU0 LDE5IEBACiBsb25nCiBpMzg2X2xpbnV4X3N5c2NhbGxfZXhpdChzdHJ1Y3QgdHJ1c3NpbmZvICp0 cnVzc2luZm8sIGludCBzeXNjYWxsX251bSBfX3VudXNlZCkKIHsKLSAgY2hhciBidWZbMzJdOwog ICBzdHJ1Y3QgcmVnIHJlZ3M7CiAgIGxvbmcgcmV0dmFsOwogICBpbnQgaTsKICAgaW50IGVycm9y cDsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8t PnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3Np bmZvLT5waWQpOwotICAgIGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0g LTEpIHsKLSAgICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4g UkVHSVNURVJTIC0tXG4iKTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0g dHJ1c3NpbmZvLT5waWQ7CisgIGNwaWQgPSB0cnVzc2luZm8tPnBpZDsKKyAgaWYgKHB0cmFjZShQ VF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKQorICB7CisgICAgZnByaW50 Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMgLS1cbiIpOwor ICAgIHJldHVybiAoLTEpOwogICB9CiAKLSAgbHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYgKHJlYWQo ZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkgewotICAgIGZwcmludGYo dHJ1c3NpbmZvLT5vdXRmaWxlLCAiXG4iKTsKLSAgICByZXR1cm4gKC0xKTsKLSAgfQogICByZXR2 YWwgPSByZWdzLnJfZWF4OwogICBlcnJvcnAgPSAhIShyZWdzLnJfZWZsYWdzICYgUFNMX0MpOwog CkBAIC0zMTMsNyArMjk0LDcgQEAKIAlpZiAoZXJyb3JwKQogCSAgYXNwcmludGYoJnRlbXAsICIw eCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9mZnNldF0pOwogCWVsc2UKLQkgIHRlbXAgPSBw cmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCByZXR2YWwsIHRydXNzaW5m byk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwg dHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0gdGVtcDsKICAgICAgIH0KICAgICB9Cj09PT0g Ly9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVzcy9pMzg2LmNvbmYjMSAodGV4 dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9pMzg2LmNv bmYjMSAodGV4dCtrbykgPT09PSBpZGVudGljYWwKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNk L3NyYy91c3IuYmluL3RydXNzL2kzODZsaW51eC5jb25mIzEgKHRleHQra28pIC0gLy9kZXBvdC91 c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5iaW4vdHJ1c3MvaTM4NmxpbnV4LmNvbmYjMSAodGV4dCtr bykgPT09PSBpZGVudGljYWwKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmlu L3RydXNzL2lhNjQtZmJzZC5jIzkgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3Ry dXNzL3Vzci5iaW4vdHJ1c3MvaWE2NC1mYnNkLmMjMiAodGV4dCtrbykgPT09PSBjb250ZW50CkBA IC00Myw4ICs0Myw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUg PHN5cy9pb2N0bC5oPgotI2luY2x1ZGUgPHN5cy9waW9jdGwuaD4KKyNpbmNsdWRlIDxzeXMvcHRy YWNlLmg+CiAjaW5jbHVkZSA8c3lzL3N5c2NhbGwuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvcmVn Lmg+CkBAIC02Miw3ICs2MSw2IEBACiAjaW5jbHVkZSAic3lzY2FsbC5oIgogI2luY2x1ZGUgImV4 dGVybi5oIgogCi1zdGF0aWMgaW50IGZkID0gLTE7CiBzdGF0aWMgaW50IGNwaWQgPSAtMTsKIAog I2luY2x1ZGUgInN5c2NhbGxzLmgiCkBAIC0xMTIsMjYgKzExMCwxNiBAQAogCiB2b2lkCiBpYTY0 X3N5c2NhbGxfZW50cnkoc3RydWN0IHRydXNzaW5mbyAqdHJ1c3NpbmZvLCBpbnQgbmFyZ3MpIHsK LSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAgIGludCBzeXNjYWxsX251bTsK ICAgaW50IGk7CiAgIHVuc2lnbmVkIGxvbmcgKnBhcm1fb2Zmc2V0OwogICBzdHJ1Y3Qgc3lzY2Fs bCAqc2M7CiAKLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9IGNwaWQpIHsKLSAg ICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7Ci0gICAgZmQg PSBvcGVuKGJ1ZiwgT19SRFdSKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmludGYo dHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsKLSAg ICAgIHJldHVybjsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwotICB9CisgIGNw aWQgPSB0cnVzc2luZm8tPnBpZDsKIAogICBjbGVhcl9mc2MoKTsKLSAgbHNlZWsoZmQsIDBMLCAw KTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkg eworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8IDAp IHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFEIFJFR0lT VEVSUyAtLVxuIik7CiAgICAgcmV0dXJuOwogICB9CkBAIC0yMDQsNyArMTkyLDcgQEAKIAkgICAg ICBpIDwgKGZzYy5uYXJncyAtIDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAgICAgICBpZiAoc2Mg JiYgIShzYy0+YXJnc1tpXS50eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9h cmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOworCWZzYy5z X2FyZ3NbaV0gPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZv KTsKICAgICAgIH0KICAgICB9CiAjaWYgREVCVUcKQEAgLTI2MCwyNSArMjQ4LDE1IEBACiBsb25n CiBpYTY0X3N5c2NhbGxfZXhpdChzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm8sIGludCBzeXNj YWxsX251bSBfX3VudXNlZCkKIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7 CiAgIGxvbmcgcmV0dmFsOwogICBpbnQgaTsKICAgaW50IGVycm9ycDsKICAgc3RydWN0IHN5c2Nh bGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0g ICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwotICAgIGZk ID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmlu dGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsK LSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0g IH0KKyAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwogCi0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlm IChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVncykpIHsKKyAgaWYg KHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKSB7CiAgICAg ZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMgLS1c biIpOwogICAgIHJldHVybiAoLTEpOwogICB9CkBAIC0zMDksNyArMjg3LDcgQEAKIAlpZiAoZXJy b3JwKQogCSAgYXNwcmludGYoJnRlbXAsICIweCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9m ZnNldF0pOwogCWVsc2UKLQkgIHRlbXAgPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0s IGZzYy5hcmdzLCByZXR2YWwsIHRydXNzaW5mbyk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+ YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0g dGVtcDsKICAgICAgIH0KICAgICB9Cj09PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNy LmJpbi90cnVzcy9tYWluLmMjMjQgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3Ry dXNzL3Vzci5iaW4vdHJ1c3MvbWFpbi5jIzQgKHRleHQra28pID09PT0gY29udGVudApAQCAtMzks MTEgKzM5LDEwIEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5 cy9pb2N0bC5oPgotI2luY2x1ZGUgPHN5cy9waW9jdGwuaD4KICNpbmNsdWRlIDxzeXMvdHlwZXMu aD4KICNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgorI2lu Y2x1ZGUgPHN5cy9zeXNjdGwuaD4KIAogI2luY2x1ZGUgPGN0eXBlLmg+CiAjaW5jbHVkZSA8ZXJy Lmg+CkBAIC01OSwxMyArNTgsOCBAQAogI2luY2x1ZGUgInRydXNzLmgiCiAjaW5jbHVkZSAiZXh0 ZXJuLmgiCiAKLS8qCi0gKiBJdCdzIGRpZmZpY3VsdCB0byBwYXJhbWV0ZXJpemUgdGhpcyBiZWNh dXNlIGl0IG11c3QgYmUKLSAqIGFjY2Vzc2libGUgaW4gYSBzaWduYWwgaGFuZGxlci4KLSAqLwor I2RlZmluZSBNQVhBUkdTIDUKIAotaW50IFByb2NmZDsKLQogc3RhdGljIHZvaWQKIHVzYWdlKHZv aWQpCiB7CkBAIC0xMTksMTggKzExMywxOSBAQAogc2V0X2V0eXBlKHN0cnVjdCB0cnVzc2luZm8g KnRydXNzaW5mbykKIHsKIAlzdHJ1Y3QgZXhfdHlwZXMgKmZ1bmNzOwotCWNoYXIgZXR5cGVbMjRd OwogCWNoYXIgcHJvZ3RbMzJdOwotCWludCBmZDsKKwkKKwlzaXplX3QgbGVuID0gc2l6ZW9mKHBy b2d0KTsKKwlpbnQgbWliWzRdOworCWludCBlcnJvcjsKIAotCXNwcmludGYoZXR5cGUsICIvcHJv Yy8lZC9ldHlwZSIsIHRydXNzaW5mby0+cGlkKTsKLQlpZiAoKGZkID0gb3BlbihldHlwZSwgT19S RE9OTFkpKSA9PSAtMSkgewotCQlzdHJjcHkocHJvZ3QsICJGcmVlQlNEIGEub3V0Iik7Ci0JfSBl bHNlIHsKLQkJaW50IGxlbiA9IHJlYWQoZmQsIHByb2d0LCBzaXplb2YocHJvZ3QpKTsKLQkJcHJv Z3RbbGVuLTFdID0gJ1wwJzsKLQkJY2xvc2UoZmQpOwotCX0KKwltaWJbMF0gPSBDVExfS0VSTjsK KwltaWJbMV0gPSBLRVJOX1BST0M7CisJbWliWzJdID0gS0VSTl9QUk9DX1NWX05BTUU7CisJbWli WzNdID0gdHJ1c3NpbmZvLT5waWQ7CisJZXJyb3IgPSBzeXNjdGwobWliLCA0LCBwcm9ndCwgJmxl biwgTlVMTCwgMCk7CisJaWYgKGVycm9yICE9IDApCisJCWVycigxLCAiY2FuIG5vdCBzeXNjdGwi KTsKIAogCWZvciAoZnVuY3MgPSBleF90eXBlczsgZnVuY3MtPnR5cGU7IGZ1bmNzKyspCiAJCWlm ICghc3RyY21wKGZ1bmNzLT50eXBlLCBwcm9ndCkpCkBAIC0xNjcsMTQgKzE2MiwxMiBAQAogCWlu dCBjOwogCWludCBpOwogCWNoYXIgKipjb21tYW5kOwotCXN0cnVjdCBwcm9jZnNfc3RhdHVzIHBm czsKIAlzdHJ1Y3QgZXhfdHlwZXMgKmZ1bmNzOwotCWludCBpbl9leGVjLCBzaWdleGl0LCBpbml0 aWFsX29wZW47CisJaW50IHNpZ2V4aXQsIGluaXRpYWxfb3BlbjsKIAljaGFyICpmbmFtZTsKIAlz dHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm87CiAJY2hhciAqc2lnbmFtZTsKIAotCWluX2V4ZWMg PSAwOwogCXNpZ2V4aXQgPSAwOwogCWZuYW1lID0gTlVMTDsKIAlpbml0aWFsX29wZW4gPSAxOwpA QCAtMTg2LDYgKzE3OSw3IEBACiAJYnplcm8odHJ1c3NpbmZvLCBzaXplb2Yoc3RydWN0IHRydXNz aW5mbykpOwogCXRydXNzaW5mby0+b3V0ZmlsZSA9IHN0ZGVycjsKIAl0cnVzc2luZm8tPnN0cnNp emUgPSAzMjsKKwl0cnVzc2luZm8tPnByX3doeSA9IFNfTk9ORTsKIAogCXdoaWxlICgoYyA9IGdl dG9wdChhYywgYXYsICJwOm86ZmFlZERzOlMiKSkgIT0gLTEpIHsKIAkJc3dpdGNoIChjKSB7CkBA IC0yNDUsNiArMjM5LDcgQEAKIAkJc2lnbmFsKFNJR1RFUk0sIFNJR19JR04pOwogCQlzaWduYWwo U0lHUVVJVCwgU0lHX0lHTik7CiAJfSBlbHNlIHsKKwkJc3RhcnRfdHJhY2luZyh0cnVzc2luZm8t PnBpZCk7CiAJCXNpZ25hbChTSUdJTlQsIHJlc3RvcmVfcHJvYyk7CiAJCXNpZ25hbChTSUdURVJN LCByZXN0b3JlX3Byb2MpOwogCQlzaWduYWwoU0lHUVVJVCwgcmVzdG9yZV9wcm9jKTsKQEAgLTI1 NywxOCArMjUyLDkgQEAKIAkgKi8KIAogU1RBUlRfVFJBQ0U6Ci0JUHJvY2ZkID0gc3RhcnRfdHJh Y2luZygKLQkgICAgdHJ1c3NpbmZvLT5waWQsIGluaXRpYWxfb3BlbiwKLQkgICAgU19FWEVDIHwg U19TQ0UgfCBTX1NDWCB8IFNfQ09SRSB8IFNfRVhJVCB8Ci0JICAgICgodHJ1c3NpbmZvLT5mbGFn cyAmIE5PU0lHUykgPyAwIDogU19TSUcpLAotCSAgICAoKHRydXNzaW5mby0+ZmxhZ3MgJiBGT0xM T1dGT1JLUykgPyBQRl9GT1JLIDogMCkpOworCWZ1bmNzID0gc2V0X2V0eXBlKHRydXNzaW5mbyk7 CisKIAlpbml0aWFsX29wZW4gPSAwOwotCWlmIChQcm9jZmQgPT0gLTEpCi0JCXJldHVybiAoMCk7 Ci0KLQlwZnMud2h5ID0gMDsKLQotCWZ1bmNzID0gc2V0X2V0eXBlKHRydXNzaW5mbyk7CiAJLyoK IAkgKiBBdCB0aGlzIHBvaW50LCBpdCdzIGEgc2ltcGxlIGxvb3AsIHdhaXRpbmcgZm9yIHRoZSBw cm9jZXNzIHRvCiAJICogc3RvcCwgZmluZGluZyBvdXQgd2h5LCBwcmludGluZyBvdXQgd2h5LCBh bmQgdGhlbiBjb250aW51aW5nIGl0LgpAQCAtMjc4LDExOCArMjY0LDkyIEBACiAJY2xvY2tfZ2V0 dGltZShDTE9DS19SRUFMVElNRSwgJnRydXNzaW5mby0+c3RhcnRfdGltZSk7CiAKIAlkbyB7Ci0J CWludCB2YWwgPSAwOwogCQlzdHJ1Y3QgdGltZXNwZWMgdGltZWRpZmY7CisJCXdhaXRldmVudCh0 cnVzc2luZm8pOwogCi0JCWlmIChpb2N0bChQcm9jZmQsIFBJT0NXQUlULCAmcGZzKSA9PSAtMSkK LQkJCXdhcm4oIlBJT0NXQUlUIHRvcCBvZiBsb29wIik7Ci0JCWVsc2UgewotCQkJc3dpdGNoKGkg PSBwZnMud2h5KSB7Ci0JCQljYXNlIFNfU0NFOgotCQkJCWZ1bmNzLT5lbnRlcl9zeXNjYWxsKHRy dXNzaW5mbywgcGZzLnZhbCk7Ci0JCQkJY2xvY2tfZ2V0dGltZShDTE9DS19SRUFMVElNRSwKLQkJ CQkgICAgJnRydXNzaW5mby0+YmVmb3JlKTsKLQkJCQlicmVhazsKLQkJCWNhc2UgU19TQ1g6Ci0J CQkJY2xvY2tfZ2V0dGltZShDTE9DS19SRUFMVElNRSwKLQkJCQkgICAgJnRydXNzaW5mby0+YWZ0 ZXIpOwotCQkJCS8qCi0JCQkJICogVGhpcyBpcyBzbyB3ZSBkb24ndCBnZXQgdHdvIG1lc3NhZ2Vz IGZvcgotCQkJCSAqIGFuIGV4ZWMgLS0gb25lIGZvciB0aGUgU19FWEVDLCBhbmQgb25lIGZvcgot CQkJCSAqIHRoZSBzeXNjYWxsIGV4aXQuICBJdCBhbHNvLCBjb252ZW5pZW50bHksCi0JCQkJICog ZW5zdXJlcyB0aGF0IHRoZSBmaXJzdCBtZXNzYWdlIHByaW50ZWQgb3V0Ci0JCQkJICogaXNuJ3Qg dGhlIHJldHVybi1mcm9tLXN5c2NhbGwgdXNlZCB0bwotCQkJCSAqIGNyZWF0ZSB0aGUgcHJvY2Vz cy4KLQkJCQkgKi8KLQkJCQlpZiAoaW5fZXhlYykgewotCQkJCQlpbl9leGVjID0gMDsKLQkJCQkJ YnJlYWs7Ci0JCQkJfQorCQlzd2l0Y2goaSA9IHRydXNzaW5mby0+cHJfd2h5KSB7CisJCWNhc2Ug U19TQ0U6CisJCQlmdW5jcy0+ZW50ZXJfc3lzY2FsbCh0cnVzc2luZm8sIE1BWEFSR1MpOworCQkJ Y2xvY2tfZ2V0dGltZShDTE9DS19SRUFMVElNRSwKKwkJCSAgICAmdHJ1c3NpbmZvLT5iZWZvcmUp OworCQkJYnJlYWs7CisJCWNhc2UgU19TQ1g6CisJCQljbG9ja19nZXR0aW1lKENMT0NLX1JFQUxU SU1FLAorCQkJICAgICZ0cnVzc2luZm8tPmFmdGVyKTsKIAotCQkJCWlmICh0cnVzc2luZm8tPmlu X2ZvcmsgJiYKLQkJCQkgICAgKHRydXNzaW5mby0+ZmxhZ3MgJiBGT0xMT1dGT1JLUykpIHsKLQkJ CQkJaW50IGNoaWxkcGlkOworCQkJaWYgKHRydXNzaW5mby0+aW5fZm9yayAmJgorCQkJICAgICh0 cnVzc2luZm8tPmZsYWdzICYgRk9MTE9XRk9SS1MpKSB7CisJCQkJaW50IGNoaWxkcGlkOwogCi0J CQkJCXRydXNzaW5mby0+aW5fZm9yayA9IDA7Ci0JCQkJCWNoaWxkcGlkID0KLQkJCQkJICAgIGZ1 bmNzLT5leGl0X3N5c2NhbGwodHJ1c3NpbmZvLAotCQkJCQkJcGZzLnZhbCk7CisJCQkJdHJ1c3Np bmZvLT5pbl9mb3JrID0gMDsKKwkJCQljaGlsZHBpZCA9CisJCQkJICAgIGZ1bmNzLT5leGl0X3N5 c2NhbGwodHJ1c3NpbmZvLAorCQkJCQl0cnVzc2luZm8tPnByX2RhdGEpOwogCi0JCQkJCS8qCi0J CQkJCSAqIEZvcmsgYSBuZXcgY29weSBvZiBvdXJzZWxmIHRvIHRyYWNlCi0JCQkJCSAqIHRoZSBj aGlsZCBvZiB0aGUgb3JpZ2luYWwgdHJhY2VkCi0JCQkJCSAqIHByb2Nlc3MuCi0JCQkJCSAqLwot CQkJCQlpZiAoZm9yaygpID09IDApIHsKLQkJCQkJCXRydXNzaW5mby0+cGlkID0gY2hpbGRwaWQ7 Ci0JCQkJCQlnb3RvIFNUQVJUX1RSQUNFOwotCQkJCQl9Ci0JCQkJCWJyZWFrOworCQkJCS8qCisJ CQkJICogRm9yayBhIG5ldyBjb3B5IG9mIG91cnNlbGYgdG8gdHJhY2UKKwkJCQkgKiB0aGUgY2hp bGQgb2YgdGhlIG9yaWdpbmFsIHRyYWNlZAorCQkJCSAqIHByb2Nlc3MuCisJCQkJICovCisJCQkJ aWYgKGZvcmsoKSA9PSAwKSB7CisJCQkJCXRydXNzaW5mby0+cGlkID0gY2hpbGRwaWQ7CisJCQkJ CXN0YXJ0X3RyYWNpbmcodHJ1c3NpbmZvLT5waWQpOworCQkJCQlnb3RvIFNUQVJUX1RSQUNFOwog CQkJCX0KLQkJCQlmdW5jcy0+ZXhpdF9zeXNjYWxsKHRydXNzaW5mbywgcGZzLnZhbCk7CiAJCQkJ YnJlYWs7Ci0JCQljYXNlIFNfU0lHOgotCQkJCWlmICh0cnVzc2luZm8tPmZsYWdzICYgRk9MTE9X Rk9SS1MpCi0JCQkJCWZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiJTVkOiAiLAotCQkJCQkg ICAgdHJ1c3NpbmZvLT5waWQpOwotCQkJCWlmICh0cnVzc2luZm8tPmZsYWdzICYgQUJTT0xVVEVU SU1FU1RBTVBTKSB7Ci0JCQkJCXRpbWVzcGVjc3VidCgmdHJ1c3NpbmZvLT5hZnRlciwKLQkJCQkJ ICAgICZ0cnVzc2luZm8tPnN0YXJ0X3RpbWUsICZ0aW1lZGlmZik7Ci0JCQkJCWZwcmludGYodHJ1 c3NpbmZvLT5vdXRmaWxlLCAiJWxkLiUwOWxkICIsCi0JCQkJCSAgICAobG9uZyl0aW1lZGlmZi50 dl9zZWMsCi0JCQkJCSAgICB0aW1lZGlmZi50dl9uc2VjKTsKLQkJCQl9Ci0JCQkJaWYgKHRydXNz aW5mby0+ZmxhZ3MgJiBSRUxBVElWRVRJTUVTVEFNUFMpIHsKLQkJCQkJdGltZXNwZWNzdWJ0KCZ0 cnVzc2luZm8tPmFmdGVyLAotCQkJCQkgICAgJnRydXNzaW5mby0+YmVmb3JlLCAmdGltZWRpZmYp OwotCQkJCQlmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiVsZC4lMDlsZCAiLAotCQkJCQkg ICAgKGxvbmcpdGltZWRpZmYudHZfc2VjLAotCQkJCQkgICAgdGltZWRpZmYudHZfbnNlYyk7Ci0J CQkJfQotCQkJCXNpZ25hbWUgPSBzdHJzaWcocGZzLnZhbCk7Ci0JCQkJZnByaW50Zih0cnVzc2lu Zm8tPm91dGZpbGUsCi0JCQkJICAgICJTSUdOQUwgJWx1ICglcylcbiIsIHBmcy52YWwsCi0JCQkJ ICAgIHNpZ25hbWUgPT0gTlVMTCA/ICI/IiA6IHNpZ25hbWUpOwotCQkJCWZyZWUoc2lnbmFtZSk7 Ci0JCQkJc2lnZXhpdCA9IHBmcy52YWw7CisJCQl9CisJCQlmdW5jcy0+ZXhpdF9zeXNjYWxsKHRy dXNzaW5mbywgTUFYQVJHUyk7CisJCQlicmVhazsKKwkJY2FzZSBTX1NJRzoKKwkJCWlmICh0cnVz c2luZm8tPmZsYWdzICYgTk9TSUdTKQogCQkJCWJyZWFrOwotCQkJY2FzZSBTX0VYSVQ6Ci0JCQkJ aWYgKHRydXNzaW5mby0+ZmxhZ3MgJiBGT0xMT1dGT1JLUykKLQkJCQkJZnByaW50Zih0cnVzc2lu Zm8tPm91dGZpbGUsICIlNWQ6ICIsCi0JCQkJCSAgICB0cnVzc2luZm8tPnBpZCk7Ci0JCQkJaWYg KHRydXNzaW5mby0+ZmxhZ3MgJiBBQlNPTFVURVRJTUVTVEFNUFMpIHsKLQkJCQkJdGltZXNwZWNz dWJ0KCZ0cnVzc2luZm8tPmFmdGVyLAotCQkJCQkgICAgJnRydXNzaW5mby0+c3RhcnRfdGltZSwg JnRpbWVkaWZmKTsKLQkJCQkJZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQg IiwKLQkJCQkJICAgIChsb25nKXRpbWVkaWZmLnR2X3NlYywKLQkJCQkJICAgIHRpbWVkaWZmLnR2 X25zZWMpOwotCQkJCX0KLQkJCQlpZiAodHJ1c3NpbmZvLT5mbGFncyAmIFJFTEFUSVZFVElNRVNU QU1QUykgewotCQkJCSAgdGltZXNwZWNzdWJ0KCZ0cnVzc2luZm8tPmFmdGVyLAotCQkJCSAgICAg ICZ0cnVzc2luZm8tPmJlZm9yZSwgJnRpbWVkaWZmKTsKLQkJCQkgIGZwcmludGYodHJ1c3NpbmZv LT5vdXRmaWxlLCAiJWxkLiUwOWxkICIsCi0JCQkJICAgIChsb25nKXRpbWVkaWZmLnR2X3NlYywg dGltZWRpZmYudHZfbnNlYyk7Ci0JCQkJfQotCQkJCWZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxl LAotCQkJCSAgICAicHJvY2VzcyBleGl0LCBydmFsID0gJWx1XG4iLCBwZnMudmFsKTsKLQkJCQli cmVhazsKLQkJCWNhc2UgU19FWEVDOgotCQkJCWZ1bmNzID0gc2V0X2V0eXBlKHRydXNzaW5mbyk7 Ci0JCQkJaW5fZXhlYyA9IDE7Ci0JCQkJYnJlYWs7Ci0JCQlkZWZhdWx0OgotCQkJCWZwcmludGYo dHJ1c3NpbmZvLT5vdXRmaWxlLAotCQkJCSAgICAiUHJvY2VzcyBzdG9wcGVkIGJlY2F1c2Ugb2Y6 ICAlZFxuIiwgaSk7Ci0JCQkJYnJlYWs7CisJCQlpZiAodHJ1c3NpbmZvLT5mbGFncyAmIEZPTExP V0ZPUktTKQorCQkJCWZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiJTVkOiAiLAorCQkJCSAg ICB0cnVzc2luZm8tPnBpZCk7CisJCQlpZiAodHJ1c3NpbmZvLT5mbGFncyAmIEFCU09MVVRFVElN RVNUQU1QUykgeworCQkJCXRpbWVzcGVjc3VidCgmdHJ1c3NpbmZvLT5hZnRlciwKKwkJCQkgICAg JnRydXNzaW5mby0+c3RhcnRfdGltZSwgJnRpbWVkaWZmKTsKKwkJCQlmcHJpbnRmKHRydXNzaW5m by0+b3V0ZmlsZSwgIiVsZC4lMDlsZCAiLAorCQkJCSAgICAobG9uZyl0aW1lZGlmZi50dl9zZWMs CisJCQkJICAgIHRpbWVkaWZmLnR2X25zZWMpOworCQkJfQorCQkJaWYgKHRydXNzaW5mby0+Zmxh Z3MgJiBSRUxBVElWRVRJTUVTVEFNUFMpIHsKKwkJCQl0aW1lc3BlY3N1YnQoJnRydXNzaW5mby0+ YWZ0ZXIsCisJCQkJICAgICZ0cnVzc2luZm8tPmJlZm9yZSwgJnRpbWVkaWZmKTsKKwkJCQlmcHJp bnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiVsZC4lMDlsZCAiLAorCQkJCSAgICAobG9uZyl0aW1l ZGlmZi50dl9zZWMsCisJCQkJICAgIHRpbWVkaWZmLnR2X25zZWMpOworCQkJfQorCQkJc2lnbmFt ZSA9IHN0cnNpZyh0cnVzc2luZm8tPnByX2RhdGEpOworCQkJZnByaW50Zih0cnVzc2luZm8tPm91 dGZpbGUsCisJCQkgICAgIlNJR05BTCAldSAoJXMpXG4iLCB0cnVzc2luZm8tPnByX2RhdGEsCisJ CQkgICAgc2lnbmFtZSA9PSBOVUxMID8gIj8iIDogc2lnbmFtZSk7CisJCQlmcmVlKHNpZ25hbWUp OworCQkJYnJlYWs7CisJCWNhc2UgU19FWElUOgorCQkJaWYgKHRydXNzaW5mby0+ZmxhZ3MgJiBG T0xMT1dGT1JLUykKKwkJCQlmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiU1ZDogIiwKKwkJ CQkgICAgdHJ1c3NpbmZvLT5waWQpOworCQkJaWYgKHRydXNzaW5mby0+ZmxhZ3MgJiBBQlNPTFVU RVRJTUVTVEFNUFMpIHsKKwkJCQl0aW1lc3BlY3N1YnQoJnRydXNzaW5mby0+YWZ0ZXIsCisJCQkJ ICAgICZ0cnVzc2luZm8tPnN0YXJ0X3RpbWUsICZ0aW1lZGlmZik7CisJCQkJZnByaW50Zih0cnVz c2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQgIiwKKwkJCQkgICAgKGxvbmcpdGltZWRpZmYudHZf c2VjLAorCQkJCSAgICB0aW1lZGlmZi50dl9uc2VjKTsKKwkJCX0KKwkJCWlmICh0cnVzc2luZm8t PmZsYWdzICYgUkVMQVRJVkVUSU1FU1RBTVBTKSB7CisJCQkgIHRpbWVzcGVjc3VidCgmdHJ1c3Np bmZvLT5hZnRlciwKKwkJCSAgICAgICZ0cnVzc2luZm8tPmJlZm9yZSwgJnRpbWVkaWZmKTsKKwkJ CSAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQgIiwKKwkJCSAgICAobG9u Zyl0aW1lZGlmZi50dl9zZWMsIHRpbWVkaWZmLnR2X25zZWMpOwogCQkJfQorCQkJZnByaW50Zih0 cnVzc2luZm8tPm91dGZpbGUsCisJCQkgICAgInByb2Nlc3MgZXhpdCwgcnZhbCA9ICV1XG4iLCB0 cnVzc2luZm8tPnByX2RhdGEpOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQlicmVhazsKIAkJ fQotCQlpZiAoaW9jdGwoUHJvY2ZkLCBQSU9DQ09OVCwgdmFsKSA9PSAtMSkgewotCQkJaWYgKGtp bGwodHJ1c3NpbmZvLT5waWQsIDApID09IC0xICYmIGVycm5vID09IEVTUkNIKQotCQkJCWJyZWFr OwotCQkJZWxzZQotCQkJCXdhcm4oIlBJT0NDT05UIik7Ci0JCX0KLQl9IHdoaWxlIChwZnMud2h5 ICE9IFNfRVhJVCk7CisJfSB3aGlsZSAodHJ1c3NpbmZvLT5wcl93aHkgIT0gU19FWElUKTsKIAlm Zmx1c2godHJ1c3NpbmZvLT5vdXRmaWxlKTsKIAlpZiAoc2lnZXhpdCkgewogCQlzdHJ1Y3Qgcmxp bWl0IHJscDsKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL3Bv d2VycGMtZmJzZC5jIzEgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vz ci5iaW4vdHJ1c3MvcG93ZXJwYy1mYnNkLmMjMyAodGV4dCtrbykgPT09PSBjb250ZW50CkBAIC00 MSw4ICs0MSw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5 cy9pb2N0bC5oPgotI2luY2x1ZGUgPHN5cy9waW9jdGwuaD4KKyNpbmNsdWRlIDxzeXMvcHRyYWNl Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c2NhbGwuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvcmVnLmg+ CkBAIC02Miw3ICs2MSw2IEBACiAjaW5jbHVkZSAic3lzY2FsbC5oIgogI2luY2x1ZGUgImV4dGVy bi5oIgogCi1zdGF0aWMgaW50IGZkID0gLTE7CiBzdGF0aWMgaW50IGNwaWQgPSAtMTsKIAogI2lu Y2x1ZGUgInN5c2NhbGxzLmgiCkBAIC0xMjAsMTkgKzExOCwxMCBAQAogICB1bnNpZ25lZCBpbnQg cmVnYXJnczsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVz c2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwg dHJ1c3NpbmZvLT5waWQpOwotICAgIGZkID0gb3BlbihidWYsIE9fUkRXUik7Ci0gICAgaWYgKGZk ID09IC0xKSB7Ci0gICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBP UEVOIFJFR0lTVEVSUyAtLVxuIik7Ci0gICAgICByZXR1cm47Ci0gICAgfQotICAgIGNwaWQgPSB0 cnVzc2luZm8tPnBpZDsKLSAgfQorICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7CiAKICAgY2xlYXJf ZnNjKCk7Ci0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlmIChyZWFkKGZkLCAmcmVncywgc2l6ZW9m KHJlZ3MpKSAhPSBzaXplb2YocmVncykpIHsKKyAgaWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlk LCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKSB7CiAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZp bGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMgLS1cbiIpOwogICAgIHJldHVybjsKICAgfQpA QCAtMTc2LDkgKzE2NSwxNiBAQAogICBmc2MuYXJncyA9IG1hbGxvYygoMStuYXJncykgKiBzaXpl b2YodW5zaWduZWQgbG9uZykpOwogCiAgIGlmIChuYXJncyA+IHJlZ2FyZ3MpIHsKKyAgICBzdHJ1 Y3QgcHRyYWNlX2lvX2Rlc2MgaW9yZXF1ZXN0OwogICAgIG1lbW1vdmUoJmZzYy5hcmdzWzBdLCBh cmdzLCByZWdhcmdzICogc2l6ZW9mKGZzYy5hcmdzWzBdKSk7Ci0gICAgbHNlZWsoUHJvY2ZkLCBy ZWdzLmZpeHJlZ1sxXSArIDgsIFNFRUtfU0VUKTsKLSAgICByZWFkKFByb2NmZCwgJmZzYy5hcmdz W3JlZ2FyZ3NdLCAobmFyZ3MgLSByZWdhcmdzKSAqIHNpemVvZihmc2MuYXJnc1swXSkpOworCisg ICAgaW9yZXF1ZXN0LnBpb2Rfb3AgPSBQSU9EX1JFQURfRDsKKyAgICBpb3JlcXVlc3QucGlvZF9v ZmZzID0gKHZvaWQgKikocmVncy5maXhyZWdbMV0gKyA4KTsKKyAgICBpb3JlcXVlc3QucGlvZF9h ZGRyID0gJmZzYy5hcmdzW3JlZ2FyZ3NdOworICAgIGlvcmVxdWVzdC5waW9kX2xlbiA9IChuYXJn cyAtIHJlZ2FyZ3MpICogc2l6ZW9mKGZzYy5hcmdzWzBdKTsKKyAgICBwdHJhY2UoUFRfSU8sIGNw aWQsIChjYWRkcl90KSZpb3JlcXVlc3QsIDApOworICAgIGlmIChpb3JlcXVlc3QucGlvZF9sZW4g PT0gMCkKKyAgICAgICByZXR1cm47CiAgIH0gZWxzZSB7CiAgICAgbWVtbW92ZSgmZnNjLmFyZ3Nb MF0sIGFyZ3MsIG5hcmdzICogc2l6ZW9mKGZzYy5hcmdzWzBdKSk7CiAgIH0KQEAgLTIyMCw3ICsy MTYsNyBAQAogCSAgICAgIGkgPCAoZnNjLm5hcmdzIC0gMSkgPyAiLCIgOiAiIik7CiAjZW5kaWYK ICAgICAgIGlmIChzYyAmJiAhKHNjLT5hcmdzW2ldLnR5cGUgJiBPVVQpKSB7Ci0JZnNjLnNfYXJn c1tpXSA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIDAsIHRydXNz aW5mbyk7CisJZnNjLnNfYXJnc1tpXSA9IHByaW50X2FyZygmc2MtPmFyZ3NbaV0sIGZzYy5hcmdz LCAwLCB0cnVzc2luZm8pOwogICAgICAgfQogICAgIH0KICNpZiBERUJVRwpAQCAtMjc1LDI1ICsy NzEsMTUgQEAKIGxvbmcKIHBvd2VycGNfc3lzY2FsbF9leGl0KHN0cnVjdCB0cnVzc2luZm8gKnRy dXNzaW5mbywgaW50IHN5c2NhbGxfbnVtIF9fdW51c2VkKQogewotICBjaGFyIGJ1ZlszMl07CiAg IHN0cnVjdCByZWcgcmVnczsKICAgbG9uZyByZXR2YWw7CiAgIGludCBpOwogICBpbnQgZXJyb3Jw OwogICBzdHJ1Y3Qgc3lzY2FsbCAqc2M7CiAKLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+ cGlkICE9IGNwaWQpIHsKLSAgICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2lu Zm8tPnBpZCk7Ci0gICAgZmQgPSBvcGVuKGJ1ZiwgT19SRE9OTFkpOwotICAgIGlmIChmZCA9PSAt MSkgewotICAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgT1BFTiBS RUdJU1RFUlMgLS1cbiIpOwotICAgICAgcmV0dXJuICgtMSk7Ci0gICAgfQotICAgIGNwaWQgPSB0 cnVzc2luZm8tPnBpZDsKLSAgfQorICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7CiAKLSAgbHNlZWso ZmQsIDBMLCAwKTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVv ZihyZWdzKSkgeworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdz LCAwKSA8IDApIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIlxuIik7CiAgICAg cmV0dXJuICgtMSk7CiAgIH0KQEAgLTMzMiw3ICszMTgsNyBAQAogCWlmIChlcnJvcnApCiAJICBh c3ByaW50ZigmdGVtcCwgIjB4JWx4IiwgZnNjLmFyZ3Nbc2MtPmFyZ3NbaV0ub2Zmc2V0XSk7CiAJ ZWxzZQotCSAgdGVtcCA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3Ms IHJldHZhbCwgdHJ1c3NpbmZvKTsKKwkgIHRlbXAgPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBm c2MuYXJncywgcmV0dmFsLCB0cnVzc2luZm8pOwogCWZzYy5zX2FyZ3NbaV0gPSB0ZW1wOwogICAg ICAgfQogICAgIH0KPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNz L3NldHVwLmMjMTEgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5i aW4vdHJ1c3Mvc2V0dXAuYyM1ICh0ZXh0K2tvKSA9PT09IGNvbnRlbnQKQEAgLTM4LDExICszOCwx MiBAQAogICovCiAKICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KLSNpbmNsdWRlIDxzeXMvaW9jdGwu aD4KLSNpbmNsdWRlIDxzeXMvcGlvY3RsLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5j bHVkZSA8c3lzL3B0cmFjZS5oPgogI2luY2x1ZGUgPHN5cy93YWl0Lmg+CiAKICNpbmNsdWRlIDxl cnIuaD4KKyNpbmNsdWRlIDxlcnJuby5oPgogI2luY2x1ZGUgPGZjbnRsLmg+CiAjaW5jbHVkZSA8 c2lnbmFsLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KQEAgLTUxLDEwICs1MiwxMiBAQAogI2luY2x1 ZGUgPHRpbWUuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAorI2luY2x1ZGUgPG1hY2hpbmUvcmVn Lmg+CisKICNpbmNsdWRlICJ0cnVzcy5oIgogI2luY2x1ZGUgImV4dGVybi5oIgogCi1zdGF0aWMg aW50IGV2ZmxhZ3MgPSAwOworc3RhdGljIGludCBjaGlsZF9waWQ7CiAKIC8qCiAgKiBzZXR1cF9h bmRfd2FpdCgpIGlzIGNhbGxlZCB0byBzdGFydCBhIHByb2Nlc3MuICBBbGwgaXQgcmVhbGx5IGRv ZXMKQEAgLTY2LDc1ICs2OSwyOCBAQAogaW50CiBzZXR1cF9hbmRfd2FpdChjaGFyICpjb21tYW5k W10pCiB7Ci0Jc3RydWN0IHByb2Nmc19zdGF0dXMgcGZzOwotCWNoYXIgYnVmWzMyXTsKLQlpbnQg ZmQ7CiAJaW50IHBpZDsKLQlpbnQgZmxhZ3M7Ci0JaW50IGxvb3A7CisJaW50IHdhaXR2YWw7CiAK LQlwaWQgPSBmb3JrKCk7CisJcGlkID0gdmZvcmsoKTsKIAlpZiAocGlkID09IC0xKSB7CiAJCWVy cigxLCAiZm9yayBmYWlsZWQiKTsKIAl9CiAJaWYgKHBpZCA9PSAwKSB7CS8qIENoaWxkICovCi0J CWludCBtYXNrID0gU19FWEVDIHwgU19FWElUOwotCQlmZCA9IG9wZW4oIi9wcm9jL2N1cnByb2Mv bWVtIiwgT19XUk9OTFkpOwotCQlpZiAoZmQgPT0gLTEpCi0JCQllcnIoMiwgImNhbm5vdCBvcGVu IC9wcm9jL2N1cnByb2MvbWVtIik7Ci0JCWZjbnRsKGZkLCBGX1NFVEZELCAxKTsKLQkJaWYgKGlv Y3RsKGZkLCBQSU9DQklTLCBtYXNrKSA9PSAtMSkKLQkJCWVycigzLCAiUElPQ0JJUyIpOwotCQlm bGFncyA9IFBGX0xJTkdFUjsKLQkJLyoKLQkJICogVGhlIFBGX0xJTkdFUiBmbGFnIHRlbGxzIHBy b2NmcyBub3QgdG8gd2FrZSB1cCB0aGUKLQkJICogcHJvY2VzcyBvbiBsYXN0IGNsb3NlOyBub3Jt YWxseSwgdGhpcyBpcyB0aGUgYmVoYXZpb3VyCi0JCSAqIHdlIHdhbnQuCi0JCSAqLwotCQlpZiAo aW9jdGwoZmQsIFBJT0NTRkwsIGZsYWdzKSA9PSAtMSkKLQkJCXdhcm4oImNhbm5vdCBzZXQgUEZf TElOR0VSIik7CisJCXB0cmFjZShQVF9UUkFDRV9NRSwgMCwgMCwgMCk7CisJCXNldHBnaWQgKDAs IDApOyAKIAkJZXhlY3ZwKGNvbW1hbmRbMF0sIGNvbW1hbmQpOwotCQltYXNrID0gfjA7Ci0JCWlv Y3RsKGZkLCBQSU9DQklDLCB+MCk7CiAJCWVycig0LCAiZXhlY3ZwICVzIiwgY29tbWFuZFswXSk7 CiAJfQorCQogCS8qIE9ubHkgaW4gdGhlIHBhcmVudCBoZXJlICovCi0KLQlpZiAod2FpdHBpZChw aWQsIE5VTEwsIFdOT0hBTkcpICE9IDApIHsKLQkJLyoKLQkJICogUHJvY2VzcyBleGl0ZWQgYmVm b3JlIGl0IGdvdCB0byB1cyAtLSBtZWFuaW5nIHRoZSBleGVjIGZhaWxlZAotCQkgKiBtaXNlcmFi bHkgLS0gc28gd2UganVzdCBxdWlldGx5IGV4aXQuCi0JCSAqLwotCQlleGl0KDEpOworCWlmICh3 YWl0cGlkKHBpZCwgJndhaXR2YWwsIDApIDwgLTEpIHsKKwkJZXJyKDEsICJ1bmV4cGVjdCBzdG9w IGluIHdhaXRwaWQiKTsKKwkJcmV0dXJuIDA7CiAJfQogCi0Jc3ByaW50ZihidWYsICIvcHJvYy8l ZC9tZW0iLCBwaWQpOwotCi0JLyogVHJ5IDYgdGltZXMgdG8gdHJhY2Ugb3VyIGNoaWxkLCB3YWl0 aW5nIDEvMiBzZWNvbmQgZWFjaCB0aW1lICovCi0JZm9yIChsb29wPTYgOzsgbG9vcC0tKSB7Ci0J CWlmIChsb29wICE9IDYpCi0JCQl1c2xlZXAoNTAwMDAwKTsKLQkJaWYgKChmZCA9IG9wZW4oYnVm LCBPX1JEV1IpKSA9PSAtMSkgewotCQkJaWYgKGxvb3AgPiAwKQotCQkJCWNvbnRpbnVlOwotCQkJ ZWxzZQotCQkJCWVycig1LCAiY2Fubm90IG9wZW4xICVzIiwgYnVmKTsKLQkJfQotCQlpZiAoaW9j dGwoZmQsIFBJT0NXQUlULCAmcGZzKSA9PSAtMSkgewotCQkJaWYgKGxvb3AgPj0gMCkKLQkJCQlj b250aW51ZTsKLQkJCWVsc2UKLQkJCQllcnIoNiwgIlBJT0NXQUlUIik7Ci0JCX0KLQkJaWYgKHBm cy53aHkgPT0gU19FWElUKSB7Ci0JCQl3YXJueCgicHJvY2VzcyBleGl0ZWQgYmVmb3JlIGV4ZWMn aW5nIik7Ci0JCQlpb2N0bChmZCwgUElPQ0NPTlQsIDApOwotCQkJd2FpdCgwKTsKLQkJCWV4aXQo Nyk7Ci0JCX0gZWxzZQotCQkJYnJlYWs7Ci0JfQotCWNsb3NlKGZkKTsKKwljaGlsZF9waWQgPSBw aWQ7CisJCiAJcmV0dXJuIChwaWQpOwogfQogCkBAIC0xNDUsNDUgKzEwMSwyNCBAQAogICovCiAK IGludAotc3RhcnRfdHJhY2luZyhpbnQgcGlkLCBpbnQgZmFpbGlzZmF0YWwsIGludCBldmVudGZs YWdzLCBpbnQgZmxhZ3MpCitzdGFydF90cmFjaW5nKGludCBwaWQpCiB7Ci0JaW50IGZkOwotCWNo YXIgYnVmWzMyXTsKLQlzdHJ1Y3QgcHJvY2ZzX3N0YXR1cyB0bXA7CisJaW50IHdhaXR2YWw7CisJ aW50IHJldDsKKwlpbnQgcmV0cnkgPSAxMDsKIAotCXNwcmludGYoYnVmLCAiL3Byb2MvJWQvbWVt IiwgcGlkKTsKLQkvKiB1c2xlZXAoNTAwMDAwKTsgKi8KKwlkbyB7CisJCXJldCA9IHB0cmFjZShQ VF9BVFRBQ0gsIHBpZCwgTlVMTCwgMCk7CisJCXVzbGVlcCgyMDApOworCX0gd2hpbGUocmV0ICYm IHJldHJ5LS0gPiAwKTsKKwlpZiAocmV0KQorCQllcnIoNSwgImNhbiBub3QgYXR0YWNoIHRvIHRh cmdldCBwcm9jZXNzIik7CiAKLQlmZCA9IG9wZW4oYnVmLCBPX1JEV1IpOwotCWlmIChmZCA9PSAt MSkgewotCQkvKgotCQkgKiBUaGUgcHJvY2VzcyBtYXkgaGF2ZSBydW4gYXdheSBiZWZvcmUgd2Ug Y291bGQgc3RhcnQgLS0gdGhpcwotCQkgKiBoYXBwZW5zIHdpdGggU1VHSUQgcHJvZ3JhbXMuICBT byB3ZSBuZWVkIHRvIHNlZSBpZiBpdCBzdGlsbAotCQkgKiBleGlzdHMgYmVmb3JlIHdlIGNvbXBs YWluIGJpdHRlcmx5LgotCQkgKi8KLQkJaWYgKCFmYWlsaXNmYXRhbCAmJiBraWxsKHBpZCwgMCkg PT0gLTEpCi0JCQlyZXR1cm4gKC0xKTsKLQkJZXJyKDgsICJjYW5ub3Qgb3BlbjIgJXMiLCBidWYp OwotCX0KKwljaGlsZF9waWQgPSBwaWQ7CQorCWlmICh3YWl0cGlkKHBpZCwgJndhaXR2YWwsIDAp IDwgLTEpIAorCQllcnIoMSwgIlVuZXhwZWN0IHN0b3AgaW4gd2FpdHBpZCIpOwogCi0JaWYgKGlv Y3RsKGZkLCBQSU9DU1RBVFVTLCAmdG1wKSA9PSAtMSkgewotCQllcnIoMTAsICJjYW5ub3QgZ2V0 IHByb2NmcyBzdGF0dXMgc3RydWN0Iik7Ci0JfQotCWV2ZmxhZ3MgPSB0bXAuZXZlbnRzOwotCi0J aWYgKGlvY3RsKGZkLCBQSU9DQklTLCBldmVudGZsYWdzKSA9PSAtMSkKLQkJZXJyKDksICJjYW5u b3Qgc2V0IHByb2NmcyBldmVudCBiaXQgbWFzayIpOwotCi0JLyoKLQkgKiBUaGlzIGNsZWFycyB0 aGUgUEZfTElOR0VSIHNldCBhYm92ZSBpbiBzZXR1cF9hbmRfd2FpdCgpOwotCSAqIGlmIHRydXNz IGhhcHBlbnMgdG8gZGllIGJlZm9yZSB0aGlzLCB0aGVuIHRoZSBwcm9jZXNzCi0JICogbmVlZHMg dG8gYmUgd29rZW4gdXAgdmlhIHByb2NjdGwuCi0JICovCi0KLQlpZiAoaW9jdGwoZmQsIFBJT0NT RkwsIGZsYWdzKSA9PSAtMSkKLQkJd2FybigiY2Fubm90IGNsZWFyIFBGX0xJTkdFUiIpOwotCi0J cmV0dXJuIChmZCk7CisJcmV0dXJuICgwKTsKIH0KIAogLyoKQEAgLTE5MywxMCArMTI4LDUxIEBA CiAgKiBwcm9jZXNzLgogICovCiB2b2lkCi1yZXN0b3JlX3Byb2MoaW50IHNpZ25vIF9fdW51c2Vk KSB7CityZXN0b3JlX3Byb2MoaW50IHNpZ25vIF9fdW51c2VkKQoreworCWludCB3YWl0dmFsOwor CQorCWtpbGwoY2hpbGRfcGlkLCBTSUdTVE9QKTsKKwlpZiAod2FpdHBpZChjaGlsZF9waWQsICZ3 YWl0dmFsLCAwKSA8IC0xKQorCQllcnIoMSwgIlVuZXhwZWN0IHN0b3AgaW4gd2FpdHBpZCIpOwog Ci0JaW9jdGwoUHJvY2ZkLCBQSU9DQklDLCB+MCk7Ci0JaWYgKGV2ZmxhZ3MpCi0JCWlvY3RsKFBy b2NmZCwgUElPQ0JJUywgZXZmbGFncyk7CisJaWYgKHB0cmFjZShQVF9ERVRBQ0gsIGNoaWxkX3Bp ZCwgKGNhZGRyX3QpMSwgMCkgPCAwKQorCQllcnIoNywgIkNhbiBub3QgZGV0YWNoIik7CisJCisJ a2lsbChjaGlsZF9waWQsIFNJR0NPTlQpOwogCWV4aXQoMCk7CiB9CisKK3ZvaWQgd2FpdGV2ZW50 KHN0cnVjdCB0cnVzc2luZm8gKmluZm8pCit7CisJaW50IHdhaXR2YWw7CisJc3RhdGljIGludCBp bl9zeXNjYWxsID0gMDsKKwkKKwlwdHJhY2UoUFRfU1lTQ0FMTCwgaW5mby0+cGlkLCAoY2FkZHJf dCkxLCAwKTsKKworCWlmICh3YWl0cGlkKGluZm8tPnBpZCwgJndhaXR2YWwsIDApIDwgLTEpIHsK KwkJZXJyKDEsICJ1bmV4cGVjdCBzdG9wIGluIHdhaXRwaWQiKTsKKwl9CisJCisJaWYgKFdJRkNP TlRJTlVFRCh3YWl0dmFsKSkgeworCQlpbmZvLT5wcl93aHkgPSBTX05PTkU7CisJCXJldHVybjsK Kwl9CisJaWYgKFdJRkVYSVRFRCh3YWl0dmFsKSkgeworCQlpbmZvLT5wcl93aHkgPSBTX0VYSVQ7 CisJCWluZm8tPnByX2RhdGEgPSBXRVhJVFNUQVRVUyh3YWl0dmFsKTsKKwkJcmV0dXJuOworCX0K KwlpZiAoV0lGU1RPUFBFRCh3YWl0dmFsKSB8fCAoV0lGU0lHTkFMRUQod2FpdHZhbCkpKSB7CisJ CXN3aXRjaChXU1RPUFNJRyh3YWl0dmFsKSkgeworCQljYXNlIFNJR1RSQVA6CisJCQlpbmZvLT5w cl93aHkgPSBpbl9zeXNjYWxsP1NfU0NYOlNfU0NFOworCQkJaW5fc3lzY2FsbCA9IDEgLSBpbl9z eXNjYWxsOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQlpbmZvLT5wcl93aHkgPSBTX1NJRzsK KwkJCWluZm8tPnByX2RhdGEgPSBXU1RPUFNJRyh3YWl0dmFsKTsKKwkJCWJyZWFrOworCQl9CisJ fQorfQo9PT09IC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3Vzci5iaW4vdHJ1c3Mvc3BhcmM2 NC1mYnNkLmMjOSAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJp bi90cnVzcy9zcGFyYzY0LWZic2QuYyMyICh0ZXh0K2tvKSA9PT09IGNvbnRlbnQKQEAgLTQ1LDgg KzQ1LDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL2lv Y3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgorI2luY2x1ZGUgPHN5cy9wdHJhY2UuaD4K ICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5jbHVkZSA8bWFjaGluZS9mcmFtZS5oPgpA QCAtNjgsNyArNjcsNiBAQAogI2luY2x1ZGUgInN5c2NhbGwuaCIKICNpbmNsdWRlICJleHRlcm4u aCIKIAotc3RhdGljIGludCBmZCA9IC0xOwogc3RhdGljIGludCBjcGlkID0gLTE7CiAKICNpbmNs dWRlICJzeXNjYWxscy5oIgpAQCAtMTE4LDI2ICsxMTYsMTggQEAKIAogdm9pZAogc3BhcmM2NF9z eXNjYWxsX2VudHJ5KHN0cnVjdCB0cnVzc2luZm8gKnRydXNzaW5mbywgaW50IG5hcmdzKSB7Ci0g IGNoYXIgYnVmWzMyXTsKICAgc3RydWN0IHJlZyByZWdzOwogICBpbnQgc3lzY2FsbF9udW07CiAg IGludCBpOwogICBzdHJ1Y3Qgc3lzY2FsbCAqc2M7CiAgIGludCBpbmRpciA9IDA7CS8qIGluZGly ZWN0IHN5c3RlbSBjYWxsICovCisgIHN0cnVjdCBwdHJhY2VfaW9fZGVzYyBpb3JlcXVlc3Q7CiAK LSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9IGNwaWQpIHsKLSAgICBzcHJpbnRm KGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7Ci0gICAgZmQgPSBvcGVuKGJ1 ZiwgT19SRFdSKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmludGYodHJ1c3NpbmZv LT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsKLSAgICAgIHJldHVy bjsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwotICB9CisgIGNwaWQgPSB0cnVz c2luZm8tPnBpZDsKIAogICBjbGVhcl9mc2MoKTsKLSAgbHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYg KHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkgeworICAKKyAg aWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKSB7CiAg ICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMg LS1cbiIpOwogICAgIHJldHVybjsKICAgfQpAQCAtMTg2LDkgKzE3NiwxNCBAQAogCSAqIG9uIHRo ZSBzdGFjaywgYXMgaXMgbm9ybWFsIGZvciBvdGhlciBwcm9jZXNzb3JzLgogCSAqIFRoZSBmYWxs LXRocm91Z2ggZm9yIGFsbCBvZiB0aGVzZSBpcyBkZWxpYmVyYXRlISEhCiAJICovCi0JbHNlZWso UHJvY2ZkLCByZWdzLnJfb3V0WzZdICsgU1BPRkYgKwotCSAgICBvZmZzZXRvZihzdHJ1Y3QgZnJh bWUsIGZyX3BhZFs2XSksIFNFRUtfU0VUKTsKLQlyZWFkKGZkLCAmZnNjLmFyZ3NbNl0sIChuYXJn cyAtIDYpICogc2l6ZW9mKGZzYy5hcmdzWzBdKSk7CisJaW9yZXF1ZXN0LnBpb2Rfb3AgPSBQSU9E X1JFQURfRDsKKwlpb3JlcXVlc3QucGlvZF9vZmZzID0gKHZvaWQgKikocmVncy5yX291dFs2XSAr IFNQT0ZGICsKKyAgICAgICAgICAgIG9mZnNldG9mKHN0cnVjdCBmcmFtZSwgZnJfcGFkWzZdKTsK Kwlpb3JlcXVlc3QucGlvZF9hZGRyID0gJmZzYy5hcmdzWzZdOworCWlvcmVxdWVzdC5waW9kX2xl biA9IChuYXJncyAtIDYpICogc2l6ZW9mKGZzYy5hcmdzWzBdKTsKKwlwdHJhY2UoUFRfSU8sIGNw aWQsIChjYWRkcl90KSZpb3JlcXVlc3QsIDApOworCWlmIChpb3JlcXVlc3QucGlvZF9sZW4gPT0g MCkgcmV0dXJuOworCiAgIGNhc2UgNjoJZnNjLmFyZ3NbNV0gPSByZWdzLnJfb3V0WzVdOwogICBj YXNlIDU6CWZzYy5hcmdzWzRdID0gcmVncy5yX291dFs0XTsKICAgY2FzZSA0Oglmc2MuYXJnc1sz XSA9IHJlZ3Mucl9vdXRbM107CkBAIC0yNDAsNyArMjM1LDcgQEAKIAkgICAgICBpIDwgKGZzYy5u YXJncyAtIDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAgICAgICBpZiAoc2MgJiYgIShzYy0+YXJn c1tpXS50eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9hcmcoUHJvY2ZkLCAm c2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOworCWZzYy5zX2FyZ3NbaV0gPSBw cmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZvKTsKICAgICAgIH0K ICAgICB9CiAjaWYgREVCVUcKQEAgLTMwMiwxOCArMjk3LDkgQEAKICAgaW50IGVycm9ycDsKICAg c3RydWN0IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAh PSBjcGlkKSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5w aWQpOwotICAgIGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsK LSAgICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNU RVJTIC0tXG4iKTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3Np bmZvLT5waWQ7Ci0gIH0KKyAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwogCi0gIGxzZWVrKGZkLCAw TCwgMCk7Ci0gIGlmIChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVn cykpIHsKKyAgaWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkg PCAwKSB7CiAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICJcbiIpOwogICAgIHJldHVy biAoLTEpOwogICB9CkBAIC0zNDQsNyArMzMwLDcgQEAKIAlpZiAoZXJyb3JwKQogCSAgYXNwcmlu dGYoJnRlbXAsICIweCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9mZnNldF0pOwogCWVsc2UK LQkgIHRlbXAgPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCByZXR2 YWwsIHRydXNzaW5mbyk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwgZnNjLmFy Z3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0gdGVtcDsKICAgICAgIH0K ICAgICB9Cj09PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVzcy9zeXNj YWxsLmgjMTIgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5iaW4v dHJ1c3Mvc3lzY2FsbC5oIzIgKHRleHQra28pID09PT0gY29udGVudApAQCAtNjEsNyArNjEsNyBA QAogCiBzdHJ1Y3Qgc3lzY2FsbCAqZ2V0X3N5c2NhbGwoY29uc3QgY2hhciopOwogY2hhciAqZ2V0 X3N0cmluZyhpbnQsIHZvaWQqLCBpbnQpOwotY2hhciAqcHJpbnRfYXJnKGludCwgc3RydWN0IHN5 c2NhbGxfYXJncyAqLCB1bnNpZ25lZCBsb25nKiwgbG9uZywgc3RydWN0IHRydXNzaW5mbyAqKTsK K2NoYXIgKnByaW50X2FyZyhzdHJ1Y3Qgc3lzY2FsbF9hcmdzICosIHVuc2lnbmVkIGxvbmcqLCBs b25nLCBzdHJ1Y3QgdHJ1c3NpbmZvICopOwogdm9pZCBwcmludF9zeXNjYWxsKHN0cnVjdCB0cnVz c2luZm8gKiwgY29uc3QgY2hhciAqLCBpbnQsIGNoYXIgKiopOwogdm9pZCBwcmludF9zeXNjYWxs X3JldChzdHJ1Y3QgdHJ1c3NpbmZvICosIGNvbnN0IGNoYXIgKiwgaW50LCBjaGFyICoqLCBpbnQs CiAgICAgbG9uZyk7Cj09PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVz cy9zeXNjYWxscy5jIzM4ICh0ZXh0K2tvKSAtIC8vZGVwb3QvdXNlci9ob3dhcmRzdS90cnVzcy91 c3IuYmluL3RydXNzL3N5c2NhbGxzLmMjMiAodGV4dCtrbykgPT09PSBjb250ZW50CkBAIC00MSw2 ICs0MSw3IEBACiAKICNpbmNsdWRlIDxzeXMvbW1hbi5oPgogI2luY2x1ZGUgPHN5cy90eXBlcy5o PgorI2luY2x1ZGUgPHN5cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CiAjaW5j bHVkZSA8c3lzL3RpbWUuaD4KICNpbmNsdWRlIDxzeXMvdW4uaD4KQEAgLTQwOCw5ICs0MDksMTMg QEAKICAqLwogCiBzdGF0aWMgaW50Ci1nZXRfc3RydWN0KGludCBwcm9jZmQsIHZvaWQgKm9mZnNl dCwgdm9pZCAqYnVmLCBpbnQgbGVuKSB7Ci0KLQlpZiAocHJlYWQocHJvY2ZkLCBidWYsIGxlbiwg KHVpbnRwdHJfdClvZmZzZXQpICE9IGxlbikKK2dldF9zdHJ1Y3QoaW50IHBpZCwgdm9pZCAqb2Zm c2V0LCB2b2lkICpidWYsIGludCBsZW4pIHsKKwlzdHJ1Y3QgcHRyYWNlX2lvX2Rlc2MgaW9yZXF1 ZXN0OworCWlvcmVxdWVzdC5waW9kX29wID0gUElPRF9SRUFEX0Q7CisJaW9yZXF1ZXN0LnBpb2Rf b2ZmcyA9IG9mZnNldDsKKwlpb3JlcXVlc3QucGlvZF9hZGRyID0gYnVmOworCWlvcmVxdWVzdC5w aW9kX2xlbiA9IGxlbjsKKwlpZiAocHRyYWNlKFBUX0lPLCBwaWQsIChjYWRkcl90KSZpb3JlcXVl c3QsIDApICE9IGxlbikKIAkJcmV0dXJuIC0xOwogCXJldHVybiAwOwogfQpAQCAtNDIzLDM3ICs0 MjgsMjEgQEAKICAqLwogCiBjaGFyICoKLWdldF9zdHJpbmcoaW50IHByb2NmZCwgdm9pZCAqb2Zm c2V0LCBpbnQgbWF4KSB7CitnZXRfc3RyaW5nKGludCBwaWQsIHZvaWQgKm9mZnNldCwgaW50IG1h eCkgewogCWNoYXIgKmJ1ZjsKLQlpbnQgc2l6ZSwgbGVuLCBjLCBmZDsKLQlGSUxFICpwOworCXN0 cnVjdCBwdHJhY2VfaW9fZGVzYyBpb3JlcXVlc3Q7CisJaWYgKG1heCA+IDEwMjQgfHwgbWF4IDw9 IDApCisJCW1heCA9IDEwMjQ7CisKKwlidWYgPSBtYWxsb2MobWF4KTsKKwlpZiAoYnVmID09IE5V TEwpIHJldHVybiBOVUxMOworCWlvcmVxdWVzdC5waW9kX29wID0gUElPRF9SRUFEX0Q7CisJaW9y ZXF1ZXN0LnBpb2Rfb2ZmcyA9IG9mZnNldDsKKwlpb3JlcXVlc3QucGlvZF9hZGRyID0gYnVmOwor CWlvcmVxdWVzdC5waW9kX2xlbiA9IG1heDsKKwlwdHJhY2UoUFRfSU8sIHBpZCwgKGNhZGRyX3Qp JmlvcmVxdWVzdCwgMCk7CisJYnVmW21heCAtIDFdID0gJ1wwJzsKIAotCWlmICgoZmQgPSBkdXAo cHJvY2ZkKSkgPT0gLTEpCi0JCWVycigxLCAiZHVwIik7Ci0JaWYgKChwID0gZmRvcGVuKGZkLCAi ciIpKSA9PSBOVUxMKQotCQllcnIoMSwgImZkb3BlbiIpOwotCWJ1ZiA9IG1hbGxvYyggc2l6ZSA9 IChtYXggPyBtYXggKyAxIDogNjQgKSApOwotCWxlbiA9IDA7Ci0JYnVmWzBdID0gMDsKLQlpZiAo ZnNlZWtvKHAsICh1aW50cHRyX3Qpb2Zmc2V0LCBTRUVLX1NFVCkgPT0gMCkgewotCQl3aGlsZSAo KGMgPSBmZ2V0YyhwKSkgIT0gRU9GKSB7Ci0JCQlidWZbbGVuKytdID0gYzsKLQkJCWlmIChjID09 IDAgfHwgbGVuID09IG1heCkKLQkJCQlicmVhazsKLQkJCWlmIChsZW4gPT0gc2l6ZSkgewotCQkJ CWNoYXIgKnRtcDsKLQkJCQl0bXAgPSByZWFsbG9jKGJ1Ziwgc2l6ZSs2NCk7Ci0JCQkJaWYgKHRt cCA9PSBOVUxMKSB7Ci0JCQkJCWJ1ZltsZW5dID0gMDsKLQkJCQkJYnJlYWs7Ci0JCQkJfQotCQkJ CXNpemUgKz0gNjQ7Ci0JCQkJYnVmID0gdG1wOwotCQkJfQotCQl9Ci0JCWJ1ZltsZW5dID0gMDsK LQl9Ci0JZmNsb3NlKHApOwogCXJldHVybiAoYnVmKTsKIH0KIApAQCAtNDY5LDkgKzQ1OCw5IEBA CiAgKi8KIAogY2hhciAqCi1wcmludF9hcmcoaW50IGZkLCBzdHJ1Y3Qgc3lzY2FsbF9hcmdzICpz YywgdW5zaWduZWQgbG9uZyAqYXJncywgbG9uZyByZXR2YWwsIHN0cnVjdCB0cnVzc2luZm8gKnRy dXNzaW5mbykgeworcHJpbnRfYXJnKHN0cnVjdCBzeXNjYWxsX2FyZ3MgKnNjLCB1bnNpZ25lZCBs b25nICphcmdzLCBsb25nIHJldHZhbCwgc3RydWN0IHRydXNzaW5mbyAqdHJ1c3NpbmZvKSB7CiAg IGNoYXIgKnRtcCA9IE5VTEw7Ci0KKyAgaW50IHBpZCA9IHRydXNzaW5mby0+cGlkOwogICBzd2l0 Y2ggKHNjLT50eXBlICYgQVJHX01BU0spIHsKICAgY2FzZSBIZXg6CiAgICAgYXNwcmludGYoJnRt cCwgIjB4JWx4IiwgYXJnc1tzYy0+b2Zmc2V0XSk7CkBAIC00ODYsNyArNDc1LDcgQEAKICAgICB7 CiAgICAgICAvKiBOVUxMLXRlcm1pbmF0ZWQgc3RyaW5nLiAqLwogICAgICAgY2hhciAqdG1wMjsK LSAgICAgIHRtcDIgPSBnZXRfc3RyaW5nKGZkLCAodm9pZCopYXJnc1tzYy0+b2Zmc2V0XSwgMCk7 CisgICAgICB0bXAyID0gZ2V0X3N0cmluZyhwaWQsICh2b2lkKilhcmdzW3NjLT5vZmZzZXRdLCAw KTsKICAgICAgIGFzcHJpbnRmKCZ0bXAsICJcIiVzXCIiLCB0bXAyKTsKICAgICAgIGZyZWUodG1w Mik7CiAgICAgfQpAQCAtNTE0LDcgKzUwMyw3IEBACiAgICAgICAgIGxlbiA9IG1heF9zdHJpbmc7 CiAgICAgICAgIHRydW5jYXRlZCA9IDE7CiAgICAgICB9Ci0gICAgICBpZiAobGVuICYmIGdldF9z dHJ1Y3QoZmQsICh2b2lkKilhcmdzW3NjLT5vZmZzZXRdLCAmdG1wMiwgbGVuKSAhPSAtMSkgewor ICAgICAgaWYgKGxlbiAmJiBnZXRfc3RydWN0KHBpZCwgKHZvaWQqKWFyZ3Nbc2MtPm9mZnNldF0s ICZ0bXAyLCBsZW4pICE9IC0xKSB7CiAgICAgICAgIHRtcDMgPSBtYWxsb2MobGVuICogNCArIDEp OwogICAgICAgICB3aGlsZSAobGVuKSB7CiAgICAgICAgICAgaWYgKHN0cnZpc3godG1wMywgdG1w MiwgbGVuLCBWSVNfQ1NUWUxFfFZJU19UQUJ8VklTX05MKSA8PSBtYXhfc3RyaW5nKQpAQCAtNTM1 LDcgKzUyNCw3IEBACiAgICAgICBjaGFyICpzdHJpbmc7CiAgICAgICBjaGFyICpzdHJhcnJheVsx MDBdOwkvKiBYWFggVGhpcyBpcyB1Z2x5LiAqLwogCi0gICAgICBpZiAoZ2V0X3N0cnVjdChmZCwg KHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzdHJhcnJheSwKKyAgICAgIGlmIChn ZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzdHJhcnJh eSwKICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihzdHJhcnJheSkpID09IC0xKSB7CiAJZXJy KDEsICJnZXRfc3RydWN0ICVwIiwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdKTsKICAgICAgIH0K QEAgLTU0NCw3ICs1MzMsNyBAQAogCiAgICAgICAvKiBGaW5kIG91dCBob3cgbGFyZ2Ugb2YgYSBi dWZmZXIgd2UnbGwgbmVlZC4gKi8KICAgICAgIHdoaWxlIChzdHJhcnJheVtudW1dICE9IE5VTEwp IHsKLQlzdHJpbmcgPSBnZXRfc3RyaW5nKGZkLCAodm9pZCopc3RyYXJyYXlbbnVtXSwgMCk7CisJ c3RyaW5nID0gZ2V0X3N0cmluZyhwaWQsICh2b2lkKilzdHJhcnJheVtudW1dLCAwKTsKICAgICAg ICAgc2l6ZSArPSBzdHJsZW4oc3RyaW5nKTsKIAlmcmVlKHN0cmluZyk7CiAJbnVtKys7CkBAIC01 NTUsNyArNTQ0LDcgQEAKIAogICAgICAgdG1wMiArPSBzcHJpbnRmKHRtcDIsICIgWyIpOwogICAg ICAgZm9yIChpID0gMDsgaSA8IG51bTsgaSsrKSB7Ci0Jc3RyaW5nID0gZ2V0X3N0cmluZyhmZCwg KHZvaWQqKXN0cmFycmF5W2ldLCAwKTsKKwlzdHJpbmcgPSBnZXRfc3RyaW5nKHBpZCwgKHZvaWQq KXN0cmFycmF5W2ldLCAwKTsKICAgICAgICAgdG1wMiArPSBzcHJpbnRmKHRtcDIsICIgXCIlc1wi JWMiLCBzdHJpbmcsIChpKzEgPT0gbnVtKSA/ICcgJyA6ICcsJyk7CiAJZnJlZShzdHJpbmcpOwog ICAgICAgfQpAQCAtNTg1LDcgKzU3NCw3IEBACiAJdG1wID0gc3RyZHVwKCIiKTsKIAlicmVhazsK ICAgICAgIH0KLSAgICAgIHRtcDIgPSBnZXRfc3RyaW5nKGZkLCAodm9pZCopYXJnc1tzYy0+b2Zm c2V0XSwgcmV0dmFsKTsKKyAgICAgIHRtcDIgPSBnZXRfc3RyaW5nKHBpZCwgKHZvaWQqKWFyZ3Nb c2MtPm9mZnNldF0sIHJldHZhbCk7CiAgICAgICBhc3ByaW50ZigmdG1wLCAiXCIlc1wiIiwgdG1w Mik7CiAgICAgICBmcmVlKHRtcDIpOwogICAgIH0KQEAgLTYwOCw3ICs1OTcsNyBAQAogICBjYXNl IFVtdHg6CiAgICAgewogICAgICAgc3RydWN0IHVtdHggdW10eDsKLSAgICAgIGlmIChnZXRfc3Ry dWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZ1bXR4LCBzaXplb2YodW10eCkpICE9 IC0xKQorICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0s ICZ1bXR4LCBzaXplb2YodW10eCkpICE9IC0xKQogCWFzcHJpbnRmKCZ0bXAsICJ7MHglbHh9Iiwg KGxvbmcpdW10eC51X293bmVyKTsKICAgICAgIGVsc2UKIAlhc3ByaW50ZigmdG1wLCAiMHglbHgi LCBhcmdzW3NjLT5vZmZzZXRdKTsKQEAgLTYxNyw3ICs2MDYsNyBAQAogICBjYXNlIFRpbWVzcGVj OgogICAgIHsKICAgICAgIHN0cnVjdCB0aW1lc3BlYyB0czsKLSAgICAgIGlmIChnZXRfc3RydWN0 KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZ0cywgc2l6ZW9mKHRzKSkgIT0gLTEpCisg ICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnRzLCBz aXplb2YodHMpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAieyVsZC4lMDlsZH0iLCAobG9uZyl0 cy50dl9zZWMsIHRzLnR2X25zZWMpOwogICAgICAgZWxzZQogCWFzcHJpbnRmKCZ0bXAsICIweCVs eCIsIGFyZ3Nbc2MtPm9mZnNldF0pOwpAQCAtNjI2LDcgKzYxNSw3IEBACiAgIGNhc2UgVGltZXZh bDoKICAgICB7CiAgICAgICBzdHJ1Y3QgdGltZXZhbCB0djsKLSAgICAgIGlmIChnZXRfc3RydWN0 KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZ0diwgc2l6ZW9mKHR2KSkgIT0gLTEpCisg ICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnR2LCBz aXplb2YodHYpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAieyVsZC4lMDZsZH0iLCAobG9uZyl0 di50dl9zZWMsIHR2LnR2X3VzZWMpOwogICAgICAgZWxzZQogCWFzcHJpbnRmKCZ0bXAsICIweCVs eCIsIGFyZ3Nbc2MtPm9mZnNldF0pOwpAQCAtNjM1LDcgKzYyNCw3IEBACiAgIGNhc2UgVGltZXZh bDI6CiAgICAgewogICAgICAgc3RydWN0IHRpbWV2YWwgdHZbMl07Ci0gICAgICBpZiAoZ2V0X3N0 cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAmdHYsIHNpemVvZih0dikpICE9IC0x KQorICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZ0 diwgc2l6ZW9mKHR2KSkgIT0gLTEpCiAJYXNwcmludGYoJnRtcCwgInslbGQuJTA2bGQsICVsZC4l MDZsZH0iLAogCSAgKGxvbmcpdHZbMF0udHZfc2VjLCB0dlswXS50dl91c2VjLAogCSAgKGxvbmcp dHZbMV0udHZfc2VjLCB0dlsxXS50dl91c2VjKTsKQEAgLTY0Niw3ICs2MzUsNyBAQAogICBjYXNl IEl0aW1lcnZhbDoKICAgICB7CiAgICAgICBzdHJ1Y3QgaXRpbWVydmFsIGl0djsKLSAgICAgIGlm IChnZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZpdHYsIHNpemVvZihp dHYpKSAhPSAtMSkKKyAgICAgIGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5v ZmZzZXRdLCAmaXR2LCBzaXplb2YoaXR2KSkgIT0gLTEpCiAJYXNwcmludGYoJnRtcCwgInslbGQu JTA2bGQsICVsZC4lMDZsZH0iLAogCSAgICAobG9uZylpdHYuaXRfaW50ZXJ2YWwudHZfc2VjLAog CSAgICBpdHYuaXRfaW50ZXJ2YWwudHZfdXNlYywKQEAgLTY3MCw3ICs2NTksNyBAQAogCiAgICAg ICBpZiAoKHBmZCA9IG1hbGxvYyhieXRlcykpID09IE5VTEwpCiAJZXJyKDEsICJDYW5ub3QgbWFs bG9jICVkIGJ5dGVzIGZvciBwb2xsZmQgYXJyYXkiLCBieXRlcyk7Ci0gICAgICBpZiAoZ2V0X3N0 cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCBwZmQsIGJ5dGVzKSAhPSAtMSkgewor ICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sIHBmZCwg Ynl0ZXMpICE9IC0xKSB7CiAKIAl1c2VkID0gMDsKIAl0bXBzaXplID0gMSArIHBlcl9mZCAqIG51 bWZkcyArIDI7CkBAIC03MDksNyArNjk4LDcgQEAKIAogICAgICAgaWYgKChmZHMgPSBtYWxsb2Mo Ynl0ZXMpKSA9PSBOVUxMKQogCWVycigxLCAiQ2Fubm90IG1hbGxvYyAlZCBieXRlcyBmb3IgZmRf c2V0IGFycmF5IiwgYnl0ZXMpOwotICAgICAgaWYgKGdldF9zdHJ1Y3QoZmQsICh2b2lkICopYXJn c1tzYy0+b2Zmc2V0XSwgZmRzLCBieXRlcykgIT0gLTEpIHsKKyAgICAgIGlmIChnZXRfc3RydWN0 KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCBmZHMsIGJ5dGVzKSAhPSAtMSkgewogCXVz ZWQgPSAwOwogCXRtcHNpemUgPSAxICsgbnVtZmRzICogcGVyX2ZkICsgMjsKIAlpZiAoKHRtcCA9 IG1hbGxvYyh0bXBzaXplKSkgPT0gTlVMTCkKQEAgLTc0OSw3ICs3MzgsNyBAQAogICAgICAgaW50 IGksIHVzZWQ7CiAKICAgICAgIHNpZyA9IGFyZ3Nbc2MtPm9mZnNldF07Ci0gICAgICBpZiAoZ2V0 X3N0cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzcywKKyAgICAg IGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZz cywKICAgICAgICAgICBzaXplb2Yoc3MpKSA9PSAtMSkKICAgICAgIHsKIAlhc3ByaW50ZigmdG1w LCAiMHglbHgiLCBhcmdzW3NjLT5vZmZzZXRdKTsKQEAgLTg1Myw3ICs4NDIsNyBAQAogICAgICAg fQogCiAgICAgICAvKiB5dWNrOiBnZXQgc3NfbGVuICovCi0gICAgICBpZiAoZ2V0X3N0cnVjdChm ZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzcywKKyAgICAgIGlmIChnZXRf c3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzcywKIAlzaXpl b2Yoc3Muc3NfbGVuKSArIHNpemVvZihzcy5zc19mYW1pbHkpKSA9PSAtMSkKIAllcnIoMSwgImdl dF9zdHJ1Y3QgJXAiLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0pOwogICAgICAgLyoKQEAgLTg3 NCw3ICs4NjMsNyBAQAogCQkgICAgICBicmVhazsKIAkgICAgICB9CiAgICAgICB9Ci0gICAgICBp ZiAoZ2V0X3N0cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAodm9pZCAqKSZzcywg c3Muc3NfbGVuKQorICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9m ZnNldF0sICh2b2lkICopJnNzLCBzcy5zc19sZW4pCiAJICA9PSAtMSkgewogCSAgZXJyKDIsICJn ZXRfc3RydWN0ICVwIiwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdKTsKICAgICAgIH0KQEAgLTkx Myw3ICs5MDIsNyBAQAogICAgICAgY2hhciAqaGFuZDsKICAgICAgIGNvbnN0IGNoYXIgKmg7CiAK LSAgICAgIGlmIChnZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZzYSwg c2l6ZW9mKHNhKSkgIT0gLTEpIHsKKyAgICAgIGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilh cmdzW3NjLT5vZmZzZXRdLCAmc2EsIHNpemVvZihzYSkpICE9IC0xKSB7CiAKIAlhc3ByaW50Zigm aGFuZCwgIiVwIiwgc2Euc2FfaGFuZGxlcik7CiAJaWYgKHNhLnNhX2hhbmRsZXIgPT0gU0lHX0RG TCkKQEAgLTk1Niw3ICs5NDUsNyBAQAogICAgICAgCWJ5dGVzID0gc2l6ZW9mKHN0cnVjdCBrZXZl bnQpICogbnVtZXZlbnRzOwogICAgICAgaWYgKChrZSA9IG1hbGxvYyhieXRlcykpID09IE5VTEwp CiAgICAgICAgIGVycigxLCAiQ2Fubm90IG1hbGxvYyAlZCBieXRlcyBmb3Iga2V2ZW50IGFycmF5 IiwgYnl0ZXMpOwotICAgICAgaWYgKG51bWV2ZW50cyA+PSAwICYmIGdldF9zdHJ1Y3QoZmQsICh2 b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwga2UsIGJ5dGVzKSAhPSAtMSkgeworICAgICAgaWYgKG51 bWV2ZW50cyA+PSAwICYmIGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0s IGtlLCBieXRlcykgIT0gLTEpIHsKIAl1c2VkID0gMDsKIAl0bXBzaXplID0gMSArIHBlcl9rZSAq IG51bWV2ZW50cyArIDI7CiAJaWYgKCh0bXAgPSBtYWxsb2ModG1wc2l6ZSkpID09IE5VTEwpCkBA IC05ODYsNyArOTc1LDcgQEAKICAgY2FzZSBTdGF0OgogICAgIHsKICAgICAgIHN0cnVjdCBzdGF0 IHN0OwotICAgICAgaWYgKGdldF9zdHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwg JnN0LCBzaXplb2Yoc3QpKSAhPSAtMSkgeworICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9p ZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZzdCwgc2l6ZW9mKHN0KSkgIT0gLTEpIHsKIAljaGFyIG1v ZGVbMTJdOwogCXN0cm1vZGUoc3Quc3RfbW9kZSwgbW9kZSk7CiAJYXNwcmludGYoJnRtcCwgIntt b2RlPSVzLGlub2RlPSVqZCxzaXplPSVqZCxibGtzaXplPSVsZH0iLApAQCAtOTk5LDcgKzk4OCw3 IEBACiAgIGNhc2UgUnVzYWdlOgogICAgIHsKICAgICAgIHN0cnVjdCBydXNhZ2UgcnU7Ci0gICAg ICBpZiAoZ2V0X3N0cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAmcnUsIHNpemVv ZihydSkpICE9IC0xKQorICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2Mt Pm9mZnNldF0sICZydSwgc2l6ZW9mKHJ1KSkgIT0gLTEpCiAJYXNwcmludGYoJnRtcCwgInt1PSVs ZC4lMDZsZCxzPSVsZC4lMDZsZCxpbj0lbGQsb3V0PSVsZH0iLAogCSAgKGxvbmcpcnUucnVfdXRp bWUudHZfc2VjLCBydS5ydV91dGltZS50dl91c2VjLAogCSAgKGxvbmcpcnUucnVfc3RpbWUudHZf c2VjLCBydS5ydV9zdGltZS50dl91c2VjLApAQCAtMTAxMSw3ICsxMDAwLDcgQEAKICAgY2FzZSBS bGltaXQ6CiAgICAgewogICAgICAgc3RydWN0IHJsaW1pdCBybDsKLSAgICAgIGlmIChnZXRfc3Ry dWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZybCwgc2l6ZW9mKHJsKSkgIT0gLTEp CisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnJs LCBzaXplb2YocmwpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAie2N1cj0lanUsbWF4PSVqdX0i LAogCSAgcmwucmxpbV9jdXIsIHJsLnJsaW1fbWF4KTsKICAgICAgIGVsc2UKPT09PSAvL2RlcG90 L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL3RydXNzLjEjMTIgKHRleHQra28pIC0g Ly9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5iaW4vdHJ1c3MvdHJ1c3MuMSMzICh0ZXh0 K2tvKSA9PT09IGNvbnRlbnQKQEAgLTIzLDcgKzIzLDcgQEAKIHV0aWxpdHkgdHJhY2VzIHRoZSBz eXN0ZW0gY2FsbHMgY2FsbGVkIGJ5IHRoZSBzcGVjaWZpZWQgcHJvY2VzcyBvciBwcm9ncmFtLgog T3V0cHV0IGlzIHRvIHRoZSBzcGVjaWZpZWQgb3V0cHV0IGZpbGUsIG9yIHN0YW5kYXJkIGVycm9y IGJ5IGRlZmF1bHQuCiBJdCBkb2VzIHRoaXMgYnkgc3RvcHBpbmcgYW5kIHJlc3RhcnRpbmcgdGhl IHByb2Nlc3MgYmVpbmcgbW9uaXRvcmVkIHZpYQotLlhyIHByb2NmcyA1IC4KKy5YciBwdHJhY2Ug MiAuCiAuUHAKIFRoZSBvcHRpb25zIGFyZSBhcyBmb2xsb3dzOgogLkJsIC10YWcgLXdpZHRoIGlu ZGVudApAQCAtNzksMTMgKzc5LDYgQEAKIC5BciBjb21tYW5kCiBvcHRpb25zIGFyZSBtdXR1YWxs eSBleGNsdXNpdmUuKQogLkVsCi0uUHAKLVRoZQotLlhyIHByb2NjdGwgOAotdXRpbGl0eSBjYW4g YmUgdXNlZCB0byBjbGVhciB0cmFjZXBvaW50cyBpbiBhIHN0dWNrIHByb2Nlc3MKLWxlZnQgYmVo aW5kIGlmCi0uTm0KLXRlcm1pbmF0ZXMgYWJub3JtYWxseS4KIC5TaCBFWEFNUExFUwogIyBGb2xs b3cgdGhlIHN5c3RlbSBjYWxscyB1c2VkIGluIGVjaG9pbmcgImhlbGxvIgogLkRsICQgdHJ1c3Mg L2Jpbi9lY2hvIGhlbGxvCkBAIC05Niw4ICs4OSw3IEBACiAuU2ggU0VFIEFMU08KIC5YciBrZHVt cCAxICwKIC5YciBrdHJhY2UgMSAsCi0uWHIgcHJvY2ZzIDUgLAotLlhyIHByb2NjdGwgOAorLlhy IHB0cmFjZSAyIDIgCiAuU2ggSElTVE9SWQogVGhlCiAuTm0KPT09PSAvL2RlcG90L3ZlbmRvci9m cmVlYnNkL3NyYy91c3IuYmluL3RydXNzL3RydXNzLmgjNSAodGV4dCtrbykgLSAvL2RlcG90L3Vz ZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy90cnVzcy5oIzMgKHRleHQra28pID09PT0g Y29udGVudApAQCAtMzcsNiArMzcsOCBAQAogCWludCBwaWQ7CiAJaW50IGZsYWdzOwogCWludCBp bl9mb3JrOworCWludCBwcl93aHk7CisJaW50IHByX2RhdGE7CiAJaW50IHN0cnNpemU7CiAJRklM RSAqb3V0ZmlsZTsKIApAQCAtNTQsMyArNTYsMTAgQEAKIAkJCSh2dnApLT50dl9uc2VjICs9IDEw MDAwMDAwMDA7CQkJXAogCQl9CQkJCQkJCVwKIAl9IHdoaWxlICgwKQorCisjZGVmaW5lIFNfTk9O RSAgMAorI2RlZmluZSBTX1NDRSAgIDEKKyNkZWZpbmUgU19TQ1ggICAyCisjZGVmaW5lIFNfRVhJ VCAgMworI2RlZmluZSBTX1NJRyAgIDQKKyNkZWZpbmUgU19FWEVDICA1Cg== ------=_Part_27400_23796817.1175674700136-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 11:28:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEDE916A408; Wed, 4 Apr 2007 11:28:06 +0000 (UTC) (envelope-from le@freebsd.org) Received: from grace.univie.ac.at (grace.univie.ac.at [131.130.3.115]) by mx1.freebsd.org (Postfix) with ESMTP id 7C34A13C45D; Wed, 4 Apr 2007 11:28:06 +0000 (UTC) (envelope-from le@freebsd.org) Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.66) (envelope-from ) id 1HZ3en-0007SA-O1; Wed, 04 Apr 2007 13:28:05 +0200 Received: from [2001:62a:4:202:214:c2ff:fe04:3088] by justin.univie.ac.at with esmtps (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HZ3en-0000ws-Ma; Wed, 04 Apr 2007 13:28:05 +0200 Message-ID: <46138BC4.2090209@freebsd.org> Date: Wed, 04 Apr 2007 13:28:04 +0200 From: Lukas Ertl User-Agent: Thunderbird 1.5.0.10 (X11/20070402) MIME-Version: 1.0 To: Andrey Chernov , Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org, des@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> <20070404105235.GA38359@nagual.pp.ru> <20070404111309.GA38798@nagual.pp.ru> In-Reply-To: <20070404111309.GA38798@nagual.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 11:28:06 -0000 Andrey Chernov wrote: > On Wed, Apr 04, 2007 at 02:52:35PM +0400, Andrey Chernov wrote: >> On Wed, Apr 04, 2007 at 09:48:17AM +0200, Lukas Ertl wrote: >>> I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. >>> Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? >> Yes, I observe the same problem too. It appearse like problem with >> ${early_late_divider} set with new des@ changes - all scripts are just >> skipped because of it. Backing out rc only not helps. > > Should be fixed in rc.conf v1.310, please try Thank you, works fine now. cheers, le -- Lukas Ertl http://mailbox.univie.ac.at/~le/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 11:30:29 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 604CC16A401 for ; Wed, 4 Apr 2007 11:30:29 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 7186313C45B for ; Wed, 4 Apr 2007 11:30:28 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so656463ugh for ; Wed, 04 Apr 2007 04:30:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GPylShWA/SeBDVyXzku6/pHASlLZXtQUtbB6SIcURrL1KA55stZpCTGgRU42T0zVfI3BmxJTp9FXTZj4/oXKuC88oFemHAHGQT98YTd9F6Lt8uBI+1xS65HmdgGdIQ7faSNJXTB1QMwtPq2VIJK9oFW8mO9XMx3ybFeKYFZJcsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BA8lA89IS+HZ9Lx51E+CNO/APl1tkHF6/u2UOryA7z13HIp7tXC+SeWBsMktpNpyItdTTTmfSUNMRT54wAgZ8PXSA6qgxy/t1t7E3J/5+SzTiAXO49E2NKOL78VPG0ySPP7iHgJV1XOGcdsqKP94MPCDHySXAsadfMc6MuCKTbU= Received: by 10.115.88.1 with SMTP id q1mr180161wal.1175686226697; Wed, 04 Apr 2007 04:30:26 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Wed, 4 Apr 2007 04:30:26 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 19:30:26 +0800 From: "Howard Su" To: "Alfred Perlstein" In-Reply-To: <20070404101222.GU61362@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070404101222.GU61362@elvis.mu.org> X-Mailman-Approved-At: Wed, 04 Apr 2007 11:48:58 +0000 Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 11:30:29 -0000 On 4/4/07, Alfred Perlstein wrote: > * Howard Su [070404 01:20] wrote: > > Following the suggestion in idea page, I proposed the attached patch. > > I didn't change any kernel part because I think PTRACE(2) is > > functional although man page didn't document it. > > > > I tested the patch under i386 and amd64 box. The help on testing and > > code review will be appreciated. > > wow, well done! any draw backs to using ptrace over procfs? I didn't see. > > have you tested performance? Not yet. Base on the number of kernel syscall, new implementaion keep in a same level. However ptrace calls has a short code path compare to generic read syscall. I suppose there will be some improvement. Anyway, I will try to get perf data. > > -Alfred > > -- -Howard From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 12:16:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90E5216A402 for ; Wed, 4 Apr 2007 12:16:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 59FFB13C448 for ; Wed, 4 Apr 2007 12:16:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 8F5A01CC5C; Wed, 4 Apr 2007 14:16:02 +0200 (CEST) Date: Wed, 4 Apr 2007 14:16:02 +0200 From: Ed Schouten To: Howard Su Message-ID: <20070404121602.GI14608@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ISKrrfpKsPiF35CV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 12:16:04 -0000 --ISKrrfpKsPiF35CV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Howard Su wrote: > Following the suggestion in idea page, I proposed the attached patch. > I didn't change any kernel part because I think PTRACE(2) is > functional although man page didn't document it. Indeed. Looking at sys/ptrace.h, there are a lot of instructions that aren't documented in the manpage: - PT_GETNUMLWPS - PT_GETLWPLIST - PT_CLEARSTEP - PT_SETSTEP - PT_SUSPEND - PT_RESUME - PT_TO_SCE - PT_TO_SCX - PT_SYSCALL - PT_FIRSTMACH --=20 Ed Schouten WWW: http://g-rave.nl/ --ISKrrfpKsPiF35CV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGE5cC52SDGA2eCwURAuklAJ9SylOdocEjchP4r3dxggjgMAEbxQCeP49u VY/81jsvE357xbv0EJZAqPM= =daN0 -----END PGP SIGNATURE----- --ISKrrfpKsPiF35CV-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 12:18:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0865A16A405 for ; Wed, 4 Apr 2007 12:18:48 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by mx1.freebsd.org (Postfix) with ESMTP id BDBE213C457 for ; Wed, 4 Apr 2007 12:18:47 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so81637nza for ; Wed, 04 Apr 2007 05:18:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rBAbPotBuDha4fFErN39EPrc3aF0a3O8pYLp4GwNoFb56soDZk9Bj5BB4Kh8K82VjCee+4hA2ThrIrgRAPtt5xSxXW/rvZEWExrHcmQKp8Fi5nrHeu3cnaMMMhPuCKhhWW5vy8/T16adX4peBshDo8Rm7KcedMIMhIbnS3yE4d4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V7EHdDyVO62gFEXOWkXD/f2uNUMwDLLftOLNldFKmYlRzI0mRdPYxfTffg1k3ciYRyp3hUcYOH2pZ7O1KerawG9rG2zfliLQSyn4Z9V/emNnAdyOZCFu33gdVz15F0JO1rBYdfYcuxw3n3lp9QBGyoalqPvMe2V0INezrYDRhzA= Received: by 10.114.168.1 with SMTP id q1mr197402wae.1175689126413; Wed, 04 Apr 2007 05:18:46 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Wed, 4 Apr 2007 05:18:45 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 20:18:45 +0800 From: "Howard Su" To: "Ed Schouten" In-Reply-To: <20070404121602.GI14608@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070404121602.GI14608@hoeg.nl> X-Mailman-Approved-At: Wed, 04 Apr 2007 12:44:43 +0000 Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 12:18:48 -0000 On 4/4/07, Ed Schouten wrote: > * Howard Su wrote: > > Following the suggestion in idea page, I proposed the attached patch. > > I didn't change any kernel part because I think PTRACE(2) is > > functional although man page didn't document it. > > Indeed. Looking at sys/ptrace.h, there are a lot of instructions that > aren't documented in the manpage: > > - PT_GETNUMLWPS > - PT_GETLWPLIST > - PT_CLEARSTEP > - PT_SETSTEP > - PT_SUSPEND > - PT_RESUME > - PT_TO_SCE > - PT_TO_SCX > - PT_SYSCALL > - PT_FIRSTMACH As far as i know, PT_TO_SCE, PT_TO_SCX, PT_SYSCALL works well. I use PT_SYSCALL in my patch. -- -Howard From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 12:51:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAC9416A401 for ; Wed, 4 Apr 2007 12:51:58 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.freebsd.org (Postfix) with ESMTP id 8885B13C44C for ; Wed, 4 Apr 2007 12:51:58 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so166473wxc for ; Wed, 04 Apr 2007 05:51:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=Bkg/6eFEeXnX6VWevYZsqYe7mrrG5Teobu3TVzzG/mFzKOC+IVygeSirkkHNysPxHFQa7vAm3gOyhPDr1LUMesNuqcVhE/PqpQ+rpsR0VG+mC35GQM6lL+061EdtmSxY97tgQWo29/ksoDLGNXhw5S5p6iQzLe/y7plukBzx7cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=XKmsEXsnDogBXxz78bP0sRo1rbzkwRRzI1VFXiG3VdIWOx23Hdyif1vRW2wF1k7HInAWONvh5UjOv57hFKCAVXGpIzGUpm/Izzozo2xS+Gs+onWSxl8dlBcz124Q/ruy5HOjnxJiMP4sw/kfKCbc6pT0rBiiE4UnfCsXU3qzTRU= Received: by 10.90.103.2 with SMTP id a2mr220132agc.1175689428155; Wed, 04 Apr 2007 05:23:48 -0700 (PDT) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id 7sm549262agd.2007.04.04.05.23.47; Wed, 04 Apr 2007 05:23:47 -0700 (PDT) Date: Wed, 4 Apr 2007 08:23:46 -0400 From: Alexander Kabaev To: Andrey Chernov Message-ID: <20070404082346.64ce25cd@kan.dnsalias.net> In-Reply-To: <20070404101321.GA37396@nagual.pp.ru> References: <20070404101321.GA37396@nagual.pp.ru> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_02AumXr7yYQtx.BvCgD0=_j"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: ports@freebsd.org, current@freebsd.org Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 12:51:58 -0000 --Sig_02AumXr7yYQtx.BvCgD0=_j Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 4 Apr 2007 14:13:21 +0400 Andrey Chernov wrote: > Try to install and run www/apache13 port. With recent -current you'll > get similar error for each module first listed in config: >=20 > Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: > Cannot load /usr/local/libexec/apache/mod_env.so into server:=20 > /usr/local/libexec > /apache/mod_env.so: Undefined symbol "ap_palloc" >=20 > Perhaps it is Apache configuration problem since old-compiled apache=20 > (Dec 9) runs normally. Perhaps Apache config find some new defines > which not works as expected. >=20 > I am not expert in dlopen() at all. Please look someone who knows. >=20 You do not have to be an expert in dlopen to find out the list of loaded modules at the time dlopen called, what parameters dlopen is called with and where the symbol allegedly not found is really defined. --=20 Alexander Kabaev --Sig_02AumXr7yYQtx.BvCgD0=_j Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGE5jSQ6z1jMm+XZYRAv7wAJ42JG+hAZoslnn9HgeuNLPQFv7RBACgu8Tu 9bhYj1Tef3TqchmdvGpGYkA= =qbCp -----END PGP SIGNATURE----- --Sig_02AumXr7yYQtx.BvCgD0=_j-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 12:57:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D10CD16A407; Wed, 4 Apr 2007 12:57:37 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5648F13C487; Wed, 4 Apr 2007 12:57:37 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34CvZkb040156; Wed, 4 Apr 2007 16:57:35 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34CvZCh040153; Wed, 4 Apr 2007 16:57:35 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 16:57:35 +0400 From: Andrey Chernov To: Alexander Kabaev Message-ID: <20070404125735.GA40094@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Alexander Kabaev , current@freebsd.org, ports@freebsd.org References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20070404082346.64ce25cd@kan.dnsalias.net> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 12:57:38 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2007 at 08:23:46AM -0400, Alexander Kabaev wrote: > > Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: > > Cannot load /usr/local/libexec/apache/mod_env.so into server:=20 > > /usr/local/libexec > > /apache/mod_env.so: Undefined symbol "ap_palloc" > >=20 > > Perhaps it is Apache configuration problem since old-compiled apache=20 > > (Dec 9) runs normally. Perhaps Apache config find some new defines > > which not works as expected. > >=20 > > I am not expert in dlopen() at all. Please look someone who knows. > >=20 > You do not have to be an expert in dlopen to find out the list of > loaded modules at the time dlopen called, what parameters dlopen is > called with and where the symbol allegedly not found is really defined. 1) The symbols in question are all _defined_ inside main httpd program. 2) dlopen() just call single first apache module and fails. 3) Apache port not changed for a long time and works at the moment of last= =20 commit 2006/12/09 --=20 http://ache.pp.ru/ --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGE6C/Vg5YK5ZEdN0RAifGAJoC1ZTzQkc+6QhEcKfY3ADgy28sZACgt1gc z1F+9HzMh+JWQjbPlAiFnOE= =7Y53 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 13:09:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBF1216A404 for ; Wed, 4 Apr 2007 13:09:51 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 72E3913C44B for ; Wed, 4 Apr 2007 13:09:51 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so171563wxc for ; Wed, 04 Apr 2007 06:09:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=OtYTmx0MY3jx8X6SzH852PkeODNtiJriMukO4OI1oefLKiuffNU6NcyPUR+AXd3P9gs91nc6Xh8qezn5wY5hT5ZNYTeT3aF7FAznuMakp8dw4LS1pCuAVfl1ndzrESR/EHuy8OZX4Mv/fogFTnzACsejavHEVtZW4GRfCUgeS9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=ujh47eyDrCS4IvQ3SNXbwUqJek69LvEHb+G4Nq3KXQ+BlM6Km83ADug9jKfo78pp2mY4cF4jbb4teU/BG5zpHPMhmOWtvUI0kQAgE8VgW7WqFPLOYTB8X6KfHQvejDKYKSGDW5QP1mWBJ4kelsJG1nbb1DsQCZxxyXPxwRBnHBE= Received: by 10.90.104.14 with SMTP id b14mr293026agc.1175692190667; Wed, 04 Apr 2007 06:09:50 -0700 (PDT) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id g9sm807094wra.2007.04.04.06.09.48; Wed, 04 Apr 2007 06:09:48 -0700 (PDT) Date: Wed, 4 Apr 2007 09:09:44 -0400 From: Alexander Kabaev To: Andrey Chernov Message-ID: <20070404090944.1a13e96f@kan.dnsalias.net> In-Reply-To: <20070404125735.GA40094@nagual.pp.ru> References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> <20070404125735.GA40094@nagual.pp.ru> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_g/HgbOppW8hzXsAC2I1N.Po"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: ports@freebsd.org, current@freebsd.org Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 13:09:52 -0000 --Sig_g/HgbOppW8hzXsAC2I1N.Po Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 4 Apr 2007 16:57:35 +0400 Andrey Chernov wrote: > On Wed, Apr 04, 2007 at 08:23:46AM -0400, Alexander Kabaev wrote: > > > Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: > > > Cannot load /usr/local/libexec/apache/mod_env.so into server:=20 > > > /usr/local/libexec > > > /apache/mod_env.so: Undefined symbol "ap_palloc" > > >=20 > > > Perhaps it is Apache configuration problem since old-compiled > > > apache (Dec 9) runs normally. Perhaps Apache config find some new > > > defines which not works as expected. > > >=20 > > > I am not expert in dlopen() at all. Please look someone who knows. > > >=20 > > You do not have to be an expert in dlopen to find out the list of > > loaded modules at the time dlopen called, what parameters dlopen is > > called with and where the symbol allegedly not found is really > > defined. >=20 > 1) The symbols in question are all _defined_ inside main httpd > program.=20 objdump -T output goes here. 2) dlopen() just call single first apache module and fails. dlopen parameters dump goes here. 2a) dlerror() output goes here objdump -T of module being loaded goes here too. > 3) Apache port not changed for a long time and works at the moment of > last commit 2006/12/09 Symbol lookup and module loading has not changed in rtld for even longer time. You honestly expect someone to do initial trivial investigation for you? --=20 Alexander Kabaev --Sig_g/HgbOppW8hzXsAC2I1N.Po Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGE6OYQ6z1jMm+XZYRAsneAJ9bXk48tsC5LfbP2P5iPYpu/YTm4wCeO4Fv BloqlYgiJ8INpqP1sa3Z87E= =4p+G -----END PGP SIGNATURE----- --Sig_g/HgbOppW8hzXsAC2I1N.Po-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 13:35:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB09316A401; Wed, 4 Apr 2007 13:35:31 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2E67C13C458; Wed, 4 Apr 2007 13:35:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34DZTll040847; Wed, 4 Apr 2007 17:35:29 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34DZT9C040846; Wed, 4 Apr 2007 17:35:29 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 17:35:29 +0400 From: Andrey Chernov To: Alexander Kabaev Message-ID: <20070404133529.GA40652@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Alexander Kabaev , current@freebsd.org, ports@freebsd.org References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> <20070404125735.GA40094@nagual.pp.ru> <20070404090944.1a13e96f@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20070404090944.1a13e96f@kan.dnsalias.net> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 13:35:31 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2007 at 09:09:44AM -0400, Alexander Kabaev wrote: > > 1) The symbols in question are all _defined_ inside main httpd > > program.=20 >=20 > objdump -T output goes here. Those symbols are in 'nm' table of httpd like this 0804a84a T ap_palloc but not found in its objdump -T output.=20 Why and how it may happens? When I do objdump -T for old httpd from Dec 9 - they are there like this 0804ecce g DF .text 0000006b ap_palloc --=20 http://ache.pp.ru/ --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGE6mhVg5YK5ZEdN0RAjJQAKCUbE02AqS1/1nkecBkjaUVZ1cciwCggNhe M+tIVDqHyBbDkiGJNAtrhvs= =fLLs -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 14:04:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A84316A406; Wed, 4 Apr 2007 14:04:59 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 080CD13C483; Wed, 4 Apr 2007 14:04:58 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=NPzs2c2U2dEEp6JAKeB67qBmvikZ/NtcC4QYOvxq3cBmLh16yXX7KCJxoqMlaF1D6y2EFseiw+5qcxIsZqtwyBTOv2LfG3nDo6e59Hdv53eLKjfDKUhJYyhTQrz1BpZkagVcZwGwix/0fwGP4n4Uy/5wdmX3/MupCpUjII4RMBI=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HZ66Z-000LS9-4Z; Wed, 04 Apr 2007 18:04:55 +0400 Date: Wed, 4 Apr 2007 18:04:50 +0400 From: Eygene Ryabinkin To: Andrey Chernov , Alexander Kabaev , current@freebsd.org, ports@freebsd.org Message-ID: <20070404140450.GM26348@codelabs.ru> References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> <20070404125735.GA40094@nagual.pp.ru> <20070404090944.1a13e96f@kan.dnsalias.net> <20070404133529.GA40652@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070404133529.GA40652@nagual.pp.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 14:04:59 -0000 Andrey, good day. Wed, Apr 04, 2007 at 05:35:29PM +0400, Andrey Chernov wrote: > On Wed, Apr 04, 2007 at 09:09:44AM -0400, Alexander Kabaev wrote: > > > 1) The symbols in question are all _defined_ inside main httpd > > > program. > > > > objdump -T output goes here. > > Those symbols are in 'nm' table of httpd like this > 0804a84a T ap_palloc > but not found in its objdump -T output. > > Why and how it may happens? Try '-Wl,--export-dynamic' flag to the gcc (or just --export-dynamic to the ld), it may help you. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 14:51:10 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FD9E16A403; Wed, 4 Apr 2007 14:51:10 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1373E13C44B; Wed, 4 Apr 2007 14:51:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34Ep6BK041935; Wed, 4 Apr 2007 18:51:06 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34Ep6KW041934; Wed, 4 Apr 2007 18:51:06 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 18:51:05 +0400 From: Andrey Chernov To: Alexander Kabaev , current@freebsd.org, ports@freebsd.org Message-ID: <20070404145105.GA41879@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Alexander Kabaev , current@freebsd.org, ports@freebsd.org References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> <20070404125735.GA40094@nagual.pp.ru> <20070404090944.1a13e96f@kan.dnsalias.net> <20070404133529.GA40652@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20070404133529.GA40652@nagual.pp.ru> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 14:51:10 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2007 at 05:35:29PM +0400, Andrey Chernov wrote: > On Wed, Apr 04, 2007 at 09:09:44AM -0400, Alexander Kabaev wrote: > > > 1) The symbols in question are all _defined_ inside main httpd > > > program.=20 > >=20 > > objdump -T output goes here. >=20 > Those symbols are in 'nm' table of httpd like this > 0804a84a T ap_palloc > but not found in its objdump -T output.=20 >=20 > Why and how it may happens? Comparing generated Makefile with FreeBSD 6 it seems some ld flags=20 are now missing: < LDFLAGS_SHLIB_EXPORT=3D --- > LDFLAGS_SHLIB_EXPORT=3D-Wl,-E I'll come back with detailed results later. --=20 http://ache.pp.ru/ --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGE7tZVg5YK5ZEdN0RAkd+AJsE1p2rK4s4Q/5Cnt65ekc17KTU9gCfXYAq lbq37B7SzE0Tqk+NUvKiimI= =CZo4 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 14:55:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6180316A401; Wed, 4 Apr 2007 14:55:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id D0BF113C44C; Wed, 4 Apr 2007 14:55:05 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l34Et4PK042054; Wed, 4 Apr 2007 18:55:04 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l34Et4K4042053; Wed, 4 Apr 2007 18:55:04 +0400 (MSD) (envelope-from ache) Date: Wed, 4 Apr 2007 18:55:03 +0400 From: Andrey Chernov To: Alexander Kabaev , current@freebsd.org, ports@freebsd.org Message-ID: <20070404145503.GA41981@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Alexander Kabaev , current@freebsd.org, ports@freebsd.org References: <20070404101321.GA37396@nagual.pp.ru> <20070404082346.64ce25cd@kan.dnsalias.net> <20070404125735.GA40094@nagual.pp.ru> <20070404090944.1a13e96f@kan.dnsalias.net> <20070404133529.GA40652@nagual.pp.ru> <20070404145105.GA41879@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20070404145105.GA41879@nagual.pp.ru> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Re: DSO loading (dlopen) appearse to be broken somehow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 14:55:06 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2007 at 06:51:05PM +0400, Andrey Chernov wrote: > Comparing generated Makefile with FreeBSD 6 it seems some ld flags=20 > are now missing: >=20 > < LDFLAGS_SHLIB_EXPORT=3D > --- > > LDFLAGS_SHLIB_EXPORT=3D-Wl,-E >=20 > I'll come back with detailed results later. Found. It is old objformat problem. OBJFORMAT=3D`test -x /usr/bin/objformat && /usr/bin/objformat |= |=20 echo aout` if [ "x$OBJFORMAT" =3D "xelf" ]; then LDFLAGS_SHLIB_EXPORT=3D"-Wl,-E" SHLIB_SUFFIX_DEPTH=3D0 else LDFLAGS_SHLIB_EXPORT=3D"" SHLIB_SUFFIX_DEPTH=3D2 fi Sorry for the noise. --=20 http://ache.pp.ru/ --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGE7xHVg5YK5ZEdN0RAuZxAJ0Znqu+6GfXFELBL+g1prID7Eyz2wCfbFJy wf4XrBzXM87QDuTtbsOsjBE= =GU6I -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 16:04:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E4B116A405; Wed, 4 Apr 2007 16:04:37 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC0013C45D; Wed, 4 Apr 2007 16:04:37 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 280891A4D8E; Wed, 4 Apr 2007 09:04:37 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 55A65514C3; Wed, 4 Apr 2007 12:04:36 -0400 (EDT) Date: Wed, 4 Apr 2007 12:04:36 -0400 From: Kris Kennaway To: Danny Braniss Message-ID: <20070404160436.GA59964@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: diskless/rm causing deadlock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 16:04:37 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2007 at 11:55:10AM +0300, Danny Braniss wrote: > I stumbled on this in -current, but it's also true for 6.2. > /(root) is mounted diskless, doing rm of a file in /, even as a lowly mor= tal > will hang the network, and hence everything. > on a 6.1 system, it works as expected. >=20 > badwolf> rm /usr/ports > rm: /usr/ports: Read-only file system >=20 > i'll try to hunt this down, but some pointers where to start might be > helpfull Start with a tcpdump of network traffic. CC mohans@ :) I have seen something similar myself, but have not yet tracked it down. Kris --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGE8yTWry0BWjoQKURAvG9AJsHKNCCi8AV9KVQMCrSFidbWiNjCwCgjfV7 KILfBeVETHbPjWKC0uBd7qY= =2jSw -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 17:09:23 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B37616A408; Wed, 4 Apr 2007 17:09:23 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1622E13C46A; Wed, 4 Apr 2007 17:09:23 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 14A9A5D65; Wed, 4 Apr 2007 12:48:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKvchYvDpBa0; Wed, 4 Apr 2007 12:48:56 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-116-136.ny325.east.verizon.net [68.161.116.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 2CFD95D00; Wed, 4 Apr 2007 12:48:56 -0400 (EDT) Message-ID: <4613D6F3.4080701@mac.com> Date: Wed, 04 Apr 2007 12:48:51 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andrew Pantyukhin References: <46128475.9060602@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 17:09:23 -0000 Andrew Pantyukhin wrote: > On 4/3/07, Maxim Sobolev wrote: >> Patch ld(1) to detect the condition and don't unlink the device node? > > Yes, but there has to be a generic solution, so that > we don't reinvent the wheel for every one of the > thousands apps that may do this. > > Isn't there some safety-net wrapper function that > refuses to remove device nodes and maybe some other > types of files? Why not set a filesystem flag like schg on device nodes under a devfs tree...? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 17:18:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBD8D16A408; Wed, 4 Apr 2007 17:18:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D7A7413C46A; Wed, 4 Apr 2007 17:18:00 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4FA901A4DA7; Wed, 4 Apr 2007 10:18:00 -0700 (PDT) Date: Wed, 4 Apr 2007 10:18:00 -0700 From: Alfred Perlstein To: Howard Su Message-ID: <20070404171800.GW61362@elvis.mu.org> References: <20070404101222.GU61362@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 17:18:01 -0000 * Howard Su [070404 04:35] wrote: > On 4/4/07, Alfred Perlstein wrote: > >* Howard Su [070404 01:20] wrote: > >> Following the suggestion in idea page, I proposed the attached patch. > >> I didn't change any kernel part because I think PTRACE(2) is > >> functional although man page didn't document it. > >> > >> I tested the patch under i386 and amd64 box. The help on testing and > >> code review will be appreciated. > > > >wow, well done! any draw backs to using ptrace over procfs? > I didn't see. > > > >have you tested performance? > Not yet. Base on the number of kernel syscall, new implementaion keep > in a same level. However ptrace calls has a short code path compare to > generic read syscall. I suppose there will be some improvement. > Anyway, I will try to get perf data. Thank you very much for the work, perhaps if the performance is slower we can make it a runtime option? Regardless, very well done, it's nice not to have this depend on procfs any longer! -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 19:32:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EBE416A406 for ; Wed, 4 Apr 2007 19:32:16 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF1E13C45D for ; Wed, 4 Apr 2007 19:32:16 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HZB8H-00027i-JB; Wed, 04 Apr 2007 21:27:01 +0200 Message-ID: <4613FC04.1040302@gwdg.de> Date: Wed, 04 Apr 2007 21:27:00 +0200 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070318) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20070313004601.GA87608@cdnetworks.co.kr> <20070313005845.GB87608@cdnetworks.co.kr> <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> <46113CF2.6090009@gwdg.de> <20070403035845.GB7223@cdnetworks.co.kr> <461285A6.5010805@gwdg.de> <20070404003215.GA11525@cdnetworks.co.kr> In-Reply-To: <20070404003215.GA11525@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 19:32:16 -0000 Pyun YongHyeon schrieb: > On Tue, Apr 03, 2007 at 06:49:42PM +0200, Rainer Hurling wrote: > > [...] > > > > In "man ehci(4)" I found: > > > > ------- > > BUGS > > The driver is not finished and is quite buggy. > > There is currently no support for isochronous transfers. > > ------- > > > > Possibly this could cause the observed "dropouts" of nfe0 from a few > > seconds till several minutes? > > > > I'm not familiar with ehci(4) but I think it has nothing to do with > missing Tx completion interrupts observed on nfe(4). > > > > > Is there a knob or option in driver nfe(4) I can use to try classical > > polling or any 'lower' mode of operation? > > > > Add 'options DEVICE_POLLING' into kernel configuration file and > rebuild your kernel. Use ifconfig(8) to enable/disable polling(4) > feature. > See polling(4) for more detailed description and tuning parameters. > Thank you for this hint. I compiled my kernel with 'options DEVICE_POLLING' and reboot. For the first four hours I get no new watchdog timeouts. But then, without heavy load and without using usb devices, I get many timeouts. Obiously nfe(4) does not support this polling feature? Or we are looking at the wrong side ... Rainer From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 19:38:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DC2716A403 for ; Wed, 4 Apr 2007 19:38:09 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE0013C459 for ; Wed, 4 Apr 2007 19:38:09 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp6-g19.free.fr (Postfix) with ESMTP id 18E266D517; Wed, 4 Apr 2007 21:38:07 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id CAFFD11D5D; Wed, 4 Apr 2007 21:38:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at xbsd.org Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HadZJtId2eTn; Wed, 4 Apr 2007 21:38:01 +0200 (CEST) Received: from [193.120.13.130] (cream.xbsd.org [193.120.13.130]) by smtp.xbsd.org (Postfix) with ESMTP id 9C9C011410; Wed, 4 Apr 2007 21:37:59 +0200 (CEST) Message-ID: <4613FEAA.20406@FreeBSD.org> Date: Wed, 04 Apr 2007 20:38:18 +0100 From: Florent Thoumie User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: Benjamin Close References: <200704031843.l33Ih7l3067181@ambrisko.com> <4612D192.1020406@clearchain.com> In-Reply-To: <4612D192.1020406@clearchain.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE1059E59CF43E613CA9B124D" Cc: "Sam Fourman Jr." , Vince , freebsd-current@freebsd.org, yal@yal.hopto.org Subject: Re: Intel 3945ABG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 19:38:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1059E59CF43E613CA9B124D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benjamin Close wrote: > Doug Ambrisko wrote: >> Sam Fourman Jr. writes: >> | do you have a diff that fixes the leaks? >> >> Note he is working on a new version that deals with the new firmware >> that has a different API. >> >> =20 >=20 > The new firmware version should be hitting p4 in a day or so, then the > cleanup will begin. Cool! And for those who were still wondering, I'm not working on the driver, due to lack of time and knowledge. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --------------enigE1059E59CF43E613CA9B124D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE/6wMxEkbVFH3PQRCsCwAJ4mfQM3zlBlgBs0P0kakClOjv7lDACfTP/Q Y/h0O0tmyd5XAIaIwE7Ja5A= =mdyz -----END PGP SIGNATURE----- --------------enigE1059E59CF43E613CA9B124D-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 23:29:34 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BCE516A401; Wed, 4 Apr 2007 23:29:34 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 06EAA13C459; Wed, 4 Apr 2007 23:29:33 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l34NTTaX041944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 16:29:31 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <461434A6.3080001@FreeBSD.org> Date: Wed, 04 Apr 2007 16:28:38 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chuck Swiger References: <46128475.9060602@FreeBSD.org> <4613D6F3.4080701@mac.com> In-Reply-To: <4613D6F3.4080701@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Pantyukhin , FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 23:29:34 -0000 Chuck Swiger wrote: > Andrew Pantyukhin wrote: >> On 4/3/07, Maxim Sobolev wrote: >>> Patch ld(1) to detect the condition and don't unlink the device node? >> >> Yes, but there has to be a generic solution, so that >> we don't reinvent the wheel for every one of the >> thousands apps that may do this. >> >> Isn't there some safety-net wrapper function that >> refuses to remove device nodes and maybe some other >> types of files? > > Why not set a filesystem flag like schg on device nodes under a devfs > tree...? Well, I suspect that it may cause ld(1) fail instead. What we want it to do is to not perform unlink(2) before open(2) when -o argument is device node. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 00:28:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC4F216A402 for ; Thu, 5 Apr 2007 00:28:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 9248413C45E for ; Thu, 5 Apr 2007 00:28:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so355832wxc for ; Wed, 04 Apr 2007 17:28:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=CnwHWIkReEKua4JfLcazKmqrCrTNIyhughQChM4KooXtb46pCvHV5jlPMjaffBbxuFLUcIE3+pamBl2WIsRvwmJOabIQtBONIwW7+M1BDqoCU4idPoz0LpBrQiJXBt8xSD5btx0BU7foA54AXWhvZ0Kcc+Qsh8lJPzMN+Jpu72w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=EVPalNC2OOtwlBQIMEUrgo+w2CmSSc6aVY0NC6iT6CAAzs7/RkS/2R1eUA4ww5wu0kYGA0PoVK0BsA18IceDfJJWy6TuGiZecKddL1z//NiDq0rUdkKkL/2DeVaW9lpS7VTV7FBpZrygAMxJWCgJ0wWxAMf+vhI+OfgLx3/CB/w= Received: by 10.115.61.1 with SMTP id o1mr485099wak.1175732901413; Wed, 04 Apr 2007 17:28:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id m28sm3866095poh.2007.04.04.17.28.18; Wed, 04 Apr 2007 17:28:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l350SoOA016129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 09:28:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l350Smi8016128; Thu, 5 Apr 2007 09:28:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 5 Apr 2007 09:28:48 +0900 From: Pyun YongHyeon To: Rainer Hurling Message-ID: <20070405002848.GB15837@cdnetworks.co.kr> References: <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> <46113CF2.6090009@gwdg.de> <20070403035845.GB7223@cdnetworks.co.kr> <461285A6.5010805@gwdg.de> <20070404003215.GA11525@cdnetworks.co.kr> <4613FC04.1040302@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4613FC04.1040302@gwdg.de> User-Agent: Mutt/1.4.2.1i Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 00:28:22 -0000 On Wed, Apr 04, 2007 at 09:27:00PM +0200, Rainer Hurling wrote: > Pyun YongHyeon schrieb: > >On Tue, Apr 03, 2007 at 06:49:42PM +0200, Rainer Hurling wrote: > > > >[...] > > > > > > In "man ehci(4)" I found: > > > > > > ------- > > > BUGS > > > The driver is not finished and is quite buggy. > > > There is currently no support for isochronous transfers. > > > ------- > > > > > > Possibly this could cause the observed "dropouts" of nfe0 from a few > > > seconds till several minutes? > > > > > > >I'm not familiar with ehci(4) but I think it has nothing to do with > >missing Tx completion interrupts observed on nfe(4). > > > > > > > > Is there a knob or option in driver nfe(4) I can use to try classical > > > polling or any 'lower' mode of operation? > > > > > > >Add 'options DEVICE_POLLING' into kernel configuration file and > >rebuild your kernel. Use ifconfig(8) to enable/disable polling(4) > >feature. > >See polling(4) for more detailed description and tuning parameters. > > > > Thank you for this hint. I compiled my kernel with 'options > DEVICE_POLLING' and reboot. > > For the first four hours I get no new watchdog timeouts. But then, > without heavy load and without using usb devices, I get many timeouts. > > Obiously nfe(4) does not support this polling feature? Or we are looking > at the wrong side ... > Did you enable polling feature with ifconfig(8)? (e.g. ifconfig nfe0 polling) You should see POLLING in flags field in ifconfig output. > Rainer -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 01:22:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E27A16A401 for ; Thu, 5 Apr 2007 01:22:19 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1802A13C4BC for ; Thu, 5 Apr 2007 01:22:19 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZGfu-0005HD-79 for freebsd-current@freebsd.org; Wed, 04 Apr 2007 21:22:06 -0400 Message-ID: <46144FC6.3050801@metricsystems.com> Date: Wed, 04 Apr 2007 18:24:22 -0700 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Subject: Strange NFS root booting behavior. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 01:22:19 -0000 I've set up a dhcp server to support two (or more) clients, which mount their root on an nfs shared volume. For one client, the booting process has one symptom: after the initial PXEBOOT and getting the parameters from the dhcp server, the boot process hangs at: pxe_boot: gateway ip: ... And after a few minutes eventuall loads the loader.conf and after a few more minutes, loads the kernel, which seems pretty speedy given the twirlers. On the other system, oddly, the boot process seems to whip through the above boot section with no hesitation. However, after the kernel is loaded, and the init starts up, with in a ver few initial commands there is a diagnostic to the effect: Starting file system checks: Then ... mount /: Bad file descriptor Mounting root filesystem rw failed, startup aborted. Since I'm booting off of the same hierarchy, I did create a ramdisk and initialized a file system to have '/var/run' created local to the client systems. Are there other things that need to be separated for each client? And would failing to do set these up, give the above behavior, in particular the failure to boot and run through the normal rc scripts. Thanks John Clark. From owner-freebsd-current@FreeBSD.ORG Wed Apr 4 21:30:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0751C16A402 for ; Wed, 4 Apr 2007 21:30:02 +0000 (UTC) (envelope-from ed.maste@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id B569113C448 for ; Wed, 4 Apr 2007 21:30:00 +0000 (UTC) (envelope-from ed.maste@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so842214ugh for ; Wed, 04 Apr 2007 14:29:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EE+zZyWJPpsP88ZiwxM/zc1P8BRKpQf5/YmddTKHv3lFIDe1COld+xDB/kaGbtLYGWenv8BT7LNW54/qvNRcGv7IEZbprRAYK2i1pa5yALUBcSFYrCffPbD9wI7XQEt1g7gGn+5EgJIxibglo5sU3+TvBFtNZ5s0CiUxq1GA7w4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JrgYcyoNvgIpR/J3cVBmAV4U0bdgYVHMkxXU8N2irFD0LMxdI16Xb2giIza6CnlOIVbPFxgK4WYhqak0evqNzmbVutmhHmEw/cgD1N8xtfb5H+ZXmHnRI/5HGH/nMEMn+wuR7vvnqAS2wZ467U7q4zJ8O1J29T3IgSnrsIZXJP4= Received: by 10.78.124.13 with SMTP id w13mr206831huc.1175720781931; Wed, 04 Apr 2007 14:06:21 -0700 (PDT) Received: by 10.78.188.7 with HTTP; Wed, 4 Apr 2007 14:06:21 -0700 (PDT) Message-ID: <88607eb20704041406ka4902fdqe0f2897a2f9f15d9@mail.gmail.com> Date: Wed, 4 Apr 2007 17:06:21 -0400 From: "Ed Maste" To: "Ed Maste" , "Ed Schouten" , "Howard Su" , current@freebsd.org In-Reply-To: <20070404203221.GA88767@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070404121602.GI14608@hoeg.nl> <20070404203221.GA88767@sandvine.com> X-Mailman-Approved-At: Thu, 05 Apr 2007 01:28:31 +0000 Cc: Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 21:30:02 -0000 On Wed, Apr 04, 2007 at 02:16:02PM +0200, Ed Schouten wrote: > Indeed. Looking at sys/ptrace.h, there are a lot of instructions that > aren't documented in the manpage: > > - PT_GETNUMLWPS > - PT_GETLWPLIST [...] Yeah, it's unfortunate that these aren't documented and ptrace seems to be somewhat mysterious. I ran across this while starting to work on switching gcore from procfs to ptrace, in the context of getting it to understand threads. (Procfs provides /proc/pid/regs, which returns only the register set for the first thread in the process. There are other XXXKSE gotchas in the procfs source too.) Ed Maste From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 02:32:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57B8A16A401 for ; Thu, 5 Apr 2007 02:32:43 +0000 (UTC) (envelope-from blyon@bitgravity.com) Received: from util2.sjc1.bitgravity.com (util2.sjc1.bitgravity.com [208.67.233.36]) by mx1.freebsd.org (Postfix) with ESMTP id 472CB13C44C; Thu, 5 Apr 2007 02:32:43 +0000 (UTC) (envelope-from blyon@bitgravity.com) Received: from [209.131.110.155] by util2.sjc1.bitgravity.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZHDW-000GCh-6w; Wed, 04 Apr 2007 18:56:50 -0700 In-Reply-To: <46132852.8090005@freebsd.org> References: <461084EA.1000706@freebsd.org> <20070402.180446.1573371202.imp@bsdimp.com> <4611E26A.7010905@freebsd.org> <20070402.233439.-1548241370.imp@bsdimp.com> <46132852.8090005@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A9673F0-9430-405F-823D-0BDCE4977A7B@bitgravity.com> Content-Transfer-Encoding: 7bit From: Barrett Lyon Date: Wed, 4 Apr 2007 18:56:21 -0700 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Thu, 05 Apr 2007 04:41:34 +0000 Cc: vkashyap@FreeBSD.org Subject: twa failures on constant loads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 02:32:43 -0000 I'm getting a consistent failure with the twa driver Model 9550SX-16ML, 16 ports, Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002, it fails every within 24 hour periods with a constant load. It seems to just out of the blue loop with these console messages: twa0: INFO: (0x16: 0x1107): Controller reset done!: twa0: ERROR: (0x05: 0x210B): Request timed out!: request = 0xffffffff80e3e6b0 twa0: INFO: (0x16: 0x1108): Resetting controller...: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=26 twa0: INFO: (0x16: 0x1107): Controller reset done!: twa0: ERROR: (0x05: 0x210B): Request timed out!: request = 0xffffffff80e40b20 twa0: INFO: (0x16: 0x1108): Resetting controller...: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=27 twa0: INFO: (0x16: 0x1107): Controller reset done!: twa0: ERROR: (0x05: 0x210B): Request timed out!: request = 0xffffffff80e3dbb0 twa0: INFO: (0x16: 0x1108): Resetting controller...: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=28 twa0: INFO: (0x16: 0x1107): Controller reset done!: twa0: ERROR: (0x05: 0x210B): Request timed out!: request = 0xffffffff80e468a0 twa0: INFO: (0x16: 0x1108): Resetting controller...: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=29 twa0: INFO: (0x16: 0x1107): Controller reset done!: From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 06:00:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BE9916A401 for ; Thu, 5 Apr 2007 06:00:45 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 22AF013C45B for ; Thu, 5 Apr 2007 06:00:45 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from [87.139.104.184] (helo=[192.168.2.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1HZL1R-00023i-17; Thu, 05 Apr 2007 08:00:37 +0200 Message-ID: <4614907E.2070308@gwdg.de> Date: Thu, 05 Apr 2007 08:00:30 +0200 From: Rainer Hurling User-Agent: Thunderbird 1.5.0.10 (X11/20070318) MIME-Version: 1.0 To: pyunyh@gmail.com References: <45F636B5.9060608@gwdg.de> <20070313070153.GD87608@cdnetworks.co.kr> <20070331003031.GB68853@cdnetworks.co.kr> <460E77BE.9090503@gwdg.de> <20070402010230.GA1323@cdnetworks.co.kr> <46113CF2.6090009@gwdg.de> <20070403035845.GB7223@cdnetworks.co.kr> <461285A6.5010805@gwdg.de> <20070404003215.GA11525@cdnetworks.co.kr> <4613FC04.1040302@gwdg.de> <20070405002848.GB15837@cdnetworks.co.kr> In-Reply-To: <20070405002848.GB15837@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: darren780@yahoo.com, freebsd-current@freebsd.org, shigeaki@se.hiroshima-u.ac.jp Subject: Re: yongari nfe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 06:00:45 -0000 Pyun YongHyeon schrieb: > On Wed, Apr 04, 2007 at 09:27:00PM +0200, Rainer Hurling wrote: > > Pyun YongHyeon schrieb: > > >On Tue, Apr 03, 2007 at 06:49:42PM +0200, Rainer Hurling wrote: > > > > > >[...] > > > > > > > > In "man ehci(4)" I found: > > > > > > > > ------- > > > > BUGS > > > > The driver is not finished and is quite buggy. > > > > There is currently no support for isochronous transfers. > > > > ------- > > > > > > > > Possibly this could cause the observed "dropouts" of nfe0 from a few > > > > seconds till several minutes? > > > > > > > > > >I'm not familiar with ehci(4) but I think it has nothing to do with > > >missing Tx completion interrupts observed on nfe(4). > > > > > > > > > > > Is there a knob or option in driver nfe(4) I can use to try classical > > > > polling or any 'lower' mode of operation? > > > > > > > > > >Add 'options DEVICE_POLLING' into kernel configuration file and > > >rebuild your kernel. Use ifconfig(8) to enable/disable polling(4) > > >feature. > > >See polling(4) for more detailed description and tuning parameters. > > > > > > > Thank you for this hint. I compiled my kernel with 'options > > DEVICE_POLLING' and reboot. > > > > For the first four hours I get no new watchdog timeouts. But then, > > without heavy load and without using usb devices, I get many timeouts. > > > > Obiously nfe(4) does not support this polling feature? Or we are looking > > at the wrong side ... > > > > Did you enable polling feature with ifconfig(8)? > (e.g. ifconfig nfe0 polling) > You should see POLLING in flags field in ifconfig output. You are right. I forgot to set the flag, in my case 'ifconfig_nfe0="DHCP polling"' in /etc/rc.conf, sorry. Now it works like a charm :-) Thank you, Rainer From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 06:34:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23DE116A401 for ; Thu, 5 Apr 2007 06:34:02 +0000 (UTC) (envelope-from vlado@botka.homeunix.org) Received: from smtp-out4.iol.cz (smtp-out4.iol.cz [194.228.2.92]) by mx1.freebsd.org (Postfix) with ESMTP id 72E8513C45B for ; Thu, 5 Apr 2007 06:34:01 +0000 (UTC) (envelope-from vlado@botka.homeunix.org) Received: from smtp-out4.iol.cz (unknown [192.168.30.31]) by smtp-out4.iol.cz (Postfix) with ESMTP id D8D731647F3 for ; Thu, 5 Apr 2007 06:02:17 +0000 (UTC) Received: from ace.botka.homeunix.org (3.77.broadband2.iol.cz [83.208.77.3]) by smtp-out4.iol.cz (Postfix) with ESMTP id 711C247E32 for ; Thu, 5 Apr 2007 08:02:17 +0200 (CEST) Received: by ace.botka.homeunix.org (Postfix, from userid 1001) id A2C44166; Thu, 5 Apr 2007 08:02:16 +0200 (CEST) Received: from srv.g1.netng.org (ac.botka.homeunix.org [192.168.1.5]) by ace.botka.homeunix.org (Postfix) with ESMTP id 7ECA526 for ; Thu, 5 Apr 2007 08:02:13 +0200 (CEST) Received: from srv (srv [10.1.0.10]) by srv.g1.netng.org (Postfix) with ESMTP id 89F1ABCDE for ; Thu, 5 Apr 2007 08:02:12 +0200 (CEST) Date: Thu, 5 Apr 2007 08:02:12 +0200 From: Vladimir Botka To: freebsd-current@freebsd.org Message-ID: <20070405080212.2d7d1c8d@srv> In-Reply-To: <46144FC6.3050801@metricsystems.com> References: <46144FC6.3050801@metricsystems.com> X-Mailer: Claws Mail 2.7.2 (GTK+ 2.10.7; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Strange NFS root booting behavior. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 06:34:02 -0000 > I've set up a dhcp server to support two (or more) clients, which > mount their root on > an nfs shared volume. > > For one client, the booting process has one symptom: > > after the initial PXEBOOT and getting the parameters from the dhcp > server, the > boot process hangs at: > > pxe_boot: gateway ip: ... > > And after a few minutes eventuall loads the loader.conf > > and after a few more minutes, loads the kernel, which seems pretty > speedy given the twirlers. > > On the other system, oddly, the boot process seems to whip through the > above boot section with no hesitation. However, after the kernel is > loaded, and the init starts up, with in a ver few initial commands > there is a diagnostic to the effect: > > Starting file system checks: > > Then ... > > mount /: Bad file descriptor > Mounting root filesystem rw failed, startup aborted. > > Since I'm booting off of the same hierarchy, I did create a ramdisk > and initialized > a file system to have '/var/run' created local to the client systems. > > Are there other things that need to be separated for each client? And > would failing to do set these up, give the above behavior, in > particular the failure to boot > and run through the normal rc scripts. > > Thanks > John Clark. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Hello, try the script /usr/share/examples/diskless/clone_root to create copy of the root. The procedure in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-diskless.html works for me. Just an idea but did you compile the diskless kernel with "options BOOTP_NFSROOT" ? Cheers, -vlado From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 07:12:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6074B16A403 for ; Thu, 5 Apr 2007 07:12:24 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: from nemesis.frida.mouhaha.de (nemesis.frida.mouhaha.de [85.236.48.53]) by mx1.freebsd.org (Postfix) with ESMTP id 23FFB13C43E for ; Thu, 5 Apr 2007 07:12:24 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: by nemesis.frida.mouhaha.de (Postfix, from userid 1001) id EC59F4B27B9; Thu, 5 Apr 2007 09:12:22 +0200 (CEST) Date: Thu, 5 Apr 2007 09:12:22 +0200 From: "Peter, Oliver" To: freebsd-current@freebsd.org Message-ID: <20070405071222.GC50561@nemesis.frida.mouhaha.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1ccMZA6j1vT5UqiK" Content-Disposition: inline X-Operating-System: FreeBSD 6.2-RELEASE-p2 i386 User-Agent: Mutt/1.5.14 (2007-02-12) Subject: gencat:No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 07:12:24 -0000 --1ccMZA6j1vT5UqiK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear, My fresh cvsup'ed current tree can not be installed with the following error message: # cd /usr/src # make clean # make buildworld && make kernel && reboot (reboot) # cd /usr/src # mergemaster -p=20 # make installworld=20 And this stops with this error message: =3D=3D=3D> bin/csh (install) install -s -o root -g wheel -m 555 csh /bin install -o root -g wheel -m 444 /usr/src/bin/csh/../../contrib/tcsh/comple= te.tc cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/charset /usr/src/bin/csh/../= =2E./co rc/bin/csh/../../contrib/tcsh/nls/et/set11 /usr/src/bin/csh/../../contrib/t= csh/n =2E./../contrib/tcsh/nls/et/set14 /usr/src/bin/csh/../../contrib/tcsh/nls/e= t/set15 ib/tcsh/nls/et/set17 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set18 /usr/= src/b /et/set2 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set20 /usr/src/bin/csh/= =2E./.. sr/src/bin/csh/../../contrib/tcsh/nls/et/set23 /usr/src/bin/csh/../../contr= ib/tc csh/../../contrib/tcsh/nls/et/set26 /usr/src/bin/csh/../../contrib/tcsh/nls= /et/s nls/et/set4 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set5 /usr/src/bin/cs= h/../ sr/src/bin/csh/../../contrib/tcsh/nls/et/set8 /usr/src/bin/csh/../../contri= b/tcs gencat et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg gencat:No such file or directory *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Here comes my make.conf: % grep -v '#' /etc/make.conf=20 CPUTYPE?=3Dpentium-m CFLAGS=3D -O2 -fno-strict-aliasing -pipe CXXFLAGS+=3D -fconserve-space COPTFLAGS=3D -O -pipe This is a FreeBSD 7.0-CURRENT i386 machine. I already tried to find out something with my friend google but all I found= was: http://lists.freebsd.org/pipermail/freebsd-current/2003-November/014271.html (... and of course this workaround didn't work for me, too) Have a nice day, Ollie --=20 Oliver PETER, email: hoschi@mouhaha.de, ICQ# 113969174 "Worker bees can leave. Even drones can fly away. The Queen is their slave." --1ccMZA6j1vT5UqiK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iEYEARECAAYFAkYUoVYACgkQ6LH/IUVtaI+PfACgyf3N/vAG8xyX8LDu/3CoL6z7 toEAn0TCJ59D6Xk4YYj6AF26fdXGs7r6 =bQYW -----END PGP SIGNATURE----- --1ccMZA6j1vT5UqiK-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 07:51:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCD1416A40D for ; Thu, 5 Apr 2007 07:51:23 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6A913C4C5 for ; Thu, 5 Apr 2007 07:51:23 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id BC726383C6; Thu, 5 Apr 2007 10:28:19 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87702-03; Thu, 5 Apr 2007 10:28:18 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id B351E383C3; Thu, 5 Apr 2007 10:28:18 +0300 (EEST) Message-ID: <4614A512.7040503@bulinfo.net> Date: Thu, 05 Apr 2007 10:28:18 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Subject: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 07:51:23 -0000 Hi, This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. # ./tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes Bus error (core dumped) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-marcel-freebsd"... Core was generated by `tcpdump'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libpcap.so.4...done. Loaded symbols for /lib/libpcap.so.4 Reading symbols from /lib/libcrypto.so.5...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000203a4 in ether_print () (gdb) bt #0 0x000203a4 in ether_print () #1 0x00020730 in ether_if_print () #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, sp=0x2040901a "") at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 #5 0x0005c3b0 in $a () at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 #6 0x0005c3b0 in $a () at /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 (gdb) From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 08:07:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CD9A16A401 for ; Thu, 5 Apr 2007 08:07:00 +0000 (UTC) (envelope-from dsh@vlink.ru) Received: from sagitta.internal.vlink.ru (sagitta.internal.vlink.ru [85.172.168.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7322B13C457 for ; Thu, 5 Apr 2007 08:06:59 +0000 (UTC) (envelope-from dsh@vlink.ru) Received: from sagitta.internal.vlink.ru (localhost [127.0.0.1]) by sagitta.internal.vlink.ru (Postfix) with ESMTP id C1E0D1F45ED for ; Thu, 5 Apr 2007 12:06:57 +0400 (MSD) Received: from [85.172.168.250] (neva.vlink.ru [85.172.168.250]) by sagitta.internal.vlink.ru (Postfix) with ESMTP id 944AE1F45E6 for ; Thu, 5 Apr 2007 12:06:57 +0400 (MSD) Message-ID: <4614AE21.9030303@vlink.ru> Date: Thu, 05 Apr 2007 12:06:57 +0400 From: Denis Shaposhnikov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.9) Gecko/20070221 Thunderbird/1.5.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Fatal trap on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 08:07:00 -0000 Hi! I have CURRENT from Mar 30. And I've got a trap (see below). Something wrong with TCP? Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0517f6e stack pointer = 0x28:0xe4f08924 frame pointer = 0x28:0xe4f0892c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 22 (em0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 2d12h44m47s Physical memory: 2043 MB Dumping 292 MB: telnet> send brk KDB: enter: Line break on console [thread pid 22 tid 100022 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 22 tid 100022 td 0xc498e6c0 kdb_enter(c0649fe5) at kdb_enter+0x2b siointr1(c49e5800) at siointr1+0xce siointr(c49e5800) at siointr+0x5a intr_execute_handlers(c48efccc,e4f08530,4,e4f08594,c05fd764,...) at intr_execute _handlers+0xd9 lapic_handle_intr(36,e4f08530) at lapic_handle_intr+0x2f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc0615eb2, esp = 0xe4f08570, ebp = 0xe4f08594 --- DELAY(a) at DELAY+0x92 ata_start(c49dc400) at ata_start+0x2ff ata_queue_request(c8fb2900,c4a0d000,c4b74980,10000,0,...) at ata_queue_request+0x26f ad_strategy(e4f085f4,e4f085f4,84,202,0,...) at ad_strategy+0x1c1 ad_dump(c4b74980,c0c22000,0,2e5b4c00,8,...) at ad_dump+0xa4 blk_flush(c069cea0) at blk_flush+0x33 blk_write(c069cea0,0,15a4000,0) at blk_write+0x1fd minidumpsys(c069cea0,3c,0,4,e4f0879c,...) at minidumpsys+0x50f dumpsys(c069cea0,e4f087dc,c04d4d46,0,c4b7478c,...) at dumpsys+0x1a doadump(0,c4b7478c,e4f087fc,c4934c8c,c498e6c0,...) at doadump+0x42 boot(104,104,c498e6c0,28,e4f088e4,...) at boot+0x4e2 panic(c062f23f,c064ede3,0,0,fffff,...) at panic+0x1ab trap_fatal(e4f088e4,c,c498e6c0,c069b5c0,0,...) at trap_fatal+0x2de trap_pfault(e4f088e4,0,c) at trap_pfault+0x1c3 trap(e4f088e4) at trap+0x396 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0517f6e, esp = 0xe4f08924, ebp = 0xe4f0892c --- sbsndptr(cac80634,1651,5b4,e4f0898c,80000,...) at sbsndptr+0x56 tcp_output(c81da000,1a,0,1,2238,...) at tcp_output+0xb1c tcp_do_segment(ca02bd00,c883a040,cac80570,c81da000,28,0) at tcp_do_segment+0x105f tcp_input(ca02bd00,14,20,1,e4f08b84,...) at tcp_input+0xb5d ip_input(ca02bd00) at ip_input+0x60a netisr_dispatch(2,ca02bd00,2ff08bb8,2,c50b1340,...) at netisr_dispatch+0x48 gre_input(ca02bd00,14,ca02bd00,c4b9ac00) at gre_input+0x144 encap4_input(ca02bd00,14,e4f08c14,246,c4964e80,...) at encap4_input+0x142 ip_input(ca02bd00) at ip_input+0x60a netisr_dispatch(2,ca02bd00,e4f08c74,c49ca800,ca020800,...) at netisr_dispatch+0x48 ether_demux(c49ca800,ca02bd00,c497b800,ca02bd00,5d,...) at ether_demux+0x185 ether_input(c49ca800,ca02bd00,c0606e00,40e7278a,22d1f,...) at ether_input+0x310 em_handle_rxtx(c497b800,1) at em_handle_rxtx+0x1d2 taskqueue_run(c4983c00) at taskqueue_run+0x137 taskqueue_thread_loop(c497ba14,e4f08d38) at taskqueue_thread_loop+0x8e fork_exit(c04fb930,c497ba14,e4f08d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4f08d70, ebp = 0 --- -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet xmpp:dsh@vlink.ru mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 10:37:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2695416A403 for ; Thu, 5 Apr 2007 10:37:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA2413C448 for ; Thu, 5 Apr 2007 10:37:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l35Ab8N7031077; Thu, 5 Apr 2007 20:37:08 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l35Ab81Y031076; Thu, 5 Apr 2007 20:37:08 +1000 (EST) (envelope-from peter) Date: Thu, 5 Apr 2007 20:37:08 +1000 From: Peter Jeremy To: Nikolas Britton Message-ID: <20070405103708.GC842@turion.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 10:37:11 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [-stable removed since it's not relevant there] On 2007-Apr-05 04:58:17 -0500, Nikolas Britton = wrote: >Can anything in the list below be removed from CURRENT? > >legacyfree1# cd dev/ >legacyfree1# grep -irsn isa ./ | grep -i include =2E.. >legacyfree1# grep -irsn mca ./ | grep -i include =2E.. Why do you believe anything in the list might need to be removed? --=20 Peter Jeremy --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFNFU/opHv/APuIcRAhJIAKCklnnRLAr0TiCJG1Z1B1BIVSdEQgCgq5pS VhBCRGS/fY6kkLqfXexg0cA= =n8K1 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 11:13:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B277D16A403; Thu, 5 Apr 2007 11:13:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 69EA013C45B; Thu, 5 Apr 2007 11:13:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 5C4CB388BE; Thu, 5 Apr 2007 14:13:41 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09039-04; Thu, 5 Apr 2007 14:13:38 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 50C3F388B7; Thu, 5 Apr 2007 14:13:38 +0300 (EEST) Message-ID: <4614D9E1.5080603@bulinfo.net> Date: Thu, 05 Apr 2007 14:13:37 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Olivier Houchard References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> In-Reply-To: <20070405110305.GA35723@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 11:13:43 -0000 Olivier Houchard wrote: > On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > >> Hi, >> >> This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. >> >> # ./tcpdump >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes >> Bus error (core dumped) >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "arm-marcel-freebsd"... >> Core was generated by `tcpdump'. >> Program terminated with signal 10, Bus error. >> Reading symbols from /lib/libpcap.so.4...done. >> Loaded symbols for /lib/libpcap.so.4 >> Reading symbols from /lib/libcrypto.so.5...done. >> Loaded symbols for /lib/libcrypto.so.5 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x000203a4 in ether_print () >> (gdb) bt >> #0 0x000203a4 in ether_print () >> #1 0x00020730 in ether_if_print () >> #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, >> sp=0x2040901a "") >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 >> #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 >> #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 >> #5 0x0005c3b0 in $a () >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >> #6 0x0005c3b0 in $a () >> at >> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >> (gdb) >> >> > > I remember seeing this, but I thought make worlding fixed it. > Warner, do you remember what the issue was, and how/if we fixed it ? > I think it had to do with the change in alignment somewhere. > > Olivier > > I am not sure whether it is related or not but I receive this message when logging on console: ld-elf.so.1: assert failed: /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 The world and the kernel are in sync (cvsup on 30.3) From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 11:18:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2564016A401 for ; Thu, 5 Apr 2007 11:18:04 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id D66A213C455 for ; Thu, 5 Apr 2007 11:18:03 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8403C8BCEF7 for ; Thu, 5 Apr 2007 12:52:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwNtnOWBwPIg for ; Thu, 5 Apr 2007 12:52:37 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9666A8BCEEC for ; Thu, 5 Apr 2007 12:52:37 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l35Aqb5C009961 for current@freebsd.org; Thu, 5 Apr 2007 12:52:37 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 5 Apr 2007 12:52:37 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20070405105237.GA9755@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: 100% reproducible panic with pseudofs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 11:18:04 -0000 hi with -current as of 2nd April I can reliable panic the system in pseudofs with the following command sequence: mount /proc cat /proc/123/status umount /proc kldunload procfs the same panic is here with linprocfs so I think its pseudofs related. I cannot get the backtrace so I had to rewrite it by hand: kern_kldunload(); linker_file_unload(); module_unload(); vfs_modevent(); _procfs_uninit(); pfs_uninit(); delete_unrhdr() PANIC; it panics on KASSERT(uh->busy == 0, ("unrhdr has %u allocations", uh->busy)); so to reproduce this panic you have to have INVARIANTS enabled kernel... thnx roman From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 10:22:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B93316A403 for ; Thu, 5 Apr 2007 10:22:26 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 37EFC13C45B for ; Thu, 5 Apr 2007 10:22:25 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so611115ana for ; Thu, 05 Apr 2007 03:22:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iYTB8zQQnGiYWTW3LNN8qfjjakOUHP7TsCkbEbDGle7K22zpA0fOKrSZhDEHTsiuua+vFX6z5rfoaWFRrv9+DvA+O+KEeMwBjWSV0AxCfSYqXgyZWp1ZApcUG9tk4FnTsBnJKh1xBpOZ1IJTEHSLydM5Q9Ie2hK0bP4xmh6p9M8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=U4sgnM0562lfkpamUDnkNZp3KRkVQfyBNjdGglO4ONOX44hxkebSOc91opLaHiIRNJCZKFvp9pcsBgpYMClWkFWfTxWDUDKnMRTKtnpLYu3+8pf9lOX6IHS26o1wR5DivLmwSAv3UH2cgav1B3CjDc+dt3Onnc4G0vsievib4Jk= Received: by 10.100.32.1 with SMTP id f1mr1134835anf.1175767097278; Thu, 05 Apr 2007 02:58:17 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Thu, 5 Apr 2007 02:58:17 -0700 (PDT) Message-ID: Date: Thu, 5 Apr 2007 04:58:17 -0500 From: "Nikolas Britton" To: "FreeBSD Stable" , "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Thu, 05 Apr 2007 11:23:25 +0000 Cc: Subject: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 10:22:26 -0000 Can anything in the list below be removed from CURRENT? legacyfree1# cd dev/ legacyfree1# grep -irsn isa ./ | grep -i include ./acpica/acpi.c:54:#include ./acpica/acpi.c:55:#include ./acpica/acpi_acad.c:46:#include ./acpica/acpi_acad.c:47:#include ./acpica/acpi_isab.c:44:#include ./advansys/adv_eisa.c:51:#include ./advansys/adv_isa.c:63:#include ./aha/aha_isa.c:72:#include ./aha/aha_mca.c:44:#include ./ahb/ahb.c:52:#include ./aic/aic_cbus.c:39:#include ./aic/aic_isa.c:39:#include ./aic7xxx/ahc_eisa.c:37:#include ./aic7xxx/ahc_isa.c:44:#include ./an/if_an_isa.c:69:#include ./an/if_an_isa.c:70:#include ./ar/if_ar_isa.c:57:#include ./ar/if_ar_isa.c:58:#include "isa_if.h" ./arcmsr/arcmsr.c:80:#include ./arl/if_arl_isa.c:57:#include ./arl/if_arl_isa.c:58:#include ./arl/if_arl_isa.c:59:#include ./asr/osd_util.h:80:# include "i386/isa/dpt_osd_defs.h" ./asr/osd_util.h:83:# include "i386/isa/dpt_osd_defs.h" ./asr/sys_info.h:55:# include "i386/isa/dpt_osd_util.h" ./asr/sys_info.h:58:# include "i386/isa/dpt_osd_util.h" ./ata/ata-cbus.c:45:#include ./ata/ata-isa.c:45:#include ./atkbdc/atkbd.c:57:#include ./atkbdc/atkbdc.c:54:#include ./atkbdc/atkbdc_isa.c:45:#include ./atkbdc/atkbdc_isa.c:46:#include ./atkbdc/psm.c:64:#include "opt_isa.h" ./atkbdc/psm.c:87:#include ./buslogic/bt_eisa.c:46:#include ./buslogic/bt_isa.c:46:#include ./buslogic/bt_mca.c:58:#include ./cs/if_cs_isa.c:46:#include ./ct/ct_isa.c:59:#include ./ct/ct_isa.c:60:#include ./ct/ct_isa.c:61:#include ./ct/ct_isa.c:82:#include ./ctau/if_ct.c:44:#include ./cx/if_cx.c:47:#include ./cy/cy_isa.c:48:#include ./dpt/dpt_eisa.c:31:#include "opt_eisa.h" ./dpt/dpt_eisa.c:45:#include ./dpt/dpt_isa.c:41:#include ./dpt/dpt_scsi.c:53:#include "opt_eisa.h" ./ed/if_ed_cbus.c:47:#include ./ed/if_ed_isa.c:49:#include ./eisa/eisaconf.c:36:#include "opt_eisa.h" ./eisa/eisaconf.c:51:#include ./eisa/eisaconf.h:37:#include "eisa_if.h" ./ep/if_ep_eisa.c:41:#include ./ep/if_ep_isa.c:49:#include ./ep/if_ep_isa.c:55:#include ./ex/if_ex.c:70:#include ./ex/if_ex.c:71:#include ./ex/if_ex_isa.c:48:#include ./ex/if_ex_isa.c:49:#include ./fb/splash_bmp.c:42:#include ./fb/vga.c:62:#include ./fdc/fdc.c:84:#include ./fdc/fdc.c:85:#include ./fdc/fdc.c:87:#include ./fdc/fdc_isa.c:44:#include ./fdc/fdc_isa.c:45:#include ./fe/if_fe_cbus.c:50:#include ./fe/if_fe_isa.c:49:#include ./hfa/hfa_eisa.c:88:#include ./hfa/hfa_eisa.c:89:#include ./ida/ida_eisa.c:49:#include ./ie/if_ie.c:144:#include ./ie/if_ie_isa.c:60:#include ./ie/if_ie_isa.c:61:#include ./ie/if_ie_isa.c:63:#include ./ieee488/ibfoo.c:50:#include ./ieee488/pcii.c:52:#include ./ieee488/upd7210.c:51:#include ./ipmi/ipmi_isa.c:43:#include ./joy/joy_isa.c:46:#include ./joy/joy_isa.c:47:#include "isa_if.h" ./le/if_le_cbus.c:57:#include ./le/if_le_isa.c:96:#include ./lmc/if_lmc.c:272:# include ./lmc/if_lmc.c:273:# include ./mcd/mcd.c:63:#include ./mcd/mcd_isa.c:24:#include ./mse/mse.c:88:#include ./mse/mse_cbus.c:88:#include ./mse/mse_isa.c:88:#include ./ncv/ncr53c500_pccard.c:58:#include ./nsp/nsp_pccard.c:57:#include ./pbio/pbio.c:50:#include ./pccbb/pccbb_isa.c:52:#include ./pcf/pcf_isa.c:50:#include ./pcf/pcf_isa.c:51:#include ./pci/isa_pci.c:44:#include ./pdq/if_fea.c:49:#include ./ppc/ppc_acpi.c:30:#include "opt_isa.h" ./ppc/ppc_acpi.c:39:#include ./ppc/ppc_acpi.c:40:#include ./ppc/ppc_isa.c:43:#include ./ppc/ppc_isa.c:45:#include ./rc/rc.c:57:#include ./rp/rp_isa.c:57:#include ./sbni/if_sbni_isa.c:48:#include ./scd/scd.c:65:#include ./scd/scd_isa.c:23:#include ./si/si.c:46:#include "opt_eisa.h" ./si/si_eisa.c:37:#include ./si/si_isa.c:39:#include ./sio/sio.c:76:#include ./sio/sio_isa.c:43:#include ./sio/sio_isa.c:44:#include ./sn/if_sn_isa.c:44:#include ./snc/if_snc_cbus.c:53:#include ./snc/if_snc_cbus.c:54:#include ./snc/if_snc_cbus.c:55:#include ./sound/isa/ad1816.c:30:#include ./sound/isa/ad1816.c:32:#include ./sound/isa/ess.c:34:#include ./sound/isa/ess.c:37:#include ./sound/isa/gusc.c:42:#include ./sound/isa/gusc.c:43:#include ./sound/isa/mss.c:35:#include ./sound/isa/mss.c:36:#include ./sound/isa/mss.c:39:#include ./sound/isa/sb16.c:34:#include ./sound/isa/sb16.c:37:#include ./sound/isa/sb8.c:34:#include ./sound/isa/sb8.c:37:#include ./sound/isa/sbc.c:29:#include ./sound/isa/sbc.c:31:#include ./sound/isa/sndbuf_dma.c:29:#include ./sound/pci/als4000.c:37:#include ./sound/pci/cmi.c:45:#include ./sound/pci/solo.c:31:#include ./sound/pcm/channel.c:28:#include "opt_isa.h" ./speaker/spkr.c:21:#include ./sr/if_sr_isa.c:48:#include ./sr/if_sr_isa.c:49:#include "isa_if.h" ./stg/tmc18c30_isa.c:57:#include ./stg/tmc18c30_pccard.c:59:#include ./stg/tmc18c30_pci.c:59:#include ./stg/tmc18c30_subr.c:55:#include ./syscons/scvgarndr.c:50:#include ./uart/uart_bus_acpi.c:38:#include ./uart/uart_bus_isa.c:38:#include ./vx/if_vx_eisa.c:49:#include ./wds/wd7000.c:158:#include ./wds/wd7000.c:159:#include ./wl/if_wl.c:224:#include legacyfree1# grep -irsn mca ./ | grep -i include ./aha/aha_mca.c:46:#include ./aha/aha_mca.c:47:#include ./buslogic/bt_mca.c:55:#include ./buslogic/bt_mca.c:56:#include ./ep/if_ep_mca.c:44:#include ./ep/if_ep_mca.c:45:#include ./mca/mca_bus.c:51:#include ./mca/mca_bus.c:52:#include legacyfree1# uname -a FreeBSD legacyfree1.local 7.0-CURRENT-200703 FreeBSD 7.0-CURRENT-200703 #1: Wed Mar 7 17:17:11 UTC 2007 nbritton@legacyfree1.local:/usr/src/sys/i386/compile/GENERIC i386 From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 11:04:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A14816A403; Thu, 5 Apr 2007 11:04:43 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8F013C45A; Thu, 5 Apr 2007 11:04:42 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l35B39dE035757; Thu, 5 Apr 2007 13:03:09 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l35B35Ns035756; Thu, 5 Apr 2007 13:03:05 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 5 Apr 2007 13:03:05 +0200 From: Olivier Houchard To: Krassimir Slavchev Message-ID: <20070405110305.GA35723@ci0.org> References: <4614A512.7040503@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4614A512.7040503@bulinfo.net> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 05 Apr 2007 11:23:40 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, Warner Losh Subject: Re: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 11:04:43 -0000 On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > Hi, > > This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > > # ./tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > Bus error (core dumped) > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "arm-marcel-freebsd"... > Core was generated by `tcpdump'. > Program terminated with signal 10, Bus error. > Reading symbols from /lib/libpcap.so.4...done. > Loaded symbols for /lib/libpcap.so.4 > Reading symbols from /lib/libcrypto.so.5...done. > Loaded symbols for /lib/libcrypto.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x000203a4 in ether_print () > (gdb) bt > #0 0x000203a4 in ether_print () > #1 0x00020730 in ether_if_print () > #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, > sp=0x2040901a "") > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > #5 0x0005c3b0 in $a () > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > #6 0x0005c3b0 in $a () > at > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > (gdb) > I remember seeing this, but I thought make worlding fixed it. Warner, do you remember what the issue was, and how/if we fixed it ? I think it had to do with the change in alignment somewhere. Olivier From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 12:05:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFD3F16A404; Thu, 5 Apr 2007 12:05:40 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6163F13C44B; Thu, 5 Apr 2007 12:05:39 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 66311389EA; Thu, 5 Apr 2007 15:05:37 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13560-02; Thu, 5 Apr 2007 15:05:36 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 48EDF389E4; Thu, 5 Apr 2007 15:05:34 +0300 (EEST) Message-ID: <4614E60D.6010100@bulinfo.net> Date: Thu, 05 Apr 2007 15:05:33 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Olivier Houchard References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> <4614D9E1.5080603@bulinfo.net> <20070405120602.GA36086@ci0.org> In-Reply-To: <20070405120602.GA36086@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 12:05:41 -0000 Olivier Houchard wrote: > On Thu, Apr 05, 2007 at 02:13:37PM +0300, Krassimir Slavchev wrote: > >> Olivier Houchard wrote: >> >>> On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: >>> >>> >>>> Hi, >>>> >>>> This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. >>>> >>>> # ./tcpdump >>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >>>> listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes >>>> Bus error (core dumped) >>>> >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and you >>>> are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for >>>> details. >>>> This GDB was configured as "arm-marcel-freebsd"... >>>> Core was generated by `tcpdump'. >>>> Program terminated with signal 10, Bus error. >>>> Reading symbols from /lib/libpcap.so.4...done. >>>> Loaded symbols for /lib/libpcap.so.4 >>>> Reading symbols from /lib/libcrypto.so.5...done. >>>> Loaded symbols for /lib/libcrypto.so.5 >>>> Reading symbols from /lib/libc.so.7...done. >>>> Loaded symbols for /lib/libc.so.7 >>>> Reading symbols from /libexec/ld-elf.so.1...done. >>>> Loaded symbols for /libexec/ld-elf.so.1 >>>> #0 0x000203a4 in ether_print () >>>> (gdb) bt >>>> #0 0x000203a4 in ether_print () >>>> #1 0x00020730 in ether_if_print () >>>> #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", >>>> h=0xbfffeb98, >>>> sp=0x2040901a "") >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 >>>> #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 >>>> #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 >>>> #5 0x0005c3b0 in $a () >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >>>> #6 0x0005c3b0 in $a () >>>> at >>>> /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 >>>> (gdb) >>>> >>>> >>>> >>> I remember seeing this, but I thought make worlding fixed it. >>> Warner, do you remember what the issue was, and how/if we fixed it ? >>> I think it had to do with the change in alignment somewhere. >>> >>> Olivier >>> >>> >>> >> I am not sure whether it is related or not but I receive this message >> when logging on console: >> >> ld-elf.so.1: assert failed: >> /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 >> >> The world and the kernel are in sync (cvsup on 30.3) >> > > Huh interesting. > I think it's unrelated, I think this is an assert triggered at start time, > Yes, it happens after login. > but I'd really like to be able to reproduce it. > > Does that happen every time you run tcpdump ? > > No. Only when login on console. > Olivier > > From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 12:07:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA6D016A402 for ; Thu, 5 Apr 2007 12:07:24 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8384413C45E for ; Thu, 5 Apr 2007 12:07:24 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so228450pyh for ; Thu, 05 Apr 2007 05:07:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=heVpT7eUTzpdDXlUGxtmzhlpaBWV9bL+b7QT4kSfTpXu39tnN6hWGNvKul7KIGdFPZ2ao4fXBsg5O0epGsL+mGd1XzgBiH1ZdRL5VzEr/lrWP8c9K11rv6tiPbj0z71JpaZYsfmuNlzGpICWttYx60Ye+vDGLgjG5amU5Q0R86s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kdnufFRk06BKdFI/ZQq8JWuk/Q/bv856PSAPyE0M3kM2CLZW+7SL2pwkJHcP4mkpD13apocXFj4GJAHlFc9igScTL7PCyZFz6MTYGnkPdDeWCRv12e1F2by1N9X/i8L9cWzXwDhWDdAiH4TGbRnmNxI2HxT07o7zvh9u3OA1Mak= Received: by 10.65.114.4 with SMTP id r4mr3639350qbm.1175774843964; Thu, 05 Apr 2007 05:07:23 -0700 (PDT) Received: from ?192.168.1.72? ( [70.234.111.73]) by mx.google.com with ESMTP id 38sm2764014nzf.2007.04.05.05.07.22; Thu, 05 Apr 2007 05:07:22 -0700 (PDT) Message-ID: <4614E697.4000303@gmail.com> Date: Thu, 05 Apr 2007 07:07:51 -0500 From: Harrison Grundy User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Barrett Lyon References: <461084EA.1000706@freebsd.org> <20070402.180446.1573371202.imp@bsdimp.com> <4611E26A.7010905@freebsd.org> <20070402.233439.-1548241370.imp@bsdimp.com> <46132852.8090005@freebsd.org> <7A9673F0-9430-405F-823D-0BDCE4977A7B@bitgravity.com> In-Reply-To: <7A9673F0-9430-405F-823D-0BDCE4977A7B@bitgravity.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: vkashyap@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: twa failures on constant loads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 12:07:24 -0000 Barrett Lyon wrote: > I'm getting a consistent failure with the twa driver Model > 9550SX-16ML, 16 ports, Firmware FE9X 3.04.00.005, BIOS BE9X > 3.04.00.002, it fails every within 24 hour periods with a constant > load. It seems to just out of the blue loop with these console messages: > > twa0: INFO: (0x16: 0x1107): Controller reset done!: > twa0: ERROR: (0x05: 0x210B): Request timed out!: request = > 0xffffffff80e3e6b0 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=26 > twa0: INFO: (0x16: 0x1107): Controller reset done!: > twa0: ERROR: (0x05: 0x210B): Request timed out!: request = > 0xffffffff80e40b20 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=27 > twa0: INFO: (0x16: 0x1107): Controller reset done!: > twa0: ERROR: (0x05: 0x210B): Request timed out!: request = > 0xffffffff80e3dbb0 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=28 > twa0: INFO: (0x16: 0x1107): Controller reset done!: > twa0: ERROR: (0x05: 0x210B): Request timed out!: request = > 0xffffffff80e468a0 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=29 > twa0: INFO: (0x16: 0x1107): Controller reset done!: > Have you installed the latest firmware from 3ware? From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 12:51:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9C5016A404 for ; Thu, 5 Apr 2007 12:51:24 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 92A3F13C45D for ; Thu, 5 Apr 2007 12:51:24 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 32EBE5FBF; Thu, 5 Apr 2007 16:27:40 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id ED8805E9A; Thu, 5 Apr 2007 16:27:39 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id l35CRBU7056524; Thu, 5 Apr 2007 16:27:11 +0400 (MSD) (envelope-from ru) Date: Thu, 5 Apr 2007 16:27:11 +0400 From: Ruslan Ermilov To: "Peter, Oliver" Message-ID: <20070405122711.GA39895@rambler-co.ru> References: <20070405071222.GC50561@nemesis.frida.mouhaha.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20070405071222.GC50561@nemesis.frida.mouhaha.de> User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: No virus found Cc: freebsd-current@freebsd.org Subject: Re: gencat:No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 12:51:24 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 09:12:22AM +0200, Peter, Oliver wrote: > Dear, >=20 > My fresh cvsup'ed current tree can not be installed with the following > error message: >=20 > # cd /usr/src > # make clean > # make buildworld && make kernel && reboot > (reboot) > # cd /usr/src > # mergemaster -p=20 > # make installworld=20 >=20 > And this stops with this error message: >=20 > =3D=3D=3D> bin/csh (install) > install -s -o root -g wheel -m 555 csh /bin > install -o root -g wheel -m 444 /usr/src/bin/csh/../../contrib/tcsh/comp= lete.tc > cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/charset /usr/src/bin/csh/.= =2E/../co > rc/bin/csh/../../contrib/tcsh/nls/et/set11 /usr/src/bin/csh/../../contrib= /tcsh/n > ../../contrib/tcsh/nls/et/set14 /usr/src/bin/csh/../../contrib/tcsh/nls/e= t/set15 > ib/tcsh/nls/et/set17 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set18 /us= r/src/b > /et/set2 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set20 /usr/src/bin/cs= h/../.. > sr/src/bin/csh/../../contrib/tcsh/nls/et/set23 /usr/src/bin/csh/../../con= trib/tc > csh/../../contrib/tcsh/nls/et/set26 /usr/src/bin/csh/../../contrib/tcsh/n= ls/et/s > nls/et/set4 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set5 /usr/src/bin/= csh/../ > sr/src/bin/csh/../../contrib/tcsh/nls/et/set8 /usr/src/bin/csh/../../cont= rib/tcs > gencat et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg > gencat:No such file or directory > *** Error code 1 >=20 > Stop in /usr/src/bin/csh. > *** Error code 1 >=20 Most likely, you forgot to run "make buildworld" after you last cvsupped, or your system date/time is set incorrectly. What you see above is that the install stage is trying to "build" something, which it's not supposed to do. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGFOsfqRfpzJluFF4RAlhwAJ9kx/OUYKkp4PtF5Mie/JDFVaRyHQCfTc3J bWlngINIUlvudXkaA3oWyPs= =trEe -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 13:06:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D47116A401 for ; Thu, 5 Apr 2007 13:06:21 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: from nemesis.frida.mouhaha.de (nemesis.frida.mouhaha.de [85.236.48.53]) by mx1.freebsd.org (Postfix) with ESMTP id 067CA13C468 for ; Thu, 5 Apr 2007 13:06:20 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: by nemesis.frida.mouhaha.de (Postfix, from userid 1001) id 477FE4B2567; Thu, 5 Apr 2007 15:06:19 +0200 (CEST) Date: Thu, 5 Apr 2007 15:06:19 +0200 From: "Peter, Oliver" To: Ruslan Ermilov Message-ID: <20070405130618.GA61925@nemesis.frida.mouhaha.de> References: <20070405071222.GC50561@nemesis.frida.mouhaha.de> <20070405122711.GA39895@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20070405122711.GA39895@rambler-co.ru> X-Operating-System: FreeBSD 6.2-RELEASE-p2 i386 User-Agent: Mutt/1.5.14 (2007-02-12) Cc: "Peter, Oliver" , freebsd-current@freebsd.org Subject: Re: gencat:No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 13:06:21 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 04:27:11PM +0400, Ruslan Ermilov wrote: > On Thu, Apr 05, 2007 at 09:12:22AM +0200, Peter, Oliver wrote: > > My fresh cvsup'ed current tree can not be installed with the following > > error message: > > [...] > > gencat et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg > > gencat:No such file or directory > > *** Error code 1 > >=20 > > Stop in /usr/src/bin/csh. > > *** Error code 1 > >=20 > Most likely, you forgot to run "make buildworld" after you > last cvsupped, or your system date/time is set incorrectly. > What you see above is that the install stage is trying to > "build" something, which it's not supposed to do. w00t - I stupid id... # /etc/rc.d/ntpdate restart Setting date via ntp. 5 Apr 15:03:17 ntpdate[13150]: step time server 193.225.14.162 offset 2414= 813.624846 sec Thanks for this hint. This is (was) a fresh installation. I will try it again ... ru@ Thanks again! --=20 Oliver PETER, email: hoschi@mouhaha.de, ICQ# 113969174 "Worker bees can leave. Even drones can fly away. The Queen is their slave." --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iEYEARECAAYFAkYU9EoACgkQ6LH/IUVtaI8WQQCePlisQWmipzb0FW/LbG5x46Qj NZ0An1XlIJCsDvBabrW5+gZ8y+LLhAtZ =9fHF -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 13:56:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E81716A401 for ; Thu, 5 Apr 2007 13:56:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3B113C4B0 for ; Thu, 5 Apr 2007 13:56:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 3A0FC1A4D8D; Thu, 5 Apr 2007 06:56:29 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3A06E513EB; Thu, 5 Apr 2007 09:56:28 -0400 (EDT) Date: Thu, 5 Apr 2007 09:56:27 -0400 From: Kris Kennaway To: Nikolas Britton Message-ID: <20070405135627.GA97163@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 13:56:29 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 05, 2007 at 04:58:17AM -0500, Nikolas Britton wrote: > Can anything in the list below be removed from CURRENT? Why did you ask on the wrong list (corrected in reply)? Kris P.S. Just because it says "ISA" does not mean that it is junk or a removal candidate. However, some of the network drivers on your list (and others) are removal candidates in 7.0 as announced a few times over the past few years, because they have no maintainers and are Giant-locked, which is now starting to hold some things back. --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFQALWry0BWjoQKURAjy8AJ0QI0UXtdiCn6RyvdNeFzKe4AHmFACgt16r tT54AWuP/uuWDDK7jDOR/qA= =Zlqs -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 14:13:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65D7216A407 for ; Thu, 5 Apr 2007 14:13:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C4D4C13C489 for ; Thu, 5 Apr 2007 14:13:23 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 54078 invoked from network); 5 Apr 2007 13:39:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2007 13:39:36 -0000 Message-ID: <46150402.6040907@freebsd.org> Date: Thu, 05 Apr 2007 16:13:22 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Denis Shaposhnikov References: <4614AE21.9030303@vlink.ru> In-Reply-To: <4614AE21.9030303@vlink.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 14:13:24 -0000 Denis Shaposhnikov wrote: > Hi! > > I have CURRENT from Mar 30. And I've got a trap (see below). Something > wrong with TCP? Nothing known. Please provide some further debugging to the sbsndptr() line. It'd also be helpful if you could run your kernel with INVARIANTS compiled in. -- Andre > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 06 > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0517f6e > stack pointer = 0x28:0xe4f08924 > frame pointer = 0x28:0xe4f0892c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 22 (em0 taskq) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 2d12h44m47s > Physical memory: 2043 MB > Dumping 292 MB: > telnet> send brk > KDB: enter: Line break on console > [thread pid 22 tid 100022 ] > Stopped at kdb_enter+0x2b: nop > db> where > Tracing pid 22 tid 100022 td 0xc498e6c0 > kdb_enter(c0649fe5) at kdb_enter+0x2b > siointr1(c49e5800) at siointr1+0xce > siointr(c49e5800) at siointr+0x5a > intr_execute_handlers(c48efccc,e4f08530,4,e4f08594,c05fd764,...) at > intr_execute > _handlers+0xd9 > lapic_handle_intr(36,e4f08530) at lapic_handle_intr+0x2f > Xapic_isr1() at Xapic_isr1+0x34 > --- interrupt, eip = 0xc0615eb2, esp = 0xe4f08570, ebp = 0xe4f08594 --- > DELAY(a) at DELAY+0x92 > ata_start(c49dc400) at ata_start+0x2ff > ata_queue_request(c8fb2900,c4a0d000,c4b74980,10000,0,...) at > ata_queue_request+0x26f > ad_strategy(e4f085f4,e4f085f4,84,202,0,...) at ad_strategy+0x1c1 > ad_dump(c4b74980,c0c22000,0,2e5b4c00,8,...) at ad_dump+0xa4 > blk_flush(c069cea0) at blk_flush+0x33 > blk_write(c069cea0,0,15a4000,0) at blk_write+0x1fd > minidumpsys(c069cea0,3c,0,4,e4f0879c,...) at minidumpsys+0x50f > dumpsys(c069cea0,e4f087dc,c04d4d46,0,c4b7478c,...) at dumpsys+0x1a > doadump(0,c4b7478c,e4f087fc,c4934c8c,c498e6c0,...) at doadump+0x42 > boot(104,104,c498e6c0,28,e4f088e4,...) at boot+0x4e2 > panic(c062f23f,c064ede3,0,0,fffff,...) at panic+0x1ab > trap_fatal(e4f088e4,c,c498e6c0,c069b5c0,0,...) at trap_fatal+0x2de > trap_pfault(e4f088e4,0,c) at trap_pfault+0x1c3 > trap(e4f088e4) at trap+0x396 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0517f6e, esp = 0xe4f08924, ebp = 0xe4f0892c --- > sbsndptr(cac80634,1651,5b4,e4f0898c,80000,...) at sbsndptr+0x56 > tcp_output(c81da000,1a,0,1,2238,...) at tcp_output+0xb1c > tcp_do_segment(ca02bd00,c883a040,cac80570,c81da000,28,0) at > tcp_do_segment+0x105f > tcp_input(ca02bd00,14,20,1,e4f08b84,...) at tcp_input+0xb5d > ip_input(ca02bd00) at ip_input+0x60a > netisr_dispatch(2,ca02bd00,2ff08bb8,2,c50b1340,...) at netisr_dispatch+0x48 > gre_input(ca02bd00,14,ca02bd00,c4b9ac00) at gre_input+0x144 > encap4_input(ca02bd00,14,e4f08c14,246,c4964e80,...) at encap4_input+0x142 > ip_input(ca02bd00) at ip_input+0x60a > netisr_dispatch(2,ca02bd00,e4f08c74,c49ca800,ca020800,...) at > netisr_dispatch+0x48 > ether_demux(c49ca800,ca02bd00,c497b800,ca02bd00,5d,...) at > ether_demux+0x185 > ether_input(c49ca800,ca02bd00,c0606e00,40e7278a,22d1f,...) at > ether_input+0x310 > em_handle_rxtx(c497b800,1) at em_handle_rxtx+0x1d2 > taskqueue_run(c4983c00) at taskqueue_run+0x137 > taskqueue_thread_loop(c497ba14,e4f08d38) at taskqueue_thread_loop+0x8e > fork_exit(c04fb930,c497ba14,e4f08d38) at fork_exit+0x7b > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe4f08d70, ebp = 0 --- > From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 15:14:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BFD616A402 for ; Thu, 5 Apr 2007 15:14:49 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.freebsd.org (Postfix) with ESMTP id E571113C487 for ; Thu, 5 Apr 2007 15:14:48 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from [81.237.208.107] (81.237.208.107) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 45FFF5CB0043C362; Thu, 5 Apr 2007 17:14:47 +0200 Message-ID: <46151262.8000805@gmail.com> Date: Thu, 05 Apr 2007 17:14:42 +0200 From: Niclas Zeising User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andre Oppermann References: <4614AE21.9030303@vlink.ru> <46150402.6040907@freebsd.org> In-Reply-To: <46150402.6040907@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Denis Shaposhnikov , freebsd-current@freebsd.org Subject: Re: Fatal trap on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 15:14:49 -0000 Andre Oppermann wrote: > Denis Shaposhnikov wrote: >> Hi! >> >> I have CURRENT from Mar 30. And I've got a trap (see below). Something >> wrong with TCP? > > Nothing known. Please provide some further debugging to the sbsndptr() > line. > > It'd also be helpful if you could run your kernel with INVARIANTS compiled > in. > TCP was broken for a while a couple (Maybe just 2) weeks ago, this might have something to do with it, try to upgrade to latest current sources. HTH! //Niclas From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 15:30:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6650716A401 for ; Thu, 5 Apr 2007 15:30:06 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: from nemesis.frida.mouhaha.de (nemesis.frida.mouhaha.de [85.236.48.53]) by mx1.freebsd.org (Postfix) with ESMTP id 21A2213C44B for ; Thu, 5 Apr 2007 15:30:06 +0000 (UTC) (envelope-from hoschi@nemesis.frida.mouhaha.de) Received: by nemesis.frida.mouhaha.de (Postfix, from userid 1001) id 43EF34B27BE; Thu, 5 Apr 2007 17:30:04 +0200 (CEST) Date: Thu, 5 Apr 2007 17:30:04 +0200 From: "Peter, Oliver" To: freebsd-current@freebsd.org Message-ID: <20070405153003.GB61925@nemesis.frida.mouhaha.de> References: <20070405071222.GC50561@nemesis.frida.mouhaha.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <20070405071222.GC50561@nemesis.frida.mouhaha.de> X-Operating-System: FreeBSD 6.2-RELEASE-p2 i386 User-Agent: Mutt/1.5.14 (2007-02-12) Subject: Re: gencat:No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 15:30:06 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 09:12:22AM +0200, Peter, Oliver wrote: > Dear, >=20 > My fresh cvsup'ed current tree can not be installed with the following > error message: >=20 > # cd /usr/src > # make clean > # make buildworld && make kernel && reboot > (reboot) > # cd /usr/src > # mergemaster -p=20 > # make installworld=20 >=20 > And this stops with this error message: >=20 > =3D=3D=3D> bin/csh (install) > install -s -o root -g wheel -m 555 csh /bin > install -o root -g wheel -m 444 /usr/src/bin/csh/../../contrib/tcsh/comp= lete.tc > cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/charset /usr/src/bin/csh/.= =2E/../co > rc/bin/csh/../../contrib/tcsh/nls/et/set11 /usr/src/bin/csh/../../contrib= /tcsh/n > ../../contrib/tcsh/nls/et/set14 /usr/src/bin/csh/../../contrib/tcsh/nls/e= t/set15 > ib/tcsh/nls/et/set17 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set18 /us= r/src/b > /et/set2 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set20 /usr/src/bin/cs= h/../.. > sr/src/bin/csh/../../contrib/tcsh/nls/et/set23 /usr/src/bin/csh/../../con= trib/tc > csh/../../contrib/tcsh/nls/et/set26 /usr/src/bin/csh/../../contrib/tcsh/n= ls/et/s > nls/et/set4 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set5 /usr/src/bin/= csh/../ > sr/src/bin/csh/../../contrib/tcsh/nls/et/set8 /usr/src/bin/csh/../../cont= rib/tcs > gencat et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg > gencat:No such file or directory > *** Error code 1 >=20 > Stop in /usr/src/bin/csh. > *** Error code 1 >=20 > Stop in /usr/src/bin. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. > *** Error code 1 >=20 > Stop in /usr/src. >=20 >=20 > Here comes my make.conf: >=20 > % grep -v '#' /etc/make.conf=20 > CPUTYPE?=3Dpentium-m > CFLAGS=3D -O2 -fno-strict-aliasing -pipe > CXXFLAGS+=3D -fconserve-space > COPTFLAGS=3D -O -pipe >=20 > This is a FreeBSD 7.0-CURRENT i386 machine. =2E.. After setting the date via ntpdate to NOW() everything wents fine. Thanks ru@ again. (Shame on me!!) --=20 Oliver PETER, email: hoschi@mouhaha.de, ICQ# 113969174 "Worker bees can leave. Even drones can fly away. The Queen is their slave." --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iEYEARECAAYFAkYVFfsACgkQ6LH/IUVtaI9hYACfUT7C2zOw2T5qqRTdLeh2IXUb uIEAoJJ+m/V2lHzgF+2Y0NlXGyAXZWzn =USUd -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 16:39:34 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58D9D16A402; Thu, 5 Apr 2007 16:39:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E77CC13C4BB; Thu, 5 Apr 2007 16:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35Gb86r084483; Thu, 5 Apr 2007 10:37:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 10:37:08 -0600 (MDT) Message-Id: <20070405.103708.71171924.imp@bsdimp.com> To: mlfbsd@ci0.org From: Warner Losh In-Reply-To: <20070405110305.GA35723@ci0.org> References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 10:37:10 -0600 (MDT) Cc: freebsd-arm@freebsd.org, krassi@bulinfo.net, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 16:39:34 -0000 From: Olivier Houchard Subject: Re: tcpdump crash on arm? Date: Thu, 5 Apr 2007 13:03:05 +0200 > On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > > Hi, > > > > This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > > > > # ./tcpdump > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > > Bus error (core dumped) > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "arm-marcel-freebsd"... > > Core was generated by `tcpdump'. > > Program terminated with signal 10, Bus error. > > Reading symbols from /lib/libpcap.so.4...done. > > Loaded symbols for /lib/libpcap.so.4 > > Reading symbols from /lib/libcrypto.so.5...done. > > Loaded symbols for /lib/libcrypto.so.5 > > Reading symbols from /lib/libc.so.7...done. > > Loaded symbols for /lib/libc.so.7 > > Reading symbols from /libexec/ld-elf.so.1...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > #0 0x000203a4 in ether_print () > > (gdb) bt > > #0 0x000203a4 in ether_print () > > #1 0x00020730 in ether_if_print () > > #2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", h=0xbfffeb98, > > sp=0x2040901a "") > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > > #3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > > #4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > > #5 0x0005c3b0 in $a () > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > > #6 0x0005c3b0 in $a () > > at > > /usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > > (gdb) > > > > I remember seeing this, but I thought make worlding fixed it. > Warner, do you remember what the issue was, and how/if we fixed it ? > I think it had to do with the change in alignment somewhere. I thought things were working. I'll have to check again. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:00:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBEC616A401 for ; Thu, 5 Apr 2007 17:00:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 73C6013C45D for ; Thu, 5 Apr 2007 17:00:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E2EFB2090; Thu, 5 Apr 2007 19:00:07 +0200 (CEST) X-Spam-Tests: AWL,DATE_IN_PAST_24_48 X-Spam-Learn: disabled X-Spam-Score: 0.4/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D6E3B20B9; Thu, 5 Apr 2007 18:59:59 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 8F089A10C1; Wed, 4 Apr 2007 11:54:42 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Lukas Ertl References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> Date: Wed, 04 Apr 2007 11:54:42 +0200 In-Reply-To: <46135841.1010902@freebsd.org> (Lukas Ertl's message of "Wed, 04 Apr 2007 09:48:17 +0200") Message-ID: <86abxov50d.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Johan Hendriks , freebsd-current@freebsd.org Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:00:13 -0000 Lukas Ertl writes: > I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. > Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? Can you check that /etc/rc and /etc/defaults/rc.conf are up-to-date - if they aren't, /etc/rc will use the wrong early / late divider. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:00:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EF4816A407; Thu, 5 Apr 2007 17:00:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0E02213C46A; Thu, 5 Apr 2007 17:00:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2B9F520F7; Thu, 5 Apr 2007 19:00:09 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7BD1B20C6; Thu, 5 Apr 2007 19:00:00 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E9F0EA10CA; Thu, 5 Apr 2007 15:34:39 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Nikolas Britton" References: Date: Thu, 05 Apr 2007 15:34:39 +0200 In-Reply-To: (Nikolas Britton's message of "Thu, 5 Apr 2007 04:58:17 -0500") Message-ID: <86zm5nrllc.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , FreeBSD Stable Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:00:15 -0000 "Nikolas Britton" writes: > Can anything in the list below be removed from CURRENT? No. Modern i386 and amd64 still have an ISA bus, and devices connected to that bus, even if they don't have ISA slots. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:00:19 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93BAD16A51D; Thu, 5 Apr 2007 17:00:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 063DA13C44C; Thu, 5 Apr 2007 17:00:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D027520A2; Thu, 5 Apr 2007 19:00:12 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B641020E8; Thu, 5 Apr 2007 19:00:01 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id F3428A10CB; Thu, 5 Apr 2007 17:59:06 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Roman Divacky References: <20070405105237.GA9755@freebsd.org> Date: Thu, 05 Apr 2007 17:59:05 +0200 In-Reply-To: <20070405105237.GA9755@freebsd.org> (Roman Divacky's message of "Thu, 5 Apr 2007 12:52:37 +0200") Message-ID: <86vegasth2.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: 100% reproducible panic with pseudofs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:00:19 -0000 Roman Divacky writes: > it panics on KASSERT(uh->busy =3D=3D 0, ("unrhdr has %u allocations", > uh->busy)); so to reproduce this panic you have to have INVARIANTS > enabled kernel... Pseudofs never releases filenos. This wasn't a problem when it had its own fileno allocation code, but became a problem when it was converted to unr*. I'm working on a fix (and on making pseudofs MPSAFE). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:09:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C13616A406; Thu, 5 Apr 2007 17:09:06 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a19.g.dreamhost.com (sd-green-bigip-202.dreamhost.com [208.97.132.202]) by mx1.freebsd.org (Postfix) with ESMTP id CA87F13C50A; Thu, 5 Apr 2007 17:08:57 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a19.g.dreamhost.com (Postfix) with ESMTP id DA85811815; Thu, 5 Apr 2007 10:08:56 -0700 (PDT) Message-ID: <46152D27.4080309@cyberwang.net> Date: Thu, 05 Apr 2007 13:08:55 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Ariff Abdullah References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> <4606C5C6.2060407@cyberwang.net> <20070326042040.37c66edb.ariff@FreeBSD.org> In-Reply-To: <20070326042040.37c66edb.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:09:06 -0000 Ariff Abdullah wrote: > On Sun, 25 Mar 2007 14:56:06 -0400 > Sean Bryant wrote: > >>> Try this one: (sys/dev/sound/pci/ich.c) >>> >>> http://people.freebsd.org/~ariff/test/ich.c >>> >>> (no, this has nothing to do with the panic at all) >>> >>> >>> > > At least, you should tell me whether this fix your attach issue or > not. > > >>>> With the latest HPS USB stack not sure if that's the same one in >>>> HEAD or not. >>>> Maybe something is conflicting or some other change has caused >>>> >>> the > resources to be tied up. That's a really rough guess with no >>> >>>> evidence to support it. >>>> >>>> >>>> >>> You should reproduce the panic, generate the dump, submit the >>> backtrace so things will become much clear for us. Will you? >>> >>> >> Okay I disabled the remote debugging things to get a dump but it >> keeps saying no dump device defined. I explicitly set it to my swap >> device. and still the same result. any ideas? >> >> > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > Are you still interested in seeing a panic or strange behavior with the snd_ich driver? I decided to load it up so I could give you a better report on what the error is. And my usb keyboard just kinda stopped working. I tried to reproduce it and it didn't happen, i thought it was a fluke. Then I played around for a bit and I tried to load it up again, and boom it happened again. I can't seem to figure out a pattern, but I'm going to get an ps/2 keyboard so I can give more detailed information but if this little bit helps great. From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:14:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A067016A401; Thu, 5 Apr 2007 17:14:24 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1501513C465; Thu, 5 Apr 2007 17:14:23 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id l35H9G4E023305; Thu, 5 Apr 2007 21:09:16 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id l35H9GVE023304; Thu, 5 Apr 2007 21:09:16 +0400 (MSD) (envelope-from ache) Date: Thu, 5 Apr 2007 21:09:15 +0400 From: Andrey Chernov To: Dag-Erling Sm?rgrav Message-ID: <20070405170915.GA23277@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Dag-Erling Sm?rgrav , Lukas Ertl , Johan Hendriks , freebsd-current@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB011158@w2003s01.double-l.local> <46135841.1010902@freebsd.org> <86abxov50d.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86abxov50d.fsf@dwp.des.no> User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Johan Hendriks , freebsd-current@freebsd.org Subject: Re: ports do not start at 7 current as of today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:14:24 -0000 On Wed, Apr 04, 2007 at 11:54:42AM +0200, Dag-Erling Sm?rgrav wrote: > Lukas Ertl writes: > > I can confirm this, /usr/local/etc/rc.d/* is ignored at boot time. > > Maybe this is fallout of the /etc/rc.d/FILESYSTEMS change? > > Can you check that /etc/rc and /etc/defaults/rc.conf are up-to-date - > if they aren't, /etc/rc will use the wrong early / late divider. The bug was fixed in defaults/rc.conf v1.310 -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 11:45:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 063AF16A402; Thu, 5 Apr 2007 11:45:30 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 354ED13C43E; Thu, 5 Apr 2007 11:45:28 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l35C62DQ036296; Thu, 5 Apr 2007 14:06:03 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l35C6270036295; Thu, 5 Apr 2007 14:06:02 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 5 Apr 2007 14:06:02 +0200 From: Olivier Houchard To: Krassimir Slavchev Message-ID: <20070405120602.GA36086@ci0.org> References: <4614A512.7040503@bulinfo.net> <20070405110305.GA35723@ci0.org> <4614D9E1.5080603@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4614D9E1.5080603@bulinfo.net> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 05 Apr 2007 17:46:56 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: tcpdump crash on arm? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 11:45:30 -0000 On Thu, Apr 05, 2007 at 02:13:37PM +0300, Krassimir Slavchev wrote: > Olivier Houchard wrote: > >On Thu, Apr 05, 2007 at 10:28:18AM +0300, Krassimir Slavchev wrote: > > > >>Hi, > >> > >>This is on 7.0-CURENT 4-5 days old but I have seen this for 2-3 months. > >> > >># ./tcpdump > >>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >>listening on ate0, link-type EN10MB (Ethernet), capture size 96 bytes > >>Bus error (core dumped) > >> > >>GNU gdb 6.1.1 [FreeBSD] > >>Copyright 2004 Free Software Foundation, Inc. > >>GDB is free software, covered by the GNU General Public License, and you > >>are > >>welcome to change it and/or distribute copies of it under certain > >>conditions. > >>Type "show copying" to see the conditions. > >>There is absolutely no warranty for GDB. Type "show warranty" for > >>details. > >>This GDB was configured as "arm-marcel-freebsd"... > >>Core was generated by `tcpdump'. > >>Program terminated with signal 10, Bus error. > >>Reading symbols from /lib/libpcap.so.4...done. > >>Loaded symbols for /lib/libpcap.so.4 > >>Reading symbols from /lib/libcrypto.so.5...done. > >>Loaded symbols for /lib/libcrypto.so.5 > >>Reading symbols from /lib/libc.so.7...done. > >>Loaded symbols for /lib/libc.so.7 > >>Reading symbols from /libexec/ld-elf.so.1...done. > >>Loaded symbols for /libexec/ld-elf.so.1 > >>#0 0x000203a4 in ether_print () > >>(gdb) bt > >>#0 0x000203a4 in ether_print () > >>#1 0x00020730 in ether_if_print () > >>#2 0x0005b594 in print_packet (user=0xbfffec18 "\020\a\002", > >>h=0xbfffeb98, > >> sp=0x2040901a "") > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1241 > >>#3 0x200f05bc in pcap_lookupnet () from /lib/libpcap.so.4 > >>#4 0x200f1a2c in pcap_loop () from /lib/libpcap.so.4 > >>#5 0x0005c3b0 in $a () > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > >>#6 0x0005c3b0 in $a () > >> at > >>/usr/src-arm/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1050 > >>(gdb) > >> > >> > > > >I remember seeing this, but I thought make worlding fixed it. > >Warner, do you remember what the issue was, and how/if we fixed it ? > >I think it had to do with the change in alignment somewhere. > > > >Olivier > > > > > I am not sure whether it is related or not but I receive this message > when logging on console: > > ld-elf.so.1: assert failed: > /usr/src-arm/src/libexec/rtld-elf/arm/reloc.c:289 > > The world and the kernel are in sync (cvsup on 30.3) Huh interesting. I think it's unrelated, I think this is an assert triggered at start time, but I'd really like to be able to reproduce it. Does that happen every time you run tcpdump ? Olivier From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 13:17:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BA0216A406 for ; Thu, 5 Apr 2007 13:17:37 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 1A53913C459 for ; Thu, 5 Apr 2007 13:17:36 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so662979ana for ; Thu, 05 Apr 2007 06:17:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fxuqJ7fBXMHOgoIvJck/sD27ROyrybaP7bKZXPKPS8ucBibqbOzB319iR5/sc6d73RbxTLHpvEZY8PBOIgTqmgquvr5e3uzGUoH/TLfVkmItzgiOAIfUF14bDcMHfj4ml66xIM/pZzcL67gHlJg5aPIbmqOjg89mBQMWXX/kVoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AFEUKw6SGtH7cac9MYBVKdI+z/mKmxsZTjXpyWTpJR8882CHGswK6wE213Yuprcswgkg4yiIVAToEIqjZ6gmSI3eTrRbQaIGeAN+0ZY12b18AwJAFCzCHBWXnbYw6yzDba4RMbiMrxirMQ25IOljWu6RNC9e2DWwNKFVFh/nVC4= Received: by 10.100.144.11 with SMTP id r11mr1260536and.1175779054327; Thu, 05 Apr 2007 06:17:34 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Thu, 5 Apr 2007 06:17:34 -0700 (PDT) Message-ID: Date: Thu, 5 Apr 2007 08:17:34 -0500 From: "Nikolas Britton" To: "Peter Jeremy" In-Reply-To: <20070405103708.GC842@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> X-Mailman-Approved-At: Thu, 05 Apr 2007 17:47:11 +0000 Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 13:17:37 -0000 On 4/5/07, Peter Jeremy wrote: > [-stable removed since it's not relevant there] > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: > >Can anything in the list below be removed from CURRENT? > > > >legacyfree1# cd dev/ > >legacyfree1# grep -irsn isa ./ | grep -i include > ... > >legacyfree1# grep -irsn mca ./ | grep -i include > ... > > Why do you believe anything in the list might need to be removed? > Because it's junk that doesn't belong, and can't even be use, in a modern operating system. For some perspective... Apple Mac Pro: 8-way 3.0GHz Intel Xeon ( 24 GHz ) 16GB System RAM NVIDIA Quadro FX 4500 512MB Now for some contrast, the AHA-1542: Supported Operating Systems: MS-DOS 3.x, 4.x, 5.x Number of devices: Up to 7 devices under DOS 5.0 Bus System Interface Type: ISA Hard Disk Capacity: Up to 8 GBytes per disk Floppy Drive Support: Supports two 5.25 in. floppy drives Release Date: 1987 Status: Discontinued CVS Log: ############################### Revision 1.33: Jan 2005 (2 years, 2 months ago) by imp Final attempt to make aha 1542A working. If not, oh well, I don't have the card and no way to reproduce problems. We do this by applying the workaround to firmware revsion 0. ############################### Revision 1.39: Feb 2007 (5 weeks, 6 days ago) by piso break newbus api: add a new argument of type driver_filter_t to bus_setup_intr() ############################### # grep aha /usr/src/sys/i386/conf/GENERIC device aha # Adaptec 154x SCSI adapters Are you fucking kidding me???!!!!! From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 15:39:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 264EC16A403 for ; Thu, 5 Apr 2007 15:39:45 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id D94F613C45D for ; Thu, 5 Apr 2007 15:39:44 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so720792ana for ; Thu, 05 Apr 2007 08:39:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DI9Mcteeg85J5XMAPWIicnn1JJKm8k/RSk9B1JvuskRimiiwiBVUF6Tcu4yxYjz+q32w+ZVnERPaN/uA9OuPDfStP5PYwRY1tv89he02+g4lov3My+1Fgnxg3QwKj7kuSfAOnk8+he6CjbiBuJoBZqqUiti98Bo6bo/KychV9T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A6zRDN4hAhn2VYixLnLh6ei/UXY45bmbmUz/eLPdER25wMZI5N/c8Tvg1TnHZaSyc/N4PmpfFO36rP8Vky5e3XWc6RjJFZWBZDi+3RY2V3eFrzfb6UAsnyo+JV7POpkvnMPSEKj7bmyNF6q0GhQcMNhmltCuAIcaPlssbh4ErpY= Received: by 10.100.121.12 with SMTP id t12mr1396526anc.1175787581697; Thu, 05 Apr 2007 08:39:41 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Thu, 5 Apr 2007 08:39:41 -0700 (PDT) Message-ID: Date: Thu, 5 Apr 2007 10:39:41 -0500 From: "Nikolas Britton" To: "Peter Jeremy" In-Reply-To: <20070405103708.GC842@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> X-Mailman-Approved-At: Thu, 05 Apr 2007 17:47:29 +0000 Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 15:39:45 -0000 On 4/5/07, Peter Jeremy wrote: > [-stable removed since it's not relevant there] > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: > >Can anything in the list below be removed from CURRENT? > > > >legacyfree1# cd dev/ > >legacyfree1# grep -irsn isa ./ | grep -i include > ... > >legacyfree1# grep -irsn mca ./ | grep -i include > ... > > Why do you believe anything in the list might need to be removed? > I'd like to also add that 6-STABLE should be the last branch to support: 1. ISA / EISA 2. PC98 Platform. 3. i486 4. i586 98.83% of us have at least a i686 and 62.6% of us have at least a i786 (SSE2) processor. Arch Break Down i386 5586 94.02% amd64 305 5.13% sparc64 30 0.50% x86 Break Down: i486 30 0.074% ??? 51 0.125% i586 404 0.995% i686 14724 36.230% i786 25431 62.576% ----------------------------------- Tot: 40640 100% data provided by bsdstats.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:53:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A90E616A401 for ; Thu, 5 Apr 2007 17:53:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9617D13C455 for ; Thu, 5 Apr 2007 17:53:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 7619C1A4D8D; Thu, 5 Apr 2007 10:53:29 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DCDD8514C3; Thu, 5 Apr 2007 13:53:28 -0400 (EDT) Date: Thu, 5 Apr 2007 13:53:28 -0400 From: Kris Kennaway To: Nikolas Britton Message-ID: <20070405175328.GA8380@xor.obsecurity.org> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:53:29 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 10:39:41AM -0500, Nikolas Britton wrote: > On 4/5/07, Peter Jeremy wrote: > >[-stable removed since it's not relevant there] > > > >On 2007-Apr-05 04:58:17 -0500, Nikolas Britton =20 > >wrote: > >>Can anything in the list below be removed from CURRENT? > >> > >>legacyfree1# cd dev/ > >>legacyfree1# grep -irsn isa ./ | grep -i include > >... > >>legacyfree1# grep -irsn mca ./ | grep -i include > >... > > > >Why do you believe anything in the list might need to be removed? > > >=20 > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA > 2. PC98 Platform. > 3. i486 > 4. i586 Thanks for your input. Kris --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFTeYWry0BWjoQKURAtmzAKCu7OIusVtNWEL/cvojOrn3RvVLwQCeL6RB yh2WjS2IXWlqu9PFvktnOtY= =CPPM -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 17:56:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B00316A404 for ; Thu, 5 Apr 2007 17:56:36 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id EFFDF13C4BB for ; Thu, 5 Apr 2007 17:56:35 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so775590ana for ; Thu, 05 Apr 2007 10:56:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=de4WlztFOb9JuV6QXe74aG9uuunzawoB9CLD4PBlMrFSBwJmdrPHjYU9UHkfUVYEoOgc2jGwDz8AyvApn7SeFRGb8qSJl97jriaDDxa0S6BAG8WwYgFTI8hh1gYCciBjQlRfka1XlWeDx/OPDQeR9WTD7tWas8CdvL72z2f7+wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N1pOY8Wl69nIiZxBUwvPuuKg5kCGgEEvOKRoEma08Vub9moHW4KZlCP8tkZOoKBQhLe3OvaxnyTUMjE4us11j0mL6I/Iw00OxxvUeQwjk1a74c1OqbSZDgAl7jrm0tWa3Ht1BrTFY3tGfq9jyVutn0ueE1tEJ5FIRLJxtGY3c30= Received: by 10.100.31.2 with SMTP id e2mr1505921ane.1175795795244; Thu, 05 Apr 2007 10:56:35 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Thu, 5 Apr 2007 10:56:35 -0700 (PDT) Message-ID: Date: Thu, 5 Apr 2007 12:56:35 -0500 From: "Nikolas Britton" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86zm5nrllc.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86zm5nrllc.fsf@dwp.des.no> Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 17:56:36 -0000 On 4/5/07, Dag-Erling Sm=F8rgrav wrote: > "Nikolas Britton" writes: > > Can anything in the list below be removed from CURRENT? > > No. Modern i386 and amd64 still have an ISA bus, and devices > connected to that bus, even if they don't have ISA slots. > What you speak of is the LPC bus. LPC is intended to be a motherboard-only bus. No connector is defined, and no LPC peripheral daughterboards are available. So I come back to the question of why we have external devices from 1987 still floating around in the kernel and more importantly why these devices are enabled by default in the GENERIC kern conf? http://www.intel.com/design/chipsets/industry/25128901.pdf From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:12:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4BCC16A402 for ; Thu, 5 Apr 2007 18:12:30 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7639513C459 for ; Thu, 5 Apr 2007 18:12:30 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZWRJ-0007EP-68; Thu, 05 Apr 2007 14:12:05 -0400 Message-ID: <46153C79.4050404@metricsystems.com> Date: Thu, 05 Apr 2007 11:14:17 -0700 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Nikolas Britton References: <20070405103708.GC842@turion.vk2pj.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:12:30 -0000 Nikolas Britton schrieb: > On 4/5/07, Peter Jeremy wrote: >> [-stable removed since it's not relevant there] >> >> On 2007-Apr-05 04:58:17 -0500, Nikolas Britton >> wrote: >> >Can anything in the list below be removed from CURRENT? >> > >> >legacyfree1# cd dev/ >> >legacyfree1# grep -irsn isa ./ | grep -i include >> ... >> >legacyfree1# grep -irsn mca ./ | grep -i include >> ... >> >> Why do you believe anything in the list might need to be removed? >> > > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA > 2. PC98 Platform. > 3. i486 > 4. i586 > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > (SSE2) processor. > > Arch Break Down > i386 5586 94.02% > amd64 305 5.13% > sparc64 30 0.50% > > x86 Break Down: > i486 30 0.074% > ??? 51 0.125% > i586 404 0.995% > i686 14724 36.230% > i786 25431 62.576% > ----------------------------------- > Tot: 40640 100% Where to varients figure in, such as Celerons, or non-Intel processor manufacturers such as VIA Tech. I had a problem a while ago on bringing up a VIA Tech processor with NetBSD because the generic compiler emitted some illegal opcodes for that processor, but when one dropped back to say a i486 level, the compiler didn't emit such, and 'all was well'... After a system has been installed, then go for the specific target processor. But for the 'boot on anything' the lowest common architecture should be the base. (I've had some AMD K6's in my house networking environment for almost 7-8 years... but for routers, dhcp, firewall service there's no point in putting a 'latest and greatest' in. In my 'embedded' world, there is also a tendency to use older architectures, albeit with low power, or a number of integrated peripherals, etc. that, like the VIA cpu that don't quite fit into the later architectures. John Clark. From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:18:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 614D816A406 for ; Thu, 5 Apr 2007 18:18:37 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3B413C45B for ; Thu, 5 Apr 2007 18:18:37 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:60867 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with smtp (Exim 4.63) (envelope-from ) id 1HZWXc-0001co-3k for freebsd-current@freebsd.org; Thu, 05 Apr 2007 20:18:36 +0200 Received: (qmail 95913 invoked from network); 5 Apr 2007 20:18:33 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 5 Apr 2007 20:18:33 +0200 Received: (qmail 60690 invoked by uid 1001); 5 Apr 2007 20:18:33 +0200 Date: Thu, 5 Apr 2007 20:18:33 +0200 From: Erik Trulsson To: Nikolas Britton Message-ID: <20070405181833.GA60674@owl.midgard.homeip.net> Mail-Followup-To: Nikolas Britton , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , FreeBSD Current References: <86zm5nrllc.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1HZWXc-0001co-3k. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HZWXc-0001co-3k 7d2bfbf94056d3d6cd00c8f8964340c7 Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:18:37 -0000 On Thu, Apr 05, 2007 at 12:56:35PM -0500, Nikolas Britton wrote: > On 4/5/07, Dag-Erling Sm=F8rgrav wrote: > >"Nikolas Britton" writes: > >> Can anything in the list below be removed from CURRENT? > > > >No. Modern i386 and amd64 still have an ISA bus, and devices > >connected to that bus, even if they don't have ISA slots. > > >=20 > What you speak of is the LPC bus. LPC is intended to be a > motherboard-only bus. No connector is defined, and no LPC peripheral > daughterboards are available. But from the software's viewpoint it looks like an ISA-bus. >=20 > So I come back to the question of why we have external devices from > 1987 still floating around in the kernel and more importantly why > these devices are enabled by default in the GENERIC kern conf? Beacuse many of them are still perfectly usable presumably. (And because there are a number of persons who do run FreeBSD on older systems that might have those devices.) --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:18:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DA4A16A40A for ; Thu, 5 Apr 2007 18:18:43 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD1613C455 for ; Thu, 5 Apr 2007 18:18:43 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:54801 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with smtp (Exim 4.63) (envelope-from ) id 1HZWMb-0007HK-5r for freebsd-current@freebsd.org; Thu, 05 Apr 2007 20:07:15 +0200 Received: (qmail 95785 invoked from network); 5 Apr 2007 20:07:11 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 5 Apr 2007 20:07:11 +0200 Received: (qmail 60582 invoked by uid 1001); 5 Apr 2007 20:07:11 +0200 Date: Thu, 5 Apr 2007 20:07:11 +0200 From: Erik Trulsson To: Nikolas Britton Message-ID: <20070405180711.GA60539@owl.midgard.homeip.net> Mail-Followup-To: Nikolas Britton , Peter Jeremy , FreeBSD Current References: <20070405103708.GC842@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1HZWMb-0007HK-5r. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HZWMb-0007HK-5r 1c752fbc62481fde2c426f4a32b55558 Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:18:43 -0000 On Thu, Apr 05, 2007 at 10:39:41AM -0500, Nikolas Britton wrote: > On 4/5/07, Peter Jeremy wrote: > >[-stable removed since it's not relevant there] > > > >On 2007-Apr-05 04:58:17 -0500, Nikolas Britton > >wrote: > >>Can anything in the list below be removed from CURRENT? > >> > >>legacyfree1# cd dev/ > >>legacyfree1# grep -irsn isa ./ | grep -i include > >... > >>legacyfree1# grep -irsn mca ./ | grep -i include > >... > > > >Why do you believe anything in the list might need to be removed? > > > > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA > 2. PC98 Platform. > 3. i486 > 4. i586 I strongly disagree. There is no good reason to drop support for those. (Or if there is nobody has explained it yet.) > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > (SSE2) processor. And 73.45% of all statistics are mainly made up of hot air. > > Arch Break Down > i386 5586 94.02% > amd64 305 5.13% > sparc64 30 0.50% > > x86 Break Down: > i486 30 0.074% > ??? 51 0.125% > i586 404 0.995% > i686 14724 36.230% > i786 25431 62.576% > ----------------------------------- > Tot: 40640 100% > > data provided by bsdstats.org What makes you think those stats are even half-way accurate or useful. It is probably a highly biased sample. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:26:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 460E816A407 for ; Thu, 5 Apr 2007 18:26:53 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0214113C4BB for ; Thu, 5 Apr 2007 18:26:52 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:57657 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.63) (envelope-from ) id 1HZWPw-0005v9-6q for freebsd-current@freebsd.org; Thu, 05 Apr 2007 20:10:40 +0200 Received: (qmail 95799 invoked from network); 5 Apr 2007 20:10:37 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 5 Apr 2007 20:10:37 +0200 Received: (qmail 60604 invoked by uid 1001); 5 Apr 2007 20:10:37 +0200 Date: Thu, 5 Apr 2007 20:10:37 +0200 From: Erik Trulsson To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070405181037.GA60588@owl.midgard.homeip.net> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Nikolas Britton , FreeBSD Current References: <86zm5nrllc.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <86zm5nrllc.fsf@dwp.des.no> User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1HZWPw-0005v9-6q. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1HZWPw-0005v9-6q 1527bad99377b9bab5831a11bea03f36 Cc: FreeBSD Current , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:26:53 -0000 On Thu, Apr 05, 2007 at 03:34:39PM +0200, Dag-Erling Sm=F8rgrav wrote: > "Nikolas Britton" writes: > > Can anything in the list below be removed from CURRENT? >=20 > No. Modern i386 and amd64 still have an ISA bus, and devices > connected to that bus, even if they don't have ISA slots. And even if that was not the case there are still lots of not-quite-as-modern i386 systems that are perfectly suitable for running FreeBSD 7.x that *do* have ISA-slots. (ISA-slots were still often included on motherboards as late as the Pentium III/AMD Athlon era.) --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:29:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45E8D16A401 for ; Thu, 5 Apr 2007 18:29:46 +0000 (UTC) (envelope-from granted14@yahoo.com) Received: from web55611.mail.re4.yahoo.com (web55611.mail.re4.yahoo.com [206.190.58.235]) by mx1.freebsd.org (Postfix) with SMTP id D43FB13C48C for ; Thu, 5 Apr 2007 18:29:45 +0000 (UTC) (envelope-from granted14@yahoo.com) Received: (qmail 13663 invoked by uid 60001); 5 Apr 2007 18:03:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=aArEd3kXkfORrv7A+SQriXFo6tlGePZs6bl3MV1I/zvNZTBmNTqWs+L3g/2E+4XA2pt6+gRNwKYT8yWQ4zD8yZy9pIz2CqN+LWiJNcnUsIx53bectomAXeLzxKtQeDPJDYRr9aCaQKqcJ8fDkGaJUwyydy9AbMSGk4eoZxFx01M=; X-YMail-OSG: r.mQ4sAVM1nWwqtF1S1AoeqIT3doOzpuvc08DxWcHjE_DqxHjYZaFZ6AGLb6Mfq7iGsAUxfjGc_p7SI1OAxLf2_4EGPtU6.5Iv0TZvOl.PoMR8Lou37GHMj3Z9UEXw-- Received: from [70.83.210.124] by web55611.mail.re4.yahoo.com via HTTP; Thu, 05 Apr 2007 14:03:03 EDT Date: Thu, 5 Apr 2007 14:03:03 -0400 (EDT) From: Etienne Robillard To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <108124.13599.qm@web55611.mail.re4.yahoo.com> Subject: snd_emu10k1 wont work without explicit reloading w/ acpi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:29:46 -0000 Hi all, I would like to report a small problem when playing around with the acpi stack on 7.0-CURRENT. If the acpi module is loaded, then the snd_emu10k1 module wont work without getting unloaded and reloaded back using kldload. In my /boot/loader.conf there is: snd_emu10k1_load="YES" Dmesg is available here: http://frutz.dnsdojo.net:8080/media/docs/dmesg.txt Is this a known issue ? Thanks in advance, Etienne ---- Etienne Robillard 7680 de jouvence, La Plaine J7M-2K9, Québec Telephone: 450-478-5026 Yahoo Messenger ID: granted14 Skype ID: incidah __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:40:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B2B916A405 for ; Thu, 5 Apr 2007 18:40:49 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE4613C455 for ; Thu, 5 Apr 2007 18:40:48 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l35IM4DQ054160; Thu, 5 Apr 2007 20:22:04 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l35ILvQd073826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 20:21:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l35ILuAM010145; Thu, 5 Apr 2007 20:21:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l35ILuAL010144; Thu, 5 Apr 2007 20:21:56 +0200 (CEST) (envelope-from ticso) Date: Thu, 5 Apr 2007 20:21:56 +0200 From: Bernd Walter To: Nikolas Britton Message-ID: <20070405182155.GJ8831@cicely12.cicely.de> References: <86zm5nrllc.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:40:49 -0000 On Thu, Apr 05, 2007 at 12:56:35PM -0500, Nikolas Britton wrote: > On 4/5/07, Dag-Erling Smørgrav wrote: > >"Nikolas Britton" writes: > >> Can anything in the list below be removed from CURRENT? > > > >No. Modern i386 and amd64 still have an ISA bus, and devices > >connected to that bus, even if they don't have ISA slots. > > > > What you speak of is the LPC bus. LPC is intended to be a > motherboard-only bus. No connector is defined, and no LPC peripheral > daughterboards are available. LPC is more or less ISA, just reduced to the features the vendors need onboard. So you still need ISA logic for your realtime clock, your PS/2 keyboard, etc... Old doesn't mean useless - PC104, which basicly ISA with different header, are still sold for a good reason. Lot of people with special hardware are still required to run those equipment, because it is not easily replaceable. E.g. blind people still have the requirement to use real ISA cards for their braile equipment, which is quite expensive and not to be wasted easily. > So I come back to the question of why we have external devices from > 1987 still floating around in the kernel and more importantly why > these devices are enabled by default in the GENERIC kern conf? Because people with such hardware need it more than those with fast hardware, for which it won't hurt to recompile a kernel or just live with a few unused bytes - an unused meg won't hurt on a 1G box. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 18:51:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C6EB16A405 for ; Thu, 5 Apr 2007 18:51:20 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id D2C9F13C469 for ; Thu, 5 Apr 2007 18:51:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from localhost (jn@ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id l35IGQfW015731; Thu, 5 Apr 2007 14:16:26 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Thu, 5 Apr 2007 14:15:21 -0400 User-Agent: KMail/1.9.6 References: <20070405103708.GC842@turion.vk2pj.dyndns.org> In-Reply-To: X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704051415.21905.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 18:51:20 -0000 On Thursday 05 April 2007 11:39:41 am Nikolas Britton wrote: > On 4/5/07, Peter Jeremy wrote: > > [-stable removed since it's not relevant there] > > > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: > > >Can anything in the list below be removed from CURRENT? > > > > > >legacyfree1# cd dev/ > > >legacyfree1# grep -irsn isa ./ | grep -i include > > > > ... > > > > >legacyfree1# grep -irsn mca ./ | grep -i include > > > > ... > > > > Why do you believe anything in the list might need to be removed? > > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA > 2. PC98 Platform. > 3. i486 > 4. i586 > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > (SSE2) processor. > > Arch Break Down > i386 5586 94.02% > amd64 305 5.13% > sparc64 30 0.50% > > x86 Break Down: > i486 30 0.074% > ??? 51 0.125% > i586 404 0.995% > i686 14724 36.230% > i786 25431 62.576% > ----------------------------------- > Tot: 40640 100% > > data provided by bsdstats.org Age alone is a lousy reason to drop support for any given piece of hardware. In fact, I consider the fact that it will install & run on whatever secondhand hardware you might happen to run across to be a major selling point of FreeBSD. As long as it's inclusion doesn't hamper advancements in other areas and there is someone to maintain it, support for more hardware new or old is always a good thing IMO. If you don't want to use it, take it out of your kernel config. The point of GENERIC is to cover as many different hardware setups as is reasonable, with emphasis on storage and network devices (without which it's difficult if not impossible to bootstrap or update a system). If you don't want to use the support then build a custom kernel without it. (But you don't lose much by leaving it alone.) The numbers on bsdstats.org, while useful in demonstrating that there are _at least_ a given number of machines using certain hardware, should probably not be relied upon at this point for any other conclusions, especially regarding the (unknown but certainly a majority) portion of machines that are not represented. In any case, patches speak louder than words. If you wanted to work on producing a highly functional legacy-free kernel tree (which maybe you are, for your unspecified new architecture mentioned in another thread), I'm sure that your work would not be ill-received. JN From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 19:27:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 088B916A403 for ; Thu, 5 Apr 2007 19:27:05 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a20.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by mx1.freebsd.org (Postfix) with ESMTP id EB8AD13C48A for ; Thu, 5 Apr 2007 19:27:04 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.28.27]) by spunkymail-a20.g.dreamhost.com (Postfix) with ESMTP id 65F0FFE373; Thu, 5 Apr 2007 12:27:03 -0700 (PDT) Date: Thu, 5 Apr 2007 16:26:58 -0300 From: Ricardo Nabinger Sanchez To: "Nikolas Britton" Message-Id: <20070405162658.a484d796.rnsanchez@wait4.org> In-Reply-To: References: <20070405103708.GC842@turion.vk2pj.dyndns.org> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.4.0beta6 (GTK+ 2.10.9; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 19:27:05 -0000 On Thu, 5 Apr 2007 08:17:34 -0500 "Nikolas Britton" wrote: > # grep aha /usr/src/sys/i386/conf/GENERIC > device aha # Adaptec 154x SCSI adapters > > > Are you fucking kidding me???!!!!! Comment it out and recompile. Or don't kldload it. I don't get your point. What are the benefits of mass-dropping support for old hardware (considering that some drivers _are_ being removed, due to lack of maintainers, interest, users, ...)? Don't forget that today's cheap appliances are very low end, and there is already people porting FreeBSD to some of them. Others just can't buy expensive hardware (yeah, i686 processors are cheap today, but you need more than just a processor to make it useful). No offense, but this kind of "I don't like it--delete it!" argument does not make any sense. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 19:49:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18D1016A402 for ; Thu, 5 Apr 2007 19:49:22 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id ACE4613C487 for ; Thu, 5 Apr 2007 19:49:21 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l35JnCBR083991; Thu, 5 Apr 2007 13:49:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <461552AD.80502@samsco.org> Date: Thu, 05 Apr 2007 13:49:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Nikolas Britton References: <20070405103708.GC842@turion.vk2pj.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 05 Apr 2007 13:49:13 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 19:49:22 -0000 Nikolas Britton wrote: > On 4/5/07, Peter Jeremy wrote: >> [-stable removed since it's not relevant there] >> >> On 2007-Apr-05 04:58:17 -0500, Nikolas Britton >> wrote: >> >Can anything in the list below be removed from CURRENT? >> > >> >legacyfree1# cd dev/ >> >legacyfree1# grep -irsn isa ./ | grep -i include >> ... >> >legacyfree1# grep -irsn mca ./ | grep -i include >> ... >> >> Why do you believe anything in the list might need to be removed? >> > > Because it's junk that doesn't belong, and can't even be use, in a > modern operating system. For some perspective... > > Apple Mac Pro: > 8-way 3.0GHz Intel Xeon ( 24 GHz ) > 16GB System RAM > NVIDIA Quadro FX 4500 512MB > > Now for some contrast, the AHA-1542: > Supported Operating Systems: MS-DOS 3.x, 4.x, 5.x > Number of devices: Up to 7 devices under DOS 5.0 > Bus System Interface Type: ISA > Hard Disk Capacity: Up to 8 GBytes per disk > Floppy Drive Support: Supports two 5.25 in. floppy drives > Release Date: 1987 > Status: Discontinued > > CVS Log: > ############################### > Revision 1.33: Jan 2005 (2 years, 2 months ago) by imp > > Final attempt to make aha 1542A working. If not, oh well, I don't > have the card and no way to reproduce problems. We do this by > applying the workaround to firmware revsion 0. > ############################### > Revision 1.39: Feb 2007 (5 weeks, 6 days ago) by piso > > break newbus api: add a new argument of type driver_filter_t to > bus_setup_intr() > ############################### > > > # grep aha /usr/src/sys/i386/conf/GENERIC > device aha # Adaptec 154x SCSI adapters > > > Are you fucking kidding me???!!!!! Stop being an elitist twit. Thanks. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 19:54:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61E3216A416; Thu, 5 Apr 2007 19:54:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 331D213C4D1; Thu, 5 Apr 2007 19:54:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35Jr7rd085841; Thu, 5 Apr 2007 13:53:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 13:53:06 -0600 (MDT) Message-Id: <20070405.135306.78791677.imp@bsdimp.com> To: nikolas.britton@gmail.com From: Warner Losh In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 13:53:07 -0600 (MDT) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 19:54:30 -0000 > legacyfree1# grep -irsn isa ./ | grep -i include >From the system: no. From your kernel, absolutely. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 19:57:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4557216A404; Thu, 5 Apr 2007 19:57:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8000313C468; Thu, 5 Apr 2007 19:57:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35JtRro085879; Thu, 5 Apr 2007 13:55:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 13:55:27 -0600 (MDT) Message-Id: <20070405.135527.112538812.imp@bsdimp.com> To: des@des.no From: Warner Losh In-Reply-To: <86zm5nrllc.fsf@dwp.des.no> References: <86zm5nrllc.fsf@dwp.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 13:55:29 -0600 (MDT) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, nikolas.britton@gmail.com Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 19:57:26 -0000 Des writes: > "Nikolas Britton" writes: > > Can anything in the list below be removed from CURRENT? > > No. Modern i386 and amd64 still have an ISA bus, and devices > connected to that bus, even if they don't have ISA slots. The isa bus also is the catch-all on board I/O bus for i386/amd64. This usage is traditional as there rarely were add-in keyboard controllers, for example. Also, while LPC has replaced ISA as a physical connection technology in many cases, it still has a the same software interface. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 20:00:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E892916A401 for ; Thu, 5 Apr 2007 20:00:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 95B0E13C45A for ; Thu, 5 Apr 2007 20:00:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35JxOue085918; Thu, 5 Apr 2007 13:59:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 13:59:24 -0600 (MDT) Message-Id: <20070405.135924.85327487.imp@bsdimp.com> To: nikolas.britton@gmail.com From: Warner Losh In-Reply-To: References: <20070405103708.GC842@turion.vk2pj.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 13:59:25 -0600 (MDT) Cc: peterjeremy@optushome.com.au, freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 20:00:07 -0000 > Revision 1.33: Jan 2005 (2 years, 2 months ago) by imp > > Final attempt to make aha 1542A working. If not, oh well, I don't > have the card and no way to reproduce problems. We do this by > applying the workaround to firmware revsion 0. But all the other 1542 cards I have work just fine (A is a really really old and somewhat rare version of the 1542 card). After I made this commit, people gave me a card, but I've not had a chance to try it out. As to your characterization that it is junk, you are just flat out wrong. There's no other way to say it. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 20:03:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E28016A403 for ; Thu, 5 Apr 2007 20:03:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D56AA13C484 for ; Thu, 5 Apr 2007 20:03:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35K1olJ085951; Thu, 5 Apr 2007 14:01:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 14:01:50 -0600 (MDT) Message-Id: <20070405.140150.59738522.imp@bsdimp.com> To: nikolas.britton@gmail.com From: Warner Losh In-Reply-To: References: <86zm5nrllc.fsf@dwp.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 14:01:51 -0600 (MDT) Cc: des@des.no, freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 20:03:25 -0000 > So I come back to the question of why we have external devices from > 1987 still floating around in the kernel and more importantly why > these devices are enabled by default in the GENERIC kern conf? Because they work and are necessary. If you don't know that, I'll echo Kris' "Thank you for the input" and be done with it. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 20:03:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B34CF16A402 for ; Thu, 5 Apr 2007 20:03:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA5613C44B for ; Thu, 5 Apr 2007 20:03:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l35K19UO085950; Thu, 5 Apr 2007 14:01:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Apr 2007 14:01:09 -0600 (MDT) Message-Id: <20070405.140109.39240822.imp@bsdimp.com> To: nikolas.britton@gmail.com From: Warner Losh In-Reply-To: References: <20070405103708.GC842@turion.vk2pj.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 05 Apr 2007 14:01:09 -0600 (MDT) Cc: peterjeremy@optushome.com.au, freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 20:03:27 -0000 From: "Nikolas Britton" Subject: Re: Do we need this junk? Date: Thu, 5 Apr 2007 10:39:41 -0500 > On 4/5/07, Peter Jeremy wrote: > > [-stable removed since it's not relevant there] > > > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: > > >Can anything in the list below be removed from CURRENT? > > > > > >legacyfree1# cd dev/ > > >legacyfree1# grep -irsn isa ./ | grep -i include > > ... > > >legacyfree1# grep -irsn mca ./ | grep -i include > > ... > > > > Why do you believe anything in the list might need to be removed? > > > > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA Not going to happen. Maybe EISA, but certainly not ISA, as machines made today still need it. > 2. PC98 Platform. What do you care? I mean really, what do you care here. There are Pentium II class machines that are perfectly good in this class of machines. I have one and it runs just fine. > 3. i486 So you want to kill all the soekris boxes? Sorry, not going to happen. > 4. i586 These machines still work, and are still popular in the embedded space due to their lower power consumption. Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 20:08:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95EDD16A404 for ; Thu, 5 Apr 2007 20:08:52 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 8243713C46A for ; Thu, 5 Apr 2007 20:08:52 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id B980E11143; Thu, 5 Apr 2007 14:49:32 -0500 (CDT) Date: Thu, 5 Apr 2007 14:49:30 -0500 From: Craig Boston To: Nikolas Britton Message-ID: <20070405194930.GC72219@nowhere> Mail-Followup-To: Craig Boston , Nikolas Britton , Dag-Erling Sm?rgrav , FreeBSD Current References: <86zm5nrllc.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Dag-Erling Sm?rgrav , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 20:08:52 -0000 On Thu, Apr 05, 2007 at 12:56:35PM -0500, Nikolas Britton wrote: > What you speak of is the LPC bus. LPC is intended to be a > motherboard-only bus. No connector is defined, and no LPC peripheral > daughterboards are available. > > So I come back to the question of why we have external devices from > 1987 still floating around in the kernel and more importantly why > these devices are enabled by default in the GENERIC kern conf? Don't forget about PCCard. There are still quite a few 16-bit PCCard devices floating around, especially modems. PCCard is basically ISA + some PnP magic. There are standards looming that may eventually replace it, but for now even most brand new laptops have it. ep(4) is an (E)ISA only driver, but I keep a 3Com 3CXFE574BT XJack NIC on my shelf because it _ALWAYS WORKS_. It's not fast, but when everything else is broken and you need a network connection, it certainly is handy. Craig From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 20:20:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3597116A404 for ; Thu, 5 Apr 2007 20:20:03 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id BBBE513C458 for ; Thu, 5 Apr 2007 20:20:02 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id l35KJvtF030208; Thu, 5 Apr 2007 22:19:57 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l35KJM7l025429; Thu, 5 Apr 2007 22:19:22 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l35KJMwQ025428; Thu, 5 Apr 2007 22:19:22 +0200 (CEST) (envelope-from wb) Date: Thu, 5 Apr 2007 22:19:22 +0200 From: Wilko Bulte To: Warner Losh Message-ID: <20070405201921.GA25415@freebie.xs4all.nl> References: <86zm5nrllc.fsf@dwp.des.no> <20070405.140150.59738522.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070405.140150.59738522.imp@bsdimp.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: des@des.no, freebsd-current@freebsd.org, nikolas.britton@gmail.com Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 20:20:03 -0000 On Thu, Apr 05, 2007 at 02:01:50PM -0600, Warner Losh wrote.. > > So I come back to the question of why we have external devices from > > 1987 still floating around in the kernel and more importantly why > > these devices are enabled by default in the GENERIC kern conf? > > Because they work and are necessary. If you don't know that, I'll > echo Kris' "Thank you for the input" and be done with it. By far the best answer to this thread-aka-time-sink I have seen sofar. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 21:05:39 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67AE316A403; Thu, 5 Apr 2007 21:05:39 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 12AF413C44C; Thu, 5 Apr 2007 21:05:39 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id 3E386D28F77; Thu, 5 Apr 2007 22:35:10 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id D54AA43466; Thu, 5 Apr 2007 22:35:08 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id A67509D619; Thu, 5 Apr 2007 20:35:04 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 80F28405B; Thu, 5 Apr 2007 22:35:04 +0200 (CEST) Date: Thu, 5 Apr 2007 22:35:04 +0200 From: Jeremie Le Hen To: Maxim Sobolev Message-ID: <20070405203504.GA11297@obiwan.tataz.chchile.org> References: <46128475.9060602@FreeBSD.org> <4613D6F3.4080701@mac.com> <461434A6.3080001@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461434A6.3080001@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Andrew Pantyukhin , FreeBSD Current Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 21:05:39 -0000 Hi, Maxim, Andrew, Chuck, On Wed, Apr 04, 2007 at 04:28:38PM -0700, Maxim Sobolev wrote: > >>Isn't there some safety-net wrapper function that > >>refuses to remove device nodes and maybe some other > >>types of files? > > > >Why not set a filesystem flag like schg on device nodes under a devfs > >tree...? > > Well, I suspect that it may cause ld(1) fail instead. What we want it to > do is to not perform unlink(2) before open(2) when -o argument is device > node. Do you have any idea why ld(1) doesn't merely use open(2) with O_TRUNC, instead of unlinking the file ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 21:28:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4109516A401 for ; Thu, 5 Apr 2007 21:28:57 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0053513C4B0 for ; Thu, 5 Apr 2007 21:28:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 4C3EF211D; Thu, 5 Apr 2007 23:28:53 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3C64C211A; Thu, 5 Apr 2007 23:28:53 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 068E6A10A5; Thu, 5 Apr 2007 23:28:52 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Nikolas Britton" References: <20070405103708.GC842@turion.vk2pj.dyndns.org> Date: Thu, 05 Apr 2007 23:28:52 +0200 In-Reply-To: (Nikolas Britton's message of "Thu, 5 Apr 2007 10:39:41 -0500") Message-ID: <86vegaldd7.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 21:28:57 -0000 "Nikolas Britton" writes: > I'd like to also add that 6-STABLE should be the last branch to > support: [...] I suggest you go write your own operating system and leave us alone. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 21:32:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6E4016A406 for ; Thu, 5 Apr 2007 21:32:55 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF3813C48A for ; Thu, 5 Apr 2007 21:32:55 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 7ADAA2169 for ; Thu, 5 Apr 2007 23:32:51 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 6C7B7211D for ; Thu, 5 Apr 2007 23:32:51 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 4F40BA10A5; Thu, 5 Apr 2007 23:32:51 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: current@freebsd.org Date: Thu, 05 Apr 2007 23:32:51 +0200 Message-ID: <86r6qyld6k.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: NFS panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 21:32:55 -0000 I've been getting a lot of these lately on fresh -CURRENT: | panic: lockmgr: locking against myself | Uptime: 4m34s | Physical memory: 2039 MB | Dumping 269 MB: 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 | | #0 doadump () at pcpu.h:172 | 172 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); | (kgdb) where | #0 doadump () at pcpu.h:172 | During symbol reading, Incomplete CFI data; unspecified registers at 0xc0= 52ff47. | #1 0xc05306be in boot (howto=3D0x104) at /usr/src/sys/kern/kern_shutdown= .c:409 | #2 0xc053018b in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:= 563 | #3 0xc052234b in _lockmgr (lkp=3D0xcfb46388, flags=3D0x3002, interlkp=3D= 0xcfb46388, td=3D0xc5021360, | file=3D0xc845d48a "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs= _serv.c", line=3D0xac9) | at /usr/src/sys/kern/kern_lock.c:448 | #4 0xc05940e2 in vop_stdlock (ap=3D0x0) at /usr/src/sys/kern/vfs_default= .c:266 | #5 0xc06a6e2f in _VOP_LOCK_APV (vop=3D0x0, a=3D0xf45ce860) at vnode_if.c= :1617 | #6 0xc05ab856 in _vn_lock (vp=3D0xcfb46330, flags=3D0x1002, td=3D0xc5021= 360, | file=3D0xc845d48a "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs= _serv.c", line=3D0xac9) | at vnode_if.h:850 | #7 0xc844e3df in nfsrv_symlink (nfsd=3D0xcea6fa00, slp=3D0x0, td=3D0xc50= 21360, mrq=3D0xf45cebfc) | at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_serv.c:2761 | #8 0xc845c0a8 in nfssvc (td=3D0xc5021360, uap=3D0xc823aa80) | at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:477 | #9 0xc06940cf in syscall (frame=3D0xf45ced38) at /usr/src/sys/i386/i386/= trap.c:1008 | #10 0xc067ef10 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:196 | #11 0x00000033 in ?? () | Previous frame inner to this frame (corrupt stack?) Anyone know what's up with that? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 21:34:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C20316A404 for ; Thu, 5 Apr 2007 21:34:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECA513C484 for ; Thu, 5 Apr 2007 21:34:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so463516wra for ; Thu, 05 Apr 2007 14:34:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=h6xvsIaMSvIGBiz4Tc46yh49vJIne8HJogTduIN1tR4XPeBpEbsEDavjOhEGkDc29asZf3+bWA+Pc9P1vj2BEEP9sM/sT+w1PRF5NEceLBOQP1E3pzMSRzcuU1dOlBaYYxqvstWRm8sVvFmHIF6t/lQbR0juFqV8S/hvXcGTvUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=PSh4igqcNLYTM5caGIY2fDSTaWesjXSkJtqy+cMPDZhdZpA9Wl8PWDkAzdWJAlx3GEOj4OzEmN33iHwlcg9GQG4YMTdibImoE/z2fyafxv74W5/bgPiFjk4kBuFPWvDR2Ac8KA0hgGDwJ5qHjrKCmUKjJ3wV3Z8wgrqEAvqaoSE= Received: by 10.115.32.1 with SMTP id k1mr906267waj.1175808858970; Thu, 05 Apr 2007 14:34:18 -0700 (PDT) Received: by 10.114.103.15 with HTTP; Thu, 5 Apr 2007 14:34:13 -0700 (PDT) Message-ID: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> Date: Thu, 5 Apr 2007 14:34:13 -0700 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net , freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Stack panic with em driver unload X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 21:34:20 -0000 Our test group uses a script that does 100 iterations of a module load, then bring up all interfaces, and then unload driver. Depending on the system in anything from just a few iterations to 20 or more, the system will panic. Its doing an em_detach() which calls ether_ifdetach() which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, and finally if_delmulti(). The panic is always happening on a cmpxchgq instruction so I assume its the LOCK macro, whats odd is that its not always the same reason, sometimes one register is 0 so its a page fault trap, but on other iterations its a general protection fault because the register is some big invalid number :) I am hardpressed to see this as a driver problem, but I'm willing to be proven wrong, does someone who knows the stack code better than me have any insights or ideas? It also appears system dependent, I have a couple machines I've tried to reproduce in on and have been unable. I also am told it happens on both amd64 and i386, but it seems easier to reproduce on the former. Lastly, from evidence so far I think this doesnt happen on CURRENT, but the test group hasnt checked that only I have and I dont have as much hardware :) Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 21:54:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8800216A407 for ; Thu, 5 Apr 2007 21:54:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 47B9513C465 for ; Thu, 5 Apr 2007 21:54:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so856611ana for ; Thu, 05 Apr 2007 14:54:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=I+lFoZDpNK9Lq/mjCPs64OZo1QIQ8PX/nkNwdoMIDSOB2aeyA6V8VZxDKJkWALJI6PAMZzMCwe25MAzuCiyVBfi8n4DrOrGf9zbu7k5K+OEFTsYVEjmPSlg/F3Kb7IaY0Zlb6Yr4Mg6nHZFeAkY5/nnHXOEW0Jy/IySgSWy5mJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HtmdQLCGF02tYkgHGY/7HLoi9og2/FrQUmcjRq54fRqu8IgYdT+sw8FC53LY1P6Np8TKl8NX/B8yKKfFZKWeR6/MLBe7niqlgRvTGylMGu9BxB9utXmoX+vA9U92zjyWSj2eWlIZchBQt2nrzA/aNA80iPnTVdnLrIChvfhlU/Q= Received: by 10.100.141.13 with SMTP id o13mr1650998and.1175810087362; Thu, 05 Apr 2007 14:54:47 -0700 (PDT) Received: by 10.100.191.1 with HTTP; Thu, 5 Apr 2007 14:54:47 -0700 (PDT) Message-ID: <3bbf2fe10704051454r6f5b196bi6dd89d3993cf0c1b@mail.gmail.com> Date: Thu, 5 Apr 2007 23:54:47 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "=?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?=" In-Reply-To: <86r6qyld6k.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <86r6qyld6k.fsf@dwp.des.no> X-Google-Sender-Auth: b16a7e25962a7674 Cc: current@freebsd.org Subject: Re: NFS panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 21:54:48 -0000 MjAwNy80LzUsIERhZy1FcmxpbmcgU23DuHJncmF2IDxkZXNAZGVzLm5vPjoKPiBJJ3ZlIGJlZW4g Z2V0dGluZyBhIGxvdCBvZiB0aGVzZSBsYXRlbHkgb24gZnJlc2ggLUNVUlJFTlQ6Cj4KPiB8IHBh bmljOiBsb2NrbWdyOiBsb2NraW5nIGFnYWluc3QgbXlzZWxmCj4gfCBVcHRpbWU6IDRtMzRzCgpb c25pcF0KClRoaXMgYmFzaWNhbGx5IGhhcHBlbnMgd2hlbiBhIGxvY2ttZ3IgaXMgcmVjdXJzZWQg YW5kIGNvbnRlbXBvcmFyeSBub3QKbWFya2VkIGFzIHJlY3Vyc2libGUuCkRvbid0IGtub3cgbXVj aCBvZiBORlMsIGJ1dCBJIGhvcGUgdGhpcyBjYW4gaGVscC4KCkF0dGlsaW8KCgotLSAKUGVhY2Ug Y2FuIG9ubHkgYmUgYWNoaWV2ZWQgYnkgdW5kZXJzdGFuZGluZyAtIEEuIEVpbnN0ZWluCg== From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 22:22:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1C7416A404 for ; Thu, 5 Apr 2007 22:22:29 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from server300.snhdns.com (server300.snhdns.com [204.15.192.210]) by mx1.freebsd.org (Postfix) with ESMTP id B62ED13C459 for ; Thu, 5 Apr 2007 22:22:29 +0000 (UTC) (envelope-from jclark@metricsystems.com) Received: from ip67-89-211-170.z211-89-67.customer.algx.net ([67.89.211.170] helo=[192.168.0.94]) by server300.snhdns.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZaLR-0007D0-3j; Thu, 05 Apr 2007 18:22:17 -0400 Message-ID: <46157721.90707@metricsystems.com> Date: Thu, 05 Apr 2007 15:24:33 -0700 From: John Clark Organization: Metric Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Vladimir Botka References: <46144FC6.3050801@metricsystems.com> <20070405080212.2d7d1c8d@srv> In-Reply-To: <20070405080212.2d7d1c8d@srv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server300.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - metricsystems.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: Strange NFS root booting behavior. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:22:30 -0000 Vladimir Botka schrieb: > > Hello, > > try the script /usr/share/examples/diskless/clone_root to create copy > of the root. The procedure in > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-diskless.html > works for me. Just an idea but did you compile the diskless kernel with > "options BOOTP_NFSROOT" ? Well, I checked, and no those options are there. However, I was able to 'boot' to a working system on one piece of hardware, but not on another. While there could be a hardware problem, the place where it fails is not in a 'hardware intensive' place, such as initing the PCI bus, accessing i/o devices, but just after the initial rc script starts up. I've enabled the debug option in 'rc.initdiskless, and it gets to the point of remounting '/' as read/write. Now of course in a multiple client setup this would not be good, but in a single client, while it may not be the best thing to do, it shouldn't halt the init process and go to the /bin/sh mode... And any attempt to 'ls /', or 'ls /bin' cause a 'bad file descriptor' message. I'm at the moment recompiling the world on the working setup, and have put into a DISKLESS conf file the appropriate options, but I don't think that is the ultimate problem in this case. John Clark. From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 22:30:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B07916A40F; Thu, 5 Apr 2007 22:30:17 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 1051413C4C2; Thu, 5 Apr 2007 22:30:16 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549a4b4d.dip.t-dialin.net [84.154.75.77]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l35MIcGW011148; Fri, 6 Apr 2007 00:18:39 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l35MIVpZ030764; Fri, 6 Apr 2007 00:18:32 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id l35MIVa3092418; Fri, 6 Apr 2007 00:18:31 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200704052218.l35MIVa3092418@fire.jhs.private> To: imp@freebsd.org, piso@freebsd.org In-reply-to: References: <20070405103708.GC842@turion.vk2pj.dyndns.org> Comments: In-reply-to "Nikolas Britton" message dated "Thu, 05 Apr 2007 08:17:34 -0500." Date: Fri, 06 Apr 2007 00:18:31 +0200 From: "Julian H. Stacey" Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:30:17 -0000 imp@freebsd.org, piso@freebsd.org cc: FreeBSD Current I have an (EISA ?) 1742A if any developer needs it for bug chasing. It's a full length card. Maybe it exhibits same problems as a 1542A ? I found it while looking to offer my old 1542A, re below "Nikolas Britton" quoted: > CVS Log: > ############################### > Revision 1.33: Jan 2005 (2 years, 2 months ago) by imp > > Final attempt to make aha 1542A working. If not, oh well, I don't > have the card and no way to reproduce problems. We do this by > applying the workaround to firmware revsion 0. > ############################### > Revision 1.39: Feb 2007 (5 weeks, 6 days ago) by piso > > break newbus api: add a new argument of type driver_filter_t to > bus_setup_intr() > ############################### But I realised I must have long ago given away the 1542A (to a single disc system owner, as a decade back we realised all 1542A had an intermittent data corruption bug on multi disc systems at least on FreeBSD. http://berklix.com/~jhs/hardware/1542a/ That bug did not materialise on 1542B & 1542C ) To counter Nikolas' `stats' argument to abandon much hardware support: None of my 20 or so personal BSD machines are registered, Mine span Athlon back to literaly cpu=386. Numerous with ISA, some with 1542B & C, some with i486 more with i586. There's scanners with FreeBSD embedded inside: http://berklix.com/scanjet/ & http://madole.net/scanjet/ that uses ISA bus Only * 486 not even 586, & work just Fine. There's slow timescale also to qualify military & scientific hardware, which then gets shipped to inacessible places, but can still be upgraded remotely. An ISP I am associated with doesn't bother to report systems to bsdstats or anywhere else, to best of my belief. But he helps promote FreeBSD in his way. Some cast off hardware in western world ends up in eg Africa, where people still try to do useful things with it. Think ecology too: tread lighter, dont force force people to dump & shred hardware. Not everyone's rich, employed on a good salary, in a rich country. Many users we'll never hear from on mail lists, if FreeBSD just works, will suddenly curse FreeBSD over a beer/ coffee to all their friends if some looney decision were to sudedenly abandon all but best newest developer workstations. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Escape Microsoft 20th April 2007: http://berklix.com/free/talk/ Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 22:36:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9333716A401; Thu, 5 Apr 2007 22:36:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC5813C44C; Thu, 5 Apr 2007 22:36:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MawKd045229; Thu, 5 Apr 2007 18:36:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MavM7012272; Thu, 5 Apr 2007 18:36:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B1BF073039; Thu, 5 Apr 2007 18:36:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070405223657.B1BF073039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 18:36:57 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:36:59 -0000 TB --- 2007-04-05 21:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 21:35:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-04-05 21:35:00 - cleaning the object tree TB --- 2007-04-05 21:35:51 - checking out the source tree TB --- 2007-04-05 21:35:51 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-04-05 21:35:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 21:45:38 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 21:45:38 - cd /src TB --- 2007-04-05 21:45:38 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 21:45:39 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c ioctl.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c kdump_subr.c kdump_subr.c: In function `whencename': kdump_subr.c:611: error: `SEEK_DATA' undeclared (first use in this function) kdump_subr.c:611: error: (Each undeclared identifier is reported only once kdump_subr.c:611: error: for each function it appears in.) kdump_subr.c:614: error: `SEEK_HOLE' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-05 22:36:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-05 22:36:57 - ERROR: failed to build world TB --- 2007-04-05 22:36:57 - tinderbox aborted TB --- 0.98 user 3.55 system 3717.08 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 22:37:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1889E16A402; Thu, 5 Apr 2007 22:37:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9C55D13C465; Thu, 5 Apr 2007 22:37:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MbTrU045241; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l35MbTeR012538; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8509073039; Thu, 5 Apr 2007 18:37:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070405223729.8509073039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 18:37:29 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:37:31 -0000 TB --- 2007-04-05 21:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 21:35:00 - starting HEAD tinderbox run for arm/arm TB --- 2007-04-05 21:35:00 - cleaning the object tree TB --- 2007-04-05 21:35:35 - checking out the source tree TB --- 2007-04-05 21:35:35 - cd /tinderbox/HEAD/arm/arm TB --- 2007-04-05 21:35:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 21:45:38 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 21:45:38 - cd /src TB --- 2007-04-05 21:45:38 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 21:45:39 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c ioctl.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -c kdump_subr.c kdump_subr.c: In function `whencename': kdump_subr.c:611: error: `SEEK_DATA' undeclared (first use in this function) kdump_subr.c:611: error: (Each undeclared identifier is reported only once kdump_subr.c:611: error: for each function it appears in.) kdump_subr.c:614: error: `SEEK_HOLE' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-05 22:37:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-05 22:37:29 - ERROR: failed to build world TB --- 2007-04-05 22:37:29 - tinderbox aborted TB --- 0.48 user 1.69 system 3749.19 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 22:48:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E87116A402; Thu, 5 Apr 2007 22:48:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3416F13C46E; Thu, 5 Apr 2007 22:48:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l35Mm2B0084947; Thu, 5 Apr 2007 16:48:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46157C97.8000004@samsco.org> Date: Thu, 05 Apr 2007 16:47:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: "Julian H. Stacey" References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <200704052218.l35MIVa3092418@fire.jhs.private> In-Reply-To: <200704052218.l35MIVa3092418@fire.jhs.private> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 05 Apr 2007 16:48:03 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD Current , imp@freebsd.org, piso@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 22:48:09 -0000 Julian H. Stacey wrote: > imp@freebsd.org, piso@freebsd.org > cc: FreeBSD Current > > I have an (EISA ?) 1742A if any developer needs it for bug chasing. > It's a full length card. Maybe it exhibits same problems as a 1542A ? > I found it while looking to offer my old 1542A, re below > The 1742 and 1542 use completely different chips, IIRC. In any case, Warner is exactly correct that the 1542A was an early rev with unique problems and that it's not representative of the 1542B or C revs. Jeez, how much traffic is the original idiot poster going to make us waste? Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:17:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6DC116A401 for ; Thu, 5 Apr 2007 23:17:12 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from vsmtp2.tin.it (vsmtp2.tin.it [212.216.176.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6595713C459 for ; Thu, 5 Apr 2007 23:17:12 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from rionda.dyndns.org (87.5.186.217) by vsmtp2.tin.it (7.2.072.1) id 460BE0B7009022BE for current@freebsd.org; Fri, 6 Apr 2007 01:17:09 +0200 Received: from rionda.dyndns.org (rionda@localhost [127.0.0.1]) by rionda.dyndns.org (8.13.8/8.13.8) with ESMTP id l35NH8Ze003693 for ; Fri, 6 Apr 2007 01:17:08 +0200 (CEST) (envelope-from matteo@freebsd.org) Received: (from rionda@localhost) by rionda.dyndns.org (8.13.8/8.13.8/Submit) id l35NH79H003692 for current@freebsd.org; Fri, 6 Apr 2007 01:17:07 +0200 (CEST) (envelope-from matteo@freebsd.org) X-Authentication-Warning: rionda.dyndns.org: rionda set sender to matteo@freebsd.org using -f Date: Fri, 6 Apr 2007 01:17:07 +0200 From: Matteo Riondato To: current@freebsd.org Message-ID: <20070405231707.GB1625@kaiser.sig11.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: struct x*pcb size mismatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:17:12 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I rebuild my system with HEAD sources as of today and began experiencing the following problem: [rionda@kaiser][~]> sockstat=20 sockstat: struct xtcpcb size mismatch sockstat: struct xinpcb size mismatch sockstat: struct xunpcb size mismatch sockstat: struct xunpcb size mismatch USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS =20 [rionda@kaiser][~]>=20 Any idea of what can cause this problem? Kernel and world are *not* out of sync: I recompiled both. Thanks Best regards --=20 Matteo Riondato FreeBSD Committer (http://www.freebsd.org) G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFGFYNz2Mp4pR7Fa+wRAj9bAJ0blKX367NF3HPPuyO2m5RAq1n6ywCgln1p GZ5omY2+mpyCCKoz7DI7J7M= =tFQ8 -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:23:44 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F0DF16A403 for ; Thu, 5 Apr 2007 23:23:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id CC01C13C4DD for ; Thu, 5 Apr 2007 23:23:43 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9431E487F7; Fri, 6 Apr 2007 01:23:42 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 928AC456AB; Fri, 6 Apr 2007 01:23:36 +0200 (CEST) Date: Fri, 6 Apr 2007 01:23:32 +0200 From: Pawel Jakub Dawidek To: FreeBSD Tinderbox Message-ID: <20070405232332.GB89034@garage.freebsd.pl> References: <20070405223657.B1BF073039@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: <20070405223657.B1BF073039@freebsd-current.sentex.ca> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:23:44 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 06:36:57PM -0400, FreeBSD Tinderbox wrote: > TB --- 2007-04-05 21:35:00 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2007-04-05 21:35:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2007-04-05 21:35:00 - cleaning the object tree > TB --- 2007-04-05 21:35:51 - checking out the source tree > TB --- 2007-04-05 21:35:51 - cd /tinderbox/HEAD/amd64/amd64 > TB --- 2007-04-05 21:35:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -P= d -A src > TB --- 2007-04-05 21:45:38 - building world (CFLAGS=3D-O2 -pipe) > TB --- 2007-04-05 21:45:38 - cd /src > TB --- 2007-04-05 21:45:38 - /usr/bin/make -B buildworld > >>> World build started on Thu Apr 5 21:45:39 UTC 2007 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/= usr.bin/kdump/../.. -c /src/usr.bin/kdump/kdump.c > cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/= usr.bin/kdump/../.. -c ioctl.c > cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/= usr.bin/kdump/../.. -c kdump_subr.c > kdump_subr.c: In function `whencename': > kdump_subr.c:611: error: `SEEK_DATA' undeclared (first use in this functi= on) > kdump_subr.c:611: error: (Each undeclared identifier is reported only once > kdump_subr.c:611: error: for each function it appears in.) > kdump_subr.c:614: error: `SEEK_HOLE' undeclared (first use in this functi= on) > *** Error code 1 I think this was some race. I committed two files: stdio.h and sys/unistd.h at once, but it seems kdump_subr.c was generated based on new sys/unistd.h, but included old stdio.h. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFYT0ForvXbEpPzQRArRHAJ90gG/E/hmzJM8jRFJ7PgqbPKFxNwCcC1n7 X+tVaq/u8LrwGuv5niUxnl8= =dQvU -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:24:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD38B16A409 for ; Thu, 5 Apr 2007 23:24:41 +0000 (UTC) (envelope-from cavaughan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6614513C459 for ; Thu, 5 Apr 2007 23:24:41 +0000 (UTC) (envelope-from cavaughan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so878076ana for ; Thu, 05 Apr 2007 16:24:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=YYMY5LIPsXXrCI4mIn7JT+Rt70TRLrFNQ+d/bT3jYgP9Ee0YTzdvhnADvLMyIgUSjQglO9kqg5/XTmej1n9oMtORdx3FWFqXTPxcCUeOJHQ1GQKbkTwgqv7X+YY8qlfvgTW4I3aMPXw9Kq06cxwOHha96EZ8ZIjILVGIurnvjV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=pUlNwv9Yn8TKugdFIkdd7OEQs216A0EV78qOG1SrVgbKbj9EwpUmaTgEVMoM4IPIi4YdmIiBs3EMIyldYid+ItvW1262bawWKYzEWJXCPnwq6m4Mtpxd2D5KUYrCI8YVgF84Fny9f1ibGNj3ts9/ldWuvJyYPe2R2c5wI/LdlwE= Received: by 10.114.254.1 with SMTP id b1mr963844wai.1175813832259; Thu, 05 Apr 2007 15:57:12 -0700 (PDT) Received: from ?192.168.2.32? ( [24.19.207.84]) by mx.google.com with ESMTP id a8sm2762441poa.2007.04.05.15.57.11; Thu, 05 Apr 2007 15:57:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2488F872-59CF-48DE-9297-5250B1C6EFB4@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Curtis Vaughan Date: Thu, 5 Apr 2007 15:56:57 -0700 X-Mailer: Apple Mail (2.752.3) Subject: Ports upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:24:41 -0000 So, I wanted to update my ports. I ran: > portsnap fetch update But after running portversion I noticed several ports were still older than the current. So I ran: > portsdb -U After which, nonetheless, portversion shows the same ports as before being older than the current. What am I missing? From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:32:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 858EB16A502 for ; Thu, 5 Apr 2007 23:32:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7338713C45B for ; Thu, 5 Apr 2007 23:32:42 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5BE8A1A4D8E; Thu, 5 Apr 2007 16:32:42 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A081B5154D; Thu, 5 Apr 2007 19:32:41 -0400 (EDT) Date: Thu, 5 Apr 2007 19:32:41 -0400 From: Kris Kennaway To: Curtis Vaughan Message-ID: <20070405233241.GA14504@xor.obsecurity.org> References: <2488F872-59CF-48DE-9297-5250B1C6EFB4@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <2488F872-59CF-48DE-9297-5250B1C6EFB4@gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Ports upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:32:42 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 03:56:57PM -0700, Curtis Vaughan wrote: > So, I wanted to update my ports. > I ran: >=20 > > portsnap fetch update >=20 > But after running portversion I noticed several ports were still older > than the current. > So I ran: >=20 > > portsdb -U >=20 > After which, nonetheless, portversion shows the same ports as before =20 > being > older than the current. >=20 > What am I missing? Dunno, you forgot to show us :) Kris --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFYcZWry0BWjoQKURAkpgAKCkEqqcmQbrWar+KcRkDzGbs2QELgCfXiz8 KcI8WKN25TlkKki3xHF9x/4= =2tS7 -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:50:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70CC116A401; Thu, 5 Apr 2007 23:50:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 37D7D13C43E; Thu, 5 Apr 2007 23:50:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35NoUxC050795; Thu, 5 Apr 2007 19:50:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l35NoUlr058303; Thu, 5 Apr 2007 19:50:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 99EED73039; Thu, 5 Apr 2007 19:50:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070405235030.99EED73039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 19:50:30 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:50:31 -0000 TB --- 2007-04-05 22:37:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 22:37:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-04-05 22:37:29 - cleaning the object tree TB --- 2007-04-05 22:38:02 - checking out the source tree TB --- 2007-04-05 22:38:02 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-04-05 22:38:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 22:46:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 22:46:56 - cd /src TB --- 2007-04-05 22:46:56 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 22:46:58 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Apr 5 23:42:08 UTC 2007 TB --- 2007-04-05 23:42:08 - generating LINT kernel config TB --- 2007-04-05 23:42:08 - cd /src/sys/pc98/conf TB --- 2007-04-05 23:42:08 - /usr/bin/make -B LINT TB --- 2007-04-05 23:42:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-05 23:42:08 - cd /src TB --- 2007-04-05 23:42:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 5 23:42:09 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue iconv_converter_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/iconv_xlat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/iconv_xlat16.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/index.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/inet_ntoa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/libkern/mcount.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/memset.c /src/sys/libkern/memset.c:31: warning: no previous prototype for 'memset' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-05 23:50:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-05 23:50:30 - ERROR: failed to build lint kernel TB --- 2007-04-05 23:50:30 - tinderbox aborted TB --- 0.74 user 2.72 system 4380.76 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 23:52:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CE9C16A403; Thu, 5 Apr 2007 23:52:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E856813C4B0; Thu, 5 Apr 2007 23:52:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35NqQDg050994; Thu, 5 Apr 2007 19:52:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l35NqQYl011218; Thu, 5 Apr 2007 19:52:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 34B6173039; Thu, 5 Apr 2007 19:52:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070405235226.34B6173039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 19:52:26 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2007 23:52:27 -0000 TB --- 2007-04-05 22:36:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 22:36:57 - starting HEAD tinderbox run for i386/i386 TB --- 2007-04-05 22:36:57 - cleaning the object tree TB --- 2007-04-05 22:37:37 - checking out the source tree TB --- 2007-04-05 22:37:37 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-04-05 22:37:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 22:46:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 22:46:56 - cd /src TB --- 2007-04-05 22:46:56 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 22:46:58 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Apr 5 23:42:35 UTC 2007 TB --- 2007-04-05 23:42:35 - generating LINT kernel config TB --- 2007-04-05 23:42:35 - cd /src/sys/i386/conf TB --- 2007-04-05 23:42:35 - /usr/bin/make -B LINT TB --- 2007-04-05 23:42:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-05 23:42:35 - cd /src TB --- 2007-04-05 23:42:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 5 23:42:36 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue iconv_converter_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/iconv_xlat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/iconv_xlat16.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/index.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/inet_ntoa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/libkern/mcount.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/libkern/memset.c /src/sys/libkern/memset.c:31: warning: no previous prototype for 'memset' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-05 23:52:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-05 23:52:26 - ERROR: failed to build lint kernel TB --- 2007-04-05 23:52:26 - tinderbox aborted TB --- 0.88 user 2.78 system 4528.26 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 00:21:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FB9016A403 for ; Fri, 6 Apr 2007 00:21:13 +0000 (UTC) (envelope-from dthomas53@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id C351A13C46A for ; Fri, 6 Apr 2007 00:21:12 +0000 (UTC) (envelope-from dthomas53@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so889031ana for ; Thu, 05 Apr 2007 17:21:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qBipFBOVuzS9ODr8NQFKC1KbC3GlDifGq43iGt6zMO8A0BVWxt5Xif3yvwbUt2/0qorh+4eTJG07DKQmXQZwELdCx/0IMZUZGaScOo36qjGYb8QLI4kiL0qrYADDwbRenNzr/Rj3hjRvABJtmrkZqClAGy3BkXNQyt7M3Em5S5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=phqCK6xV5N+6NRO4ifS159/OsfGVyjWxdtZwIAaDSXtOkg89/qOGQVLpx7wpn+x48SNdF7QZY1tkq5b5p2W9vjKVvKQVfwkJbCWnwnMTLSulrJ7Qsac7xbiqugbFwHdWhSec7jJA4raYvaBUA4CgPNNIe0IjMjusujcRdxt6400= Received: by 10.100.139.9 with SMTP id m9mr1727775and.1175817379198; Thu, 05 Apr 2007 16:56:19 -0700 (PDT) Received: by 10.100.134.1 with HTTP; Thu, 5 Apr 2007 16:56:19 -0700 (PDT) Message-ID: Date: Thu, 5 Apr 2007 19:56:19 -0400 From: "David Stanford" To: "Curtis Vaughan" In-Reply-To: <2488F872-59CF-48DE-9297-5250B1C6EFB4@gmail.com> MIME-Version: 1.0 References: <2488F872-59CF-48DE-9297-5250B1C6EFB4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Ports upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 00:21:13 -0000 > So, I wanted to update my ports. > I ran: > > > portsnap fetch update > > But after running portversion I noticed several ports were still older > than the current. > So I ran: > > > portsdb -U > > After which, nonetheless, portversion shows the same ports as before > being > older than the current. > > What am I missing? I think you may be confusing the purpose of these two utilities. portsnap is used to update your ports tree (/usr/ports directory). 'portsdb -U' will update your ports INDEX. Neither of these actually updates the software you have installed on your system; for that you can try portupgrade (ports-mgmt/portupgrade). -David -- [root@fbsd ~]# fortune Happiness is just an illusion, filled with sadness and confusion. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 01:04:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50CA516A402; Fri, 6 Apr 2007 01:04:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 28D6813C46C; Fri, 6 Apr 2007 01:04:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l3614Fkg055140; Thu, 5 Apr 2007 21:04:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l3614FK3058367; Thu, 5 Apr 2007 21:04:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 23D7C73039; Thu, 5 Apr 2007 21:04:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070406010415.23D7C73039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 21:04:15 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 01:04:16 -0000 TB --- 2007-04-05 23:52:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 23:52:26 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-04-05 23:52:26 - cleaning the object tree TB --- 2007-04-05 23:52:51 - checking out the source tree TB --- 2007-04-05 23:52:51 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-04-05 23:52:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 23:59:54 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 23:59:54 - cd /src TB --- 2007-04-05 23:59:54 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 23:59:56 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 6 00:57:13 UTC 2007 TB --- 2007-04-06 00:57:13 - generating LINT kernel config TB --- 2007-04-06 00:57:13 - cd /src/sys/powerpc/conf TB --- 2007-04-06 00:57:13 - /usr/bin/make -B LINT TB --- 2007-04-06 00:57:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-06 00:57:13 - cd /src TB --- 2007-04-06 00:57:13 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 6 00:57:14 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/iconv.c awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror iconv_converter_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/iconv_xlat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/iconv_xlat16.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/index.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/inet_ntoa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/libkern/memset.c /src/sys/libkern/memset.c:31: warning: no previous prototype for 'memset' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-06 01:04:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-06 01:04:14 - ERROR: failed to build lint kernel TB --- 2007-04-06 01:04:14 - tinderbox aborted TB --- 0.53 user 2.46 system 4308.47 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 01:24:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7E5516A406 for ; Fri, 6 Apr 2007 01:24:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id A702013C483 for ; Fri, 6 Apr 2007 01:24:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 05 Apr 2007 17:54:49 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id C08F3125AF9; Thu, 5 Apr 2007 18:24:52 -0700 (PDT) Message-ID: <4615A164.6010900@elischer.org> Date: Thu, 05 Apr 2007 18:24:52 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Matteo Riondato References: <20070405231707.GB1625@kaiser.sig11.org> In-Reply-To: <20070405231707.GB1625@kaiser.sig11.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: struct x*pcb size mismatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 01:24:53 -0000 Matteo Riondato wrote: > I rebuild my system with HEAD sources as of today and began > experiencing the following problem: > [rionda@kaiser][~]> sockstat > sockstat: struct xtcpcb size mismatch > sockstat: struct xinpcb size mismatch > sockstat: struct xunpcb size mismatch > sockstat: struct xunpcb size mismatch > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN > ADDRESS > [rionda@kaiser][~]> > > > Any idea of what can cause this problem? > Kernel and world are *not* out of sync: I recompiled both. > > Thanks > Best regards Remove some debugging options in your kernel. (or put the same options in /etc/make.conf) and recompile Unfortunately some of the profiling and debugging options change the size of some of the structures.. In particular I think the lock-profiling one changes the size of a mutex which is included everywhere. This is a bug, but don't expect it to be fixed too quickly. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 01:28:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DCE416A406; Fri, 6 Apr 2007 01:28:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C86C913C458; Fri, 6 Apr 2007 01:28:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l361SCtF056567; Thu, 5 Apr 2007 21:28:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l361SClO073102; Thu, 5 Apr 2007 21:28:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F29ED73039; Thu, 5 Apr 2007 21:28:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070406012811.F29ED73039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 21:28:11 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 01:28:13 -0000 TB --- 2007-04-05 23:50:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-05 23:50:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-04-05 23:50:30 - cleaning the object tree TB --- 2007-04-05 23:51:02 - checking out the source tree TB --- 2007-04-05 23:51:02 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-04-05 23:51:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-05 23:59:54 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-05 23:59:54 - cd /src TB --- 2007-04-05 23:59:54 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 5 23:59:56 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 6 01:17:11 UTC 2007 TB --- 2007-04-06 01:17:11 - generating LINT kernel config TB --- 2007-04-06 01:17:11 - cd /src/sys/ia64/conf TB --- 2007-04-06 01:17:11 - /usr/bin/make -B LINT TB --- 2007-04-06 01:17:11 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-06 01:17:11 - cd /src TB --- 2007-04-06 01:17:11 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 6 01:17:12 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/iconv.c awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror iconv_converter_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/iconv_xlat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/iconv_xlat16.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/index.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/inet_ntoa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/libkern/memset.c /src/sys/libkern/memset.c:31: warning: no previous prototype for 'memset' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-06 01:28:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-06 01:28:11 - ERROR: failed to build lint kernel TB --- 2007-04-06 01:28:11 - tinderbox aborted TB --- 0.74 user 2.65 system 5860.97 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 01:58:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B0C216A403 for ; Fri, 6 Apr 2007 01:58:18 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4806613C45E for ; Fri, 6 Apr 2007 01:58:18 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l361wH5u020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Apr 2007 18:58:17 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l361wHAt019699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Apr 2007 18:58:17 -0700 Message-ID: <4615A924.4080108@u.washington.edu> Date: Thu, 05 Apr 2007 18:57:56 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070405103708.GC842@turion.vk2pj.dyndns.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.5.184834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __USER_AGENT 0' Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 01:58:18 -0000 Nikolas Britton wrote: > On 4/5/07, Peter Jeremy wrote: >> [-stable removed since it's not relevant there] >> >> On 2007-Apr-05 04:58:17 -0500, Nikolas Britton >> wrote: >> >Can anything in the list below be removed from CURRENT? >> > >> >legacyfree1# cd dev/ >> >legacyfree1# grep -irsn isa ./ | grep -i include >> ... >> >legacyfree1# grep -irsn mca ./ | grep -i include >> ... >> >> Why do you believe anything in the list might need to be removed? >> > > I'd like to also add that 6-STABLE should be the last branch to support: > 1. ISA / EISA > 2. PC98 Platform. > 3. i486 > 4. i586 > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > (SSE2) processor. > > Arch Break Down > i386 5586 94.02% > amd64 305 5.13% > sparc64 30 0.50% > > x86 Break Down: > i486 30 0.074% > ??? 51 0.125% > i586 404 0.995% > i686 14724 36.230% > i786 25431 62.576% > ----------------------------------- > Tot: 40640 100% > > data provided by bsdstats.org Bad idea. A lot of routers using pfsense are running a modified version of FreeBSD 6.2, and are typically running Soekris hardware, which is i586 branded hardware. -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 02:21:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4EB116A401; Fri, 6 Apr 2007 02:21:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 757FE13C455; Fri, 6 Apr 2007 02:21:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l362LfE3059312; Thu, 5 Apr 2007 22:21:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l362LfV6052392; Thu, 5 Apr 2007 22:21:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B19E473039; Thu, 5 Apr 2007 22:21:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070406022141.B19E473039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 22:21:41 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 02:21:42 -0000 TB --- 2007-04-06 01:04:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-06 01:04:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-04-06 01:04:15 - cleaning the object tree TB --- 2007-04-06 01:04:57 - checking out the source tree TB --- 2007-04-06 01:04:57 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-04-06 01:04:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-06 01:13:20 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-06 01:13:20 - cd /src TB --- 2007-04-06 01:13:20 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 6 01:13:22 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 6 02:09:49 UTC 2007 TB --- 2007-04-06 02:09:49 - generating LINT kernel config TB --- 2007-04-06 02:09:49 - cd /src/sys/sparc64/conf TB --- 2007-04-06 02:09:49 - /usr/bin/make -B LINT TB --- 2007-04-06 02:09:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-06 02:09:49 - cd /src TB --- 2007-04-06 02:09:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 6 02:09:49 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel support.o(.text+0x6c0): In function `memset': : multiple definition of `memset' memset.o(.text+0x0): first defined here ld: Warning: size of symbol `memset' changed from 40 in memset.o to 192 in support.o *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-06 02:21:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-06 02:21:41 - ERROR: failed to build lint kernel TB --- 2007-04-06 02:21:41 - tinderbox aborted TB --- 0.67 user 2.66 system 4646.11 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 02:41:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F4FC16A403; Fri, 6 Apr 2007 02:41:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8D413C448; Fri, 6 Apr 2007 02:41:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l362ffAO060506; Thu, 5 Apr 2007 22:41:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l362ffSt018959; Thu, 5 Apr 2007 22:41:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E299373039; Thu, 5 Apr 2007 22:41:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070406024140.E299373039@freebsd-current.sentex.ca> Date: Thu, 5 Apr 2007 22:41:40 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 02:41:42 -0000 TB --- 2007-04-06 01:28:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-06 01:28:12 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-04-06 01:28:12 - cleaning the object tree TB --- 2007-04-06 01:28:31 - checking out the source tree TB --- 2007-04-06 01:28:31 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-04-06 01:28:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-06 01:36:45 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-06 01:36:45 - cd /src TB --- 2007-04-06 01:36:45 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 6 01:36:47 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 6 02:30:51 UTC 2007 TB --- 2007-04-06 02:30:51 - generating LINT kernel config TB --- 2007-04-06 02:30:51 - cd /src/sys/sun4v/conf TB --- 2007-04-06 02:30:51 - /usr/bin/make -B LINT TB --- 2007-04-06 02:30:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-06 02:30:51 - cd /src TB --- 2007-04-06 02:30:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 6 02:30:51 UTC 2007 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel support.o(.text+0x4e0): In function `memset': : multiple definition of `memset' memset.o(.text+0x0): first defined here ld: Warning: size of symbol `memset' changed from 40 in memset.o to 192 in support.o *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-06 02:41:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-06 02:41:40 - ERROR: failed to build lint kernel TB --- 2007-04-06 02:41:40 - tinderbox aborted TB --- 0.65 user 2.06 system 4408.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 02:58:34 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7021816A403; Fri, 6 Apr 2007 02:58:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 1267113C458; Fri, 6 Apr 2007 02:58:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7E89E487F0; Fri, 6 Apr 2007 04:58:32 +0200 (CEST) Received: from localhost (public-gprs33845.centertel.pl [91.94.4.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9E17145B26; Fri, 6 Apr 2007 04:57:32 +0200 (CEST) Date: Fri, 6 Apr 2007 04:57:00 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20070406025700.GB98545@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org Subject: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 02:58:34 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'm happy to inform that the ZFS file system is now part of the FreeBSD operating system. ZFS is available in the HEAD branch and will be available in FreeBSD 7.0-RELEASE as an experimental feature. Commit log: Please welcome ZFS - The last word in file systems. =20 ZFS file system was ported from OpenSolaris operating system. The code in under CDDL license. =20 I'd like to thank all SUN developers that created this great piece of software. =20 Supported by: Wheel LTD (http://www.wheel.pl/) Supported by: The FreeBSD Foundation (http://www.freebsdfoundation.org/) Supported by: Sentex (http://www.sentex.net/) Limitations. Currently ZFS is only compiled as kernel module and is only available for i386 architecture. Amd64 should be available very soon, the other archs will come later, as we implement needed atomic operations. Missing functionality. - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via iSCSI is also not supported at this point. This should be fixed in the future, we may also add support for sharing ZVOLs over ggate. - There is no support for ACLs and extended attributes. - There is no support for booting off of ZFS file system. Other than that, ZFS should be fully-functional. Enjoy! --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFbb8ForvXbEpPzQRAnhYAJ9VEGhPltyreenuGZ0WkfDZG+Rn7wCgv9xk gyTdHRipWKksDu7AmsBdFj8= =nzW1 -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 03:07:52 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 189EA16A401; Fri, 6 Apr 2007 03:07:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 046DA13C43E; Fri, 6 Apr 2007 03:07:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C5DD11A4D9B; Thu, 5 Apr 2007 20:07:51 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BCC0A51579; Thu, 5 Apr 2007 23:07:50 -0400 (EDT) Date: Thu, 5 Apr 2007 23:07:50 -0400 From: Kris Kennaway To: Pawel Jakub Dawidek Message-ID: <20070406030750.GA18778@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 03:07:52 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 04:57:00AM +0200, Pawel Jakub Dawidek wrote: > Hi. >=20 > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. >=20 > Commit log: >=20 > Please welcome ZFS - The last word in file systems. > =20 > ZFS file system was ported from OpenSolaris operating system. The code > in under CDDL license. > =20 > I'd like to thank all SUN developers that created this great piece of > software. > =20 > Supported by: Wheel LTD (http://www.wheel.pl/) > Supported by: The FreeBSD Foundation (http://www.freebsdfoundation.org/) > Supported by: Sentex (http://www.sentex.net/) >=20 > Limitations. >=20 > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. >=20 > Missing functionality. >=20 > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > iSCSI is also not supported at this point. This should be fixed in > the future, we may also add support for sharing ZVOLs over ggate. > - There is no support for ACLs and extended attributes. > - There is no support for booting off of ZFS file system. >=20 > Other than that, ZFS should be fully-functional. >=20 > Enjoy! Give yourself a pat on the back :) Kris --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFbmGWry0BWjoQKURAuvhAJ48AU88otPOAdxZYFshxojGgh0GqACgzyxP RWOoa6zEMCufgqHY1ueP3WY= =Bx1M -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 03:51:14 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DACF916A404; Fri, 6 Apr 2007 03:51:14 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id C394613C465; Fri, 6 Apr 2007 03:51:14 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a6.g.dreamhost.com (sd-green-bigip-74.dreamhost.com [208.97.132.74]) by sumo.dreamhost.com (Postfix) with ESMTP id 2940517B4DB; Thu, 5 Apr 2007 20:21:09 -0700 (PDT) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a6.g.dreamhost.com (Postfix) with ESMTP id 1068B109F28; Thu, 5 Apr 2007 20:21:06 -0700 (PDT) Message-ID: <4615BCA4.7030109@cyberwang.net> Date: Thu, 05 Apr 2007 23:21:08 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 03:51:15 -0000 Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. > > Commit log: > > Please welcome ZFS - The last word in file systems. > > ZFS file system was ported from OpenSolaris operating system. The code > in under CDDL license. > > I'd like to thank all SUN developers that created this great piece of > software. > > Supported by: Wheel LTD (http://www.wheel.pl/) > Supported by: The FreeBSD Foundation (http://www.freebsdfoundation.org/) > Supported by: Sentex (http://www.sentex.net/) > > Limitations. > > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. > > Missing functionality. > > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > iSCSI is also not supported at this point. This should be fixed in > the future, we may also add support for sharing ZVOLs over ggate. > - There is no support for ACLs and extended attributes. > - There is no support for booting off of ZFS file system. > > Other than that, ZFS should be fully-functional. > > Enjoy! > > Is it fully 128bit? From wikipedia, which is by no means an authoritative source but I have no idea if this was ever an issue. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 04:11:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCC7116A403 for ; Fri, 6 Apr 2007 04:11:42 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9BB13C45B for ; Fri, 6 Apr 2007 04:11:42 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so442710nza for ; Thu, 05 Apr 2007 21:11:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VDz45fcoF3GUpVm0Y/9L5RtRt5233cX239LOVrNpEyk0y0PTW2FY5ByHccvPLBJaQpeQTHT0aoCd95Ffb5AoGxv3lEf9wxV/mzrOSUCwfvOcCG7fs/8ZVstO8dsU3ettawMtPOYrgUjDvvEzkg2CkiymVhPnpEkWm/D3kM8M3qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZVLICvK9YODGHxY47fWz/PeGPmhwdTafuLNuVxIHlm5u8CKe6UEuRiAFmkpedaeGXz/ZxmU3voe0GZ7S1oRm3MvqVVyP++BzyDzssvz1STA6CRGndBJtQB06NlqkTNyzt8dMEcpjGf0yeEclx7jYCBznhum4bn2JPaMpIu91IxY= Received: by 10.114.124.1 with SMTP id w1mr1073251wac.1175830971853; Thu, 05 Apr 2007 20:42:51 -0700 (PDT) Received: by 10.115.95.19 with HTTP; Thu, 5 Apr 2007 20:42:51 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:42:51 +1200 From: "Juha Saarinen" To: "Kris Kennaway" In-Reply-To: <20070406030750.GA18778@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406025700.GB98545@garage.freebsd.pl> <20070406030750.GA18778@xor.obsecurity.org> Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 04:11:42 -0000 On 4/6/07, Kris Kennaway wrote: > > Please welcome ZFS - The last word in file systems. > Give yourself a pat on the back :) Seconded. -- Juha http://www.geekzone.co.nz/juha From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 04:17:51 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id E9F2716A401; Fri, 6 Apr 2007 04:17:49 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Fri, 6 Apr 2007 12:17:37 +0800 From: Ariff Abdullah To: Sean Bryant Message-Id: <20070406121737.086e275a.ariff@FreeBSD.org> In-Reply-To: <46152D27.4080309@cyberwang.net> References: <46060D94.2060506@cyberwang.net> <20070325182836.548f3585.ariff@FreeBSD.org> <1174819506.1150.4.camel@jesus.automatvapen.se> <4606946B.7080209@cyberwang.net> <20070325233341.7e31cc8c.ariff@FreeBSD.org> <46069992.40706@cyberwang.net> <20070326001147.7bbc28ed.ariff@FreeBSD.org> <4606AE95.6010606@cyberwang.net> <20070326012826.7bd36ac8.ariff@FreeBSD.org> <4606C5C6.2060407@cyberwang.net> <20070326042040.37c66edb.ariff@FreeBSD.org> <46152D27.4080309@cyberwang.net> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__6_Apr_2007_12_17_37_+0800_Xbo.NMEh0_dYebDO" Cc: current@freebsd.org Subject: Re: Panic when loading snd_ich. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 04:17:51 -0000 --Signature=_Fri__6_Apr_2007_12_17_37_+0800_Xbo.NMEh0_dYebDO Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 05 Apr 2007 13:08:55 -0400 Sean Bryant wrote: >=20 > Are you still interested in seeing a panic or strange behavior with > the snd_ich driver? >=20 The later, as in "attach/reset failed" or "interrupt time out channel dead". Take note that snd_ich itself is virtually unchanged since past few months, except few obvious tiny memory leak fixes (I think I've said this twice). Why it suddenly break now is kind of mystery to me. > I decided to load it up so I could give you a better report on what > the error is. And my usb keyboard just kinda stopped working. > I tried to reproduce it and it didn't happen, i thought it was a > fluke. Then I played around for a bit and I tried to load it up > again, and boom it happened again. I can't seem to figure out a > pattern, but I'm going to get an ps/2 keyboard so I can give more > detailed information but if this little bit helps great. >=20 My suggestion (brute force way), go back to full March 16 sources, and start moving forward step by step from that point. Other people are doing this as well, painstakingly, to investigate simmilar issues. It could be because of recent ACPI import, bus related changes, etc. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Fri__6_Apr_2007_12_17_37_+0800_Xbo.NMEh0_dYebDO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFcnhlr+deMUwTNoRAu6AAKDZbOpsmVHtnAmrPp2RyskEfM9j8wCgznY2 d62K+RMKq7zUn00cXGpge8g= =cq9G -----END PGP SIGNATURE----- --Signature=_Fri__6_Apr_2007_12_17_37_+0800_Xbo.NMEh0_dYebDO-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 05:22:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A58B816A406; Fri, 6 Apr 2007 05:22:15 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7615913C4AD; Fri, 6 Apr 2007 05:22:15 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l365ME2O086066; Fri, 6 Apr 2007 00:22:14 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4615D906.60006@freebsd.org> Date: Fri, 06 Apr 2007 00:22:14 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3026/Thu Apr 5 22:00:29 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 05:22:15 -0000 On 04/05/07 21:57, Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. Pawel - you're a madman! :) I'm afraid of what your next project will be. Thanks for the solid work (again..), Eric From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 05:35:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8724216A404 for ; Fri, 6 Apr 2007 05:35:26 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1C61413C44C for ; Fri, 6 Apr 2007 05:35:25 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1167629ugh for ; Thu, 05 Apr 2007 22:35:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=of4Z4SBlT6vn07XAu+q9ubtwesL4YGKvVzeIULpVmtJwauF/aZYohESg8N25nq+ASjvcrEN4doHgSpFBBzd4rmenFf60C/5VWYUN7pQdRnmpGATEx3WDxjKcHs+SpFjxztg9A4/EwextMxSooBvmD2nDCopL+aV2W5/1POh1EKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DIeFaCaTCQqrp8sbqAINqNYZwdpSXbYG4OmoTS2w6FWdRP2DkCRd7XJS4j3roMDazHPs7Sc4GyBEKPoIqplL3t18lQv+9rn+2LCaX2urhMhv1JdAttLjC7EwZJpdLbGG+ArZPf1cVaRiW81JFJoTSVDDKeqA0nti2GVmKwXYB1g= Received: by 10.82.178.11 with SMTP id a11mr3886168buf.1175835980751; Thu, 05 Apr 2007 22:06:20 -0700 (PDT) Received: by 10.82.134.15 with HTTP; Thu, 5 Apr 2007 22:06:20 -0700 (PDT) Message-ID: <3aaaa3a0704052206l60da06f6vaafa7ac3fd8479a8@mail.gmail.com> Date: Fri, 6 Apr 2007 06:06:20 +0100 From: Chris To: "Kris Kennaway" In-Reply-To: <20070405135627.GA97163@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405135627.GA97163@xor.obsecurity.org> Cc: FreeBSD Current , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 05:35:26 -0000 On 05/04/07, Kris Kennaway wrote: > On Thu, Apr 05, 2007 at 04:58:17AM -0500, Nikolas Britton wrote: > > Can anything in the list below be removed from CURRENT? > > Why did you ask on the wrong list (corrected in reply)? > > Kris > > P.S. Just because it says "ISA" does not mean that it is junk or a > removal candidate. However, some of the network drivers on your list > (and others) are removal candidates in 7.0 as announced a few times > over the past few years, because they have no maintainers and are > Giant-locked, which is now starting to hold some things back. > > Does this mean future of FreeBSD 7 and beyond will start to stop working on small old machines that people like myself like to use for freebsd? Chris From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 05:36:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 924E616A404 for ; Fri, 6 Apr 2007 05:36:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE2F13C46E for ; Fri, 6 Apr 2007 05:36:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 707851A4DAD; Thu, 5 Apr 2007 22:36:49 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A377C513BC; Fri, 6 Apr 2007 01:36:48 -0400 (EDT) Date: Fri, 6 Apr 2007 01:36:48 -0400 From: Kris Kennaway To: Chris Message-ID: <20070406053648.GA21363@xor.obsecurity.org> References: <20070405135627.GA97163@xor.obsecurity.org> <3aaaa3a0704052206l60da06f6vaafa7ac3fd8479a8@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <3aaaa3a0704052206l60da06f6vaafa7ac3fd8479a8@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: FreeBSD Current , Nikolas Britton , Kris Kennaway Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 05:36:49 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 06:06:20AM +0100, Chris wrote: > On 05/04/07, Kris Kennaway wrote: > >On Thu, Apr 05, 2007 at 04:58:17AM -0500, Nikolas Britton wrote: > >> Can anything in the list below be removed from CURRENT? > > > >Why did you ask on the wrong list (corrected in reply)? > > > >Kris > > > >P.S. Just because it says "ISA" does not mean that it is junk or a > >removal candidate. However, some of the network drivers on your list > >(and others) are removal candidates in 7.0 as announced a few times > >over the past few years, because they have no maintainers and are > >Giant-locked, which is now starting to hold some things back. > > > > >=20 > Does this mean future of FreeBSD 7 and beyond will start to stop > working on small old machines that people like myself like to use for > freebsd? No, please read what I said instead of what you are afraid I might have said. Kris --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFdxwWry0BWjoQKURAoVAAKDEOt00AGM5f/OdqX/3ytYtGTCpmQCgmbhp TNC1aKUkvoRIJcVpDbPwyM0= =rqmz -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 07:26:37 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07CAF16A403 for ; Fri, 6 Apr 2007 07:26:37 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE0213C44C for ; Fri, 6 Apr 2007 07:26:35 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 57212 invoked from network); 6 Apr 2007 07:26:34 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 6 Apr 2007 07:26:34 -0000 Message-ID: <4615F62A.5090001@FreeBSD.org> Date: Fri, 06 Apr 2007 09:26:34 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 07:26:37 -0000 Pawel Jakub Dawidek wrote: > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. Congratulations! You're great! > - There is no support for booting off of ZFS file system. Even booting kernel from a removable ufs media and then mounting a zfs root via vfs.root.mountfrom? -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 08:04:25 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7842B16A401 for ; Fri, 6 Apr 2007 08:04:25 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by mx1.freebsd.org (Postfix) with ESMTP id 33D2E13C455 for ; Fri, 6 Apr 2007 08:04:25 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so467688nza for ; Fri, 06 Apr 2007 01:04:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=apLQlrSLkENSWk8GGeni670qK1ifEaNo8Fn9zHIHosHBqq1WAukOQ4K50xEK5HHI6woueHrcZdmCBcJL2l+7XF+5k3lZwvTsOwVivEDFbQ65rXyvCWH75eaTfMC/930oy2aadqRCZOPZlPVmLvZiR7xM4lkUxrj2V7KiqcW+JOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jyT1mCsJX4/b8OovVUKj1Khlzx6ca+pl3iLM4Rqk3/H8ATwlyoLmln9+VVa/MN5x7UCsirVUwZ+lbuIfo6xR6BtDhh1PgpBUbqUXDWyaUa3pagSYUVfZwZn97F9vPg3bUa/OR3ANVN9hOsfO57+ra74bHJ6cCenwfsFjmq68r+M= Received: by 10.115.33.1 with SMTP id l1mr1151612waj.1175846663895; Fri, 06 Apr 2007 01:04:23 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Fri, 6 Apr 2007 01:04:23 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 16:04:23 +0800 From: "Howard Su" To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3006_3639545.1175846663809" References: Cc: alfred@freebsd.org, Robert Watson Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 08:04:25 -0000 ------=_Part_3006_3639545.1175846663809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks to Robert to point out that my original patch didn't work against a threaded application. I fixed that. Please try the new patch. I tested this patch under i386 box only with libthr and libpthread. Howard On 4/4/07, Howard Su wrote: > Following the suggestion in idea page, I proposed the attached patch. > I didn't change any kernel part because I think PTRACE(2) is > functional although man page didn't document it. > > I tested the patch under i386 and amd64 box. The help on testing and > code review will be appreciated. > > To test, please try the following commands: > 1. truss ps > basic stuff > 2. truss -o output ps > output the result to file > 3. truss -f -o output sh -c "ps" > test follow fork > 4. start TOP(1) in another session, the > truss -p > > -- > -Howard > > -- -Howard ------=_Part_3006_3639545.1175846663809 Content-Type: text/plain; name=truss_patch.diff; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f06cp13a Content-Disposition: attachment; filename="truss_patch.diff" PT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL01ha2VmaWxlIzkg KHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5iaW4vdHJ1c3MvTWFr ZWZpbGUjMSAodGV4dCtrbykgPT09PSBpZGVudGljYWwKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVl YnNkL3NyYy91c3IuYmluL3RydXNzL2FtZDY0LWZic2QuYyM2ICh0ZXh0K2tvKSAtIC8vZGVwb3Qv dXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL2FtZDY0LWZic2QuYyM1ICh0ZXh0K2tv KSA9PT09IGNvbnRlbnQKQEAgLTQzLDggKzQzLDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgor I2luY2x1ZGUgPHN5cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5j bHVkZSA8bWFjaGluZS9yZWcuaD4KQEAgLTYzLDcgKzYyLDYgQEAKICNpbmNsdWRlICJzeXNjYWxs LmgiCiAjaW5jbHVkZSAiZXh0ZXJuLmgiCiAKLXN0YXRpYyBpbnQgZmQgPSAtMTsKIHN0YXRpYyBp bnQgY3BpZCA9IC0xOwogCiAjaW5jbHVkZSAic3lzY2FsbHMuaCIKQEAgLTExMywyNSArMTExLDE2 IEBACiAKIHZvaWQKIGFtZDY0X3N5c2NhbGxfZW50cnkoc3RydWN0IHRydXNzaW5mbyAqdHJ1c3Np bmZvLCBpbnQgbmFyZ3MpIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAg IGludCBzeXNjYWxsX251bTsKICAgaW50IGksIHJlZzsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwog Ci0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50 ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwotICAgIGZkID0gb3Blbihi dWYsIE9fUkRXUik7Ci0gICAgaWYgKGZkID09IC0xKSB7Ci0gICAgICBmcHJpbnRmKHRydXNzaW5m by0+b3V0ZmlsZSwgIi0tIENBTk5PVCBPUEVOIFJFR0lTVEVSUyAtLVxuIik7Ci0gICAgICByZXR1 cm47Ci0gICAgfQotICAgIGNwaWQgPSB0cnVzc2luZm8tPnBpZDsKLSAgfQorICBjcGlkID0gdHJ1 c3NpbmZvLT5jdXJ0aHJlYWQtPnRpZDsKIAogICBjbGVhcl9mc2MoKTsKLSAgbHNlZWsoZmQsIDBM LCAwKTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdz KSkgeworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8 IDApCisgIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFE IFJFR0lTVEVSUyAtLVxuIik7CiAgICAgcmV0dXJuOwogICB9CkBAIC0xNjMsNyArMTUyLDcgQEAK ICAgICB8fCAhc3RyY21wKGZzYy5uYW1lLCAicmZvcmsiKQogICAgIHx8ICFzdHJjbXAoZnNjLm5h bWUsICJ2Zm9yayIpKSkpCiAgIHsKLSAgICB0cnVzc2luZm8tPmluX2ZvcmsgPSAxOworICAgIHRy dXNzaW5mby0+Y3VydGhyZWFkLT5pbl9mb3JrID0gMTsKICAgfQogCiAgIGlmIChuYXJncyA9PSAw KQpAQCAtMTgxLDggKzE3MCwxMyBAQAogICAgIH0KICAgfQogICBpZiAobmFyZ3MgPiBpKSB7Ci0g ICAgbHNlZWsoUHJvY2ZkLCByZWdzLnJfcnNwICsgc2l6ZW9mKHJlZ2lzdGVyX3QpLCBTRUVLX1NF VCk7Ci0gICAgaWYgKHJlYWQoUHJvY2ZkLCAmZnNjLmFyZ3NbaV0sIChuYXJncy1pKSAqIHNpemVv ZihyZWdpc3Rlcl90KSkgPT0gLTEpCisgICAgc3RydWN0IHB0cmFjZV9pb19kZXNjIGlvcmVxdWVz dDsKKyAgICBpb3JlcXVlc3QucGlvZF9vcCA9IFBJT0RfUkVBRF9EOworICAgIGlvcmVxdWVzdC5w aW9kX29mZnMgPSAodm9pZCAqKShyZWdzLnJfcnNwICsgc2l6ZW9mKHJlZ2lzdGVyX3QpKTsKKyAg ICBpb3JlcXVlc3QucGlvZF9hZGRyID0gJmZzYy5hcmdzW2ldOworICAgIGlvcmVxdWVzdC5waW9k X2xlbiA9IChuYXJncyAtIGkpICogc2l6ZW9mKHJlZ2lzdGVyX3QpOworICAgIHB0cmFjZShQVF9J TywgY3BpZCwgKGNhZGRyX3QpJmlvcmVxdWVzdCwgMCk7CisgICAgaWYgKGlvcmVxdWVzdC5waW9k X2xlbiA9PSAwKQogICAgICAgcmV0dXJuOwogICB9CiAKQEAgLTIyMyw3ICsyMTcsNyBAQAogCSAg ICAgIGkgPCAoZnNjLm5hcmdzIC0gMSkgPyAiLCIgOiAiIik7CiAjZW5kaWYKICAgICAgIGlmIChz YyAmJiAhKHNjLT5hcmdzW2ldLnR5cGUgJiBPVVQpKSB7Ci0JZnNjLnNfYXJnc1tpXSA9IHByaW50 X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIDAsIHRydXNzaW5mbyk7CisJZnNj LnNfYXJnc1tpXSA9IHByaW50X2FyZygmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2lu Zm8pOwogICAgICAgfQogICAgIH0KICNpZiBERUJVRwpAQCAtMjc5LDI1ICsyNzMsMTYgQEAKIGxv bmcKIGFtZDY0X3N5c2NhbGxfZXhpdChzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm8sIGludCBz eXNjYWxsX251bSBfX3VudXNlZCkKIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJl Z3M7CiAgIGxvbmcgcmV0dmFsOwogICBpbnQgaTsKICAgaW50IGVycm9ycDsKICAgc3RydWN0IHN5 c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7 Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwotICAg IGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZw cmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4i KTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7 Ci0gIH0KKyAgY3BpZCA9IHRydXNzaW5mby0+Y3VydGhyZWFkLT50aWQ7CiAKLSAgbHNlZWsoZmQs IDBMLCAwKTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihy ZWdzKSkgeworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAw KSA8IDApCisgIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBS RUFEIFJFR0lTVEVSUyAtLVxuIik7CiAgICAgcmV0dXJuICgtMSk7CiAgIH0KQEAgLTMyOCw3ICsz MTMsNyBAQAogCWlmIChlcnJvcnApCiAJICBhc3ByaW50ZigmdGVtcCwgIjB4JWx4IiwgZnNjLmFy Z3Nbc2MtPmFyZ3NbaV0ub2Zmc2V0XSk7CiAJZWxzZQotCSAgdGVtcCA9IHByaW50X2FyZyhQcm9j ZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKKwkgIHRlbXAg PSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgcmV0dmFsLCB0cnVzc2luZm8pOwog CWZzYy5zX2FyZ3NbaV0gPSB0ZW1wOwogICAgICAgfQogICAgIH0KPT09PSAvL2RlcG90L3ZlbmRv ci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL2V4dGVybi5oIzEwICh0ZXh0K2tvKSAtIC8vZGVw b3QvdXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL2V4dGVybi5oIzMgKHRleHQra28p ID09PT0gY29udGVudApAQCAtMzIsOCArMzIsOSBAQAogICovCiAKIGV4dGVybiBpbnQgc2V0dXBf YW5kX3dhaXQoY2hhciAqKik7Ci1leHRlcm4gaW50IHN0YXJ0X3RyYWNpbmcoaW50LCBpbnQsIGlu dCwgaW50KTsKK2V4dGVybiBpbnQgc3RhcnRfdHJhY2luZyhpbnQpOwogZXh0ZXJuIHZvaWQgcmVz dG9yZV9wcm9jKGludCk7CitleHRlcm4gdm9pZCB3YWl0ZXZlbnQoc3RydWN0IHRydXNzaW5mbyAq KTsKIGV4dGVybiBjb25zdCBjaGFyICppb2N0bG5hbWUocmVnaXN0ZXJfdCB2YWwpOwogZXh0ZXJu IGNoYXIgKnN0cnNpZyhpbnQgc2lnKTsKICNpZmRlZiBfX2FscGhhX18KQEAgLTYzLDQgKzY0LDMg QEAKIGV4dGVybiBsb25nIHNwYXJjNjRfc3lzY2FsbF9leGl0KHN0cnVjdCB0cnVzc2luZm8gKiwg aW50KTsKICNlbmRpZgogCi1leHRlcm4gaW50IFByb2NmZDsKPT09PSAvL2RlcG90L3ZlbmRvci9m cmVlYnNkL3NyYy91c3IuYmluL3RydXNzL2kzODYtZmJzZC5jIzE3ICh0ZXh0K2tvKSAtIC8vZGVw b3QvdXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL2kzODYtZmJzZC5jIzQgKHRleHQr a28pID09PT0gY29udGVudApAQCAtNDMsOSArNDMsOCBAQAogICovCiAKICNpbmNsdWRlIDxzeXMv dHlwZXMuaD4KLSNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KLSNpbmNsdWRlIDxzeXMvcGlvY3RsLmg+ CiAjaW5jbHVkZSA8c3lzL3N5c2NhbGwuaD4KKyNpbmNsdWRlIDxzeXMvcHRyYWNlLmg+CiAKICNp bmNsdWRlIDxtYWNoaW5lL3JlZy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvcHNsLmg+CkBAIC02Myw3 ICs2Miw2IEBACiAjaW5jbHVkZSAic3lzY2FsbC5oIgogI2luY2x1ZGUgImV4dGVybi5oIgogCi1z dGF0aWMgaW50IGZkID0gLTE7CiBzdGF0aWMgaW50IGNwaWQgPSAtMTsKIAogI2luY2x1ZGUgInN5 c2NhbGxzLmgiCkBAIC0xMTMsMjYgKzExMSwxOCBAQAogCiB2b2lkCiBpMzg2X3N5c2NhbGxfZW50 cnkoc3RydWN0IHRydXNzaW5mbyAqdHJ1c3NpbmZvLCBpbnQgbmFyZ3MpIHsKLSAgY2hhciBidWZb MzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAgIGludCBzeXNjYWxsX251bTsKICAgaW50IGk7CiAg IHVuc2lnbmVkIGludCBwYXJtX29mZnNldDsKICAgc3RydWN0IHN5c2NhbGwgKnNjID0gTlVMTDsK KyAgc3RydWN0IHB0cmFjZV9pb19kZXNjIGlvcmVxdWVzdDsKKyAgY3BpZCA9IHRydXNzaW5mby0+ Y3VydGhyZWFkLT50aWQ7CiAKLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9IGNw aWQpIHsKLSAgICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7 Ci0gICAgZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAg IGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0t XG4iKTsKLSAgICAgIHJldHVybjsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwot ICB9Ci0KICAgY2xlYXJfZnNjKCk7Ci0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlmIChyZWFkKGZk LCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVncykpIHsKKyAgCisgIGlmIChwdHJh Y2UoUFRfR0VUUkVHUywgY3BpZCwgKGNhZGRyX3QpJnJlZ3MsIDApIDwgMCkKKyAgewogICAgIGZw cmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIFJFQUQgUkVHSVNURVJTIC0tXG4i KTsKICAgICByZXR1cm47CiAgIH0KQEAgLTE0NiwxMyArMTM2LDExIEBACiAgIHN5c2NhbGxfbnVt ID0gcmVncy5yX2VheDsKICAgc3dpdGNoIChzeXNjYWxsX251bSkgewogICBjYXNlIFNZU19zeXNj YWxsOgotICAgIGxzZWVrKFByb2NmZCwgcGFybV9vZmZzZXQsIFNFRUtfU0VUKTsKLSAgICByZWFk KFByb2NmZCwgJnN5c2NhbGxfbnVtLCBzaXplb2YoaW50KSk7CisgICAgc3lzY2FsbF9udW0gPSBw dHJhY2UoUFRfUkVBRF9ELCBjcGlkLCAoY2FkZHJfdClwYXJtX29mZnNldCwgMCk7CiAgICAgcGFy bV9vZmZzZXQgKz0gc2l6ZW9mKGludCk7CiAgICAgYnJlYWs7CiAgIGNhc2UgU1lTX19fc3lzY2Fs bDoKLSAgICBsc2VlayhQcm9jZmQsIHBhcm1fb2Zmc2V0LCBTRUVLX1NFVCk7Ci0gICAgcmVhZChQ cm9jZmQsICZzeXNjYWxsX251bSwgc2l6ZW9mKGludCkpOworICAgIHN5c2NhbGxfbnVtID0gcHRy YWNlKFBUX1JFQURfRCwgY3BpZCwgKGNhZGRyX3QpcGFybV9vZmZzZXQsIDApOwogICAgIHBhcm1f b2Zmc2V0ICs9IHNpemVvZihxdWFkX3QpOwogICAgIGJyZWFrOwogICB9CkBAIC0xNjksMTUgKzE1 NywxOSBAQAogICAgIHx8ICFzdHJjbXAoZnNjLm5hbWUsICJyZm9yayIpCiAgICAgfHwgIXN0cmNt cChmc2MubmFtZSwgInZmb3JrIikpKSkKICAgewotICAgIHRydXNzaW5mby0+aW5fZm9yayA9IDE7 CisgICAgdHJ1c3NpbmZvLT5jdXJ0aHJlYWQtPmluX2ZvcmsgPSAxOwogICB9CiAKICAgaWYgKG5h cmdzID09IDApCiAgICAgcmV0dXJuOwogCiAgIGZzYy5hcmdzID0gbWFsbG9jKCgxK25hcmdzKSAq IHNpemVvZih1bnNpZ25lZCBsb25nKSk7Ci0gIGxzZWVrKFByb2NmZCwgcGFybV9vZmZzZXQsIFNF RUtfU0VUKTsKLSAgaWYgKHJlYWQoUHJvY2ZkLCBmc2MuYXJncywgbmFyZ3MgKiBzaXplb2YodW5z aWduZWQgbG9uZykpID09IC0xKQorICBpb3JlcXVlc3QucGlvZF9vcCA9IFBJT0RfUkVBRF9EOwor ICBpb3JlcXVlc3QucGlvZF9vZmZzID0gKHZvaWQgKilwYXJtX29mZnNldDsKKyAgaW9yZXF1ZXN0 LnBpb2RfYWRkciA9IGZzYy5hcmdzOworICBpb3JlcXVlc3QucGlvZF9sZW4gPSBuYXJncyAqIHNp emVvZih1bnNpZ25lZCBsb25nKTsKKyAgcHRyYWNlKFBUX0lPLCBjcGlkLCAoY2FkZHJfdCkmaW9y ZXF1ZXN0LCAwKTsKKyAgaWYgKGlvcmVxdWVzdC5waW9kX2xlbiA9PSAwKQogICAgIHJldHVybjsK IAogICBpZiAoZnNjLm5hbWUpCkBAIC0yMTgsNyArMjEwLDcgQEAKIAkgICAgICBpIDwgKGZzYy5u YXJncyAtIDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAgICAgICBpZiAoc2MgJiYgIShzYy0+YXJn c1tpXS50eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9hcmcoUHJvY2ZkLCAm c2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOworCWZzYy5zX2FyZ3NbaV0gPSBw cmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZvKTsKICAgICAgIH0K ICAgICB9CiAjaWYgREVCVUcKQEAgLTI3NCwyOCArMjY2LDIwIEBACiBsb25nCiBpMzg2X3N5c2Nh bGxfZXhpdChzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm8sIGludCBzeXNjYWxsX251bSBfX3Vu dXNlZCkKIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1Y3QgcmVnIHJlZ3M7CiAgIGxvbmcgcmV0 dmFsOwogICBpbnQgaTsKICAgaW50IGVycm9ycDsKICAgc3RydWN0IHN5c2NhbGwgKnNjOwogCi0g IGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlkKSB7Ci0gICAgc3ByaW50Zihi dWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwotICAgIGZkID0gb3BlbihidWYs IE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmludGYodHJ1c3NpbmZv LT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsKLSAgICAgIHJldHVy biAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0gIH0KKyAgY3BpZCA9 IHRydXNzaW5mby0+Y3VydGhyZWFkLT50aWQ7CiAKLSAgbHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYg KHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVvZihyZWdzKSkgeworICBpZiAo cHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8IDApCisgIHsKICAg ICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFEIFJFR0lTVEVSUyAt LVxuIik7CiAgICAgcmV0dXJuICgtMSk7CiAgIH0KKyAgCiAgIHJldHZhbCA9IHJlZ3Mucl9lYXg7 CiAgIGVycm9ycCA9ICEhKHJlZ3Mucl9lZmxhZ3MgJiBQU0xfQyk7CiAKQEAgLTMyMyw3ICszMDcs NyBAQAogCWlmIChlcnJvcnApCiAJICBhc3ByaW50ZigmdGVtcCwgIjB4JWx4IiwgZnNjLmFyZ3Nb c2MtPmFyZ3NbaV0ub2Zmc2V0XSk7CiAJZWxzZQotCSAgdGVtcCA9IHByaW50X2FyZyhQcm9jZmQs ICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKKwkgIHRlbXAgPSBw cmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgcmV0dmFsLCB0cnVzc2luZm8pOwogCWZz Yy5zX2FyZ3NbaV0gPSB0ZW1wOwogICAgICAgfQogICAgIH0KPT09PSAvL2RlcG90L3ZlbmRvci9m cmVlYnNkL3NyYy91c3IuYmluL3RydXNzL2kzODYtbGludXguYyMxNiAodGV4dCtrbykgLSAvL2Rl cG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9pMzg2LWxpbnV4LmMjNCAodGV4 dCtrbykgPT09PSBjb250ZW50CkBAIC00MSw4ICs0MSw3IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5 cy90eXBlcy5oPgotI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgotI2luY2x1ZGUgPHN5cy9waW9jdGwu aD4KKyNpbmNsdWRlIDxzeXMvcHRyYWNlLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL3JlZy5oPgog I2luY2x1ZGUgPG1hY2hpbmUvcHNsLmg+CkBAIC02MCw3ICs1OSw2IEBACiAjaW5jbHVkZSAic3lz Y2FsbC5oIgogI2luY2x1ZGUgImV4dGVybi5oIgogCi1zdGF0aWMgaW50IGZkID0gLTE7CiBzdGF0 aWMgaW50IGNwaWQgPSAtMTsKIAogI2luY2x1ZGUgImxpbnV4X3N5c2NhbGxzLmgiCkBAIC0xMDgs MjggKzEwNiwyMCBAQAogCiB2b2lkCiBpMzg2X2xpbnV4X3N5c2NhbGxfZW50cnkoc3RydWN0IHRy dXNzaW5mbyAqdHJ1c3NpbmZvLCBpbnQgbmFyZ3MpIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1 Y3QgcmVnIHJlZ3M7CiAgIGludCBzeXNjYWxsX251bTsKICAgaW50IGk7CiAgIHN0cnVjdCBzeXNj YWxsICpzYzsKIAotICBpZiAoZmQgPT0gLTEgfHwgdHJ1c3NpbmZvLT5waWQgIT0gY3BpZCkgewot ICAgIHNwcmludGYoYnVmLCAiL3Byb2MvJWQvcmVncyIsIHRydXNzaW5mby0+cGlkKTsKLSAgICBm ZCA9IG9wZW4oYnVmLCBPX1JEV1IpOwotICAgIGlmIChmZCA9PSAtMSkgewotICAgICAgZnByaW50 Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgT1BFTiBSRUdJU1RFUlMgLS1cbiIpOwot ICAgICAgcmV0dXJuOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0gIH0KKyAg Y3BpZCA9IHRydXNzaW5mby0+Y3VydGhyZWFkLT50aWQ7CiAKICAgY2xlYXJfZnNjKCk7Ci0gIGxz ZWVrKGZkLCAwTCwgMCk7Ci0gIGlmIChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBz aXplb2YocmVncykpIHsKKyAgCisgIGlmIChwdHJhY2UoUFRfR0VUUkVHUywgY3BpZCwgKGNhZGRy X3QpJnJlZ3MsIDApIDwgMCkKKyAgewogICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAi LS0gQ0FOTk9UIFJFQUQgUkVHSVNURVJTIC0tXG4iKTsKICAgICByZXR1cm47Ci0gIH0KKyAgfSAK ICAgc3lzY2FsbF9udW0gPSByZWdzLnJfZWF4OwogCiAgIGZzYy5udW1iZXIgPSBzeXNjYWxsX251 bTsKQEAgLTE0Myw3ICsxMzMsNyBAQAogICAgJiYgKCghc3RyY21wKGZzYy5uYW1lLCAibGludXhf Zm9yayIpCiAgICAgfHwgIXN0cmNtcChmc2MubmFtZSwgImxpbnV4X3Zmb3JrIikpKSkKICAgewot ICAgIHRydXNzaW5mby0+aW5fZm9yayA9IDE7CisgICAgdHJ1c3NpbmZvLT5jdXJ0aHJlYWQtPmlu X2ZvcmsgPSAxOwogICB9CiAKICAgaWYgKG5hcmdzID09IDApCkBAIC0yMDAsNyArMTkwLDcgQEAK IAkgICAgICBpIDwgKGZzYy5uYXJncyAtIDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAgICAgICBp ZiAoc2MgJiYgIShzYy0+YXJnc1tpXS50eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3NbaV0gPSBw cmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOwor CWZzYy5zX2FyZ3NbaV0gPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1 c3NpbmZvKTsKICAgICAgIH0KICAgICB9CiAjaWYgREVCVUcKQEAgLTI2NCwyOCArMjU0LDE5IEBA CiBsb25nCiBpMzg2X2xpbnV4X3N5c2NhbGxfZXhpdChzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2lu Zm8sIGludCBzeXNjYWxsX251bSBfX3VudXNlZCkKIHsKLSAgY2hhciBidWZbMzJdOwogICBzdHJ1 Y3QgcmVnIHJlZ3M7CiAgIGxvbmcgcmV0dmFsOwogICBpbnQgaTsKICAgaW50IGVycm9ycDsKICAg c3RydWN0IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAh PSBjcGlkKSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5w aWQpOwotICAgIGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsK LSAgICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNU RVJTIC0tXG4iKTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3Np bmZvLT5waWQ7CisgIGNwaWQgPSB0cnVzc2luZm8tPmN1cnRocmVhZC0+dGlkOworICBpZiAocHRy YWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdzLCAwKSA8IDApCisgIHsKKyAgICBm cHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBSRUFEIFJFR0lTVEVSUyAtLVxu Iik7CisgICAgcmV0dXJuICgtMSk7CiAgIH0KIAotICBsc2VlayhmZCwgMEwsIDApOwotICBpZiAo cmVhZChmZCwgJnJlZ3MsIHNpemVvZihyZWdzKSkgIT0gc2l6ZW9mKHJlZ3MpKSB7Ci0gICAgZnBy aW50Zih0cnVzc2luZm8tPm91dGZpbGUsICJcbiIpOwotICAgIHJldHVybiAoLTEpOwotICB9CiAg IHJldHZhbCA9IHJlZ3Mucl9lYXg7CiAgIGVycm9ycCA9ICEhKHJlZ3Mucl9lZmxhZ3MgJiBQU0xf Qyk7CiAKQEAgLTMxMyw3ICsyOTQsNyBAQAogCWlmIChlcnJvcnApCiAJICBhc3ByaW50ZigmdGVt cCwgIjB4JWx4IiwgZnNjLmFyZ3Nbc2MtPmFyZ3NbaV0ub2Zmc2V0XSk7CiAJZWxzZQotCSAgdGVt cCA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIHJldHZhbCwgdHJ1 c3NpbmZvKTsKKwkgIHRlbXAgPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgcmV0 dmFsLCB0cnVzc2luZm8pOwogCWZzYy5zX2FyZ3NbaV0gPSB0ZW1wOwogICAgICAgfQogICAgIH0K PT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNzL2kzODYuY29uZiMx ICh0ZXh0K2tvKSAtIC8vZGVwb3QvdXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL2kz ODYuY29uZiMxICh0ZXh0K2tvKSA9PT09IGlkZW50aWNhbAo9PT09IC8vZGVwb3QvdmVuZG9yL2Zy ZWVic2Qvc3JjL3Vzci5iaW4vdHJ1c3MvaTM4NmxpbnV4LmNvbmYjMSAodGV4dCtrbykgLSAvL2Rl cG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9pMzg2bGludXguY29uZiMxICh0 ZXh0K2tvKSA9PT09IGlkZW50aWNhbAo9PT09IC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3Vz ci5iaW4vdHJ1c3MvaWE2NC1mYnNkLmMjOSAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJk c3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9pYTY0LWZic2QuYyMzICh0ZXh0K2tvKSA9PT09IGNvbnRl bnQKQEAgLTQzLDggKzQzLDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5j bHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgorI2luY2x1ZGUgPHN5 cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5jbHVkZSA8bWFjaGlu ZS9yZWcuaD4KQEAgLTYyLDcgKzYxLDYgQEAKICNpbmNsdWRlICJzeXNjYWxsLmgiCiAjaW5jbHVk ZSAiZXh0ZXJuLmgiCiAKLXN0YXRpYyBpbnQgZmQgPSAtMTsKIHN0YXRpYyBpbnQgY3BpZCA9IC0x OwogCiAjaW5jbHVkZSAic3lzY2FsbHMuaCIKQEAgLTExMiwyNiArMTEwLDE2IEBACiAKIHZvaWQK IGlhNjRfc3lzY2FsbF9lbnRyeShzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm8sIGludCBuYXJn cykgewotICBjaGFyIGJ1ZlszMl07CiAgIHN0cnVjdCByZWcgcmVnczsKICAgaW50IHN5c2NhbGxf bnVtOwogICBpbnQgaTsKICAgdW5zaWduZWQgbG9uZyAqcGFybV9vZmZzZXQ7CiAgIHN0cnVjdCBz eXNjYWxsICpzYzsKIAotICBpZiAoZmQgPT0gLTEgfHwgdHJ1c3NpbmZvLT5waWQgIT0gY3BpZCkg ewotICAgIHNwcmludGYoYnVmLCAiL3Byb2MvJWQvcmVncyIsIHRydXNzaW5mby0+cGlkKTsKLSAg ICBmZCA9IG9wZW4oYnVmLCBPX1JEV1IpOwotICAgIGlmIChmZCA9PSAtMSkgewotICAgICAgZnBy aW50Zih0cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgT1BFTiBSRUdJU1RFUlMgLS1cbiIp OwotICAgICAgcmV0dXJuOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5waWQ7Ci0gIH0K KyAgY3BpZCA9IHRydXNzaW5mby0+Y3VydGhyZWFkLT5pZDsKIAogICBjbGVhcl9mc2MoKTsKLSAg bHNlZWsoZmQsIDBMLCAwKTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9 IHNpemVvZihyZWdzKSkgeworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90 KSZyZWdzLCAwKSA8IDApIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENB Tk5PVCBSRUFEIFJFR0lTVEVSUyAtLVxuIik7CiAgICAgcmV0dXJuOwogICB9CkBAIC0xNTgsNyAr MTQ2LDcgQEAKICAgICB8fCAhc3RyY21wKGZzYy5uYW1lLCAicmZvcmsiKQogICAgIHx8ICFzdHJj bXAoZnNjLm5hbWUsICJ2Zm9yayIpKSkpCiAgIHsKLSAgICB0cnVzc2luZm8tPmluX2ZvcmsgPSAx OworICAgIHRydXNzaW5mby0+Y3VydGhyZWFkLT5pbl9mb3JrID0gMTsKICAgfQogCiAgIGlmIChu YXJncyA9PSAwKQpAQCAtMjA0LDcgKzE5Miw3IEBACiAJICAgICAgaSA8IChmc2MubmFyZ3MgLSAx KSA/ICIsIiA6ICIiKTsKICNlbmRpZgogICAgICAgaWYgKHNjICYmICEoc2MtPmFyZ3NbaV0udHlw ZSAmIE9VVCkpIHsKLQlmc2Muc19hcmdzW2ldID0gcHJpbnRfYXJnKFByb2NmZCwgJnNjLT5hcmdz W2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZvKTsKKwlmc2Muc19hcmdzW2ldID0gcHJpbnRfYXJn KCZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIDAsIHRydXNzaW5mbyk7CiAgICAgICB9CiAgICAgfQog I2lmIERFQlVHCkBAIC0yNjAsMjUgKzI0OCwxNSBAQAogbG9uZwogaWE2NF9zeXNjYWxsX2V4aXQo c3RydWN0IHRydXNzaW5mbyAqdHJ1c3NpbmZvLCBpbnQgc3lzY2FsbF9udW0gX191bnVzZWQpCiB7 Ci0gIGNoYXIgYnVmWzMyXTsKICAgc3RydWN0IHJlZyByZWdzOwogICBsb25nIHJldHZhbDsKICAg aW50IGk7CiAgIGludCBlcnJvcnA7CiAgIHN0cnVjdCBzeXNjYWxsICpzYzsKIAotICBpZiAoZmQg PT0gLTEgfHwgdHJ1c3NpbmZvLT5waWQgIT0gY3BpZCkgewotICAgIHNwcmludGYoYnVmLCAiL3By b2MvJWQvcmVncyIsIHRydXNzaW5mby0+cGlkKTsKLSAgICBmZCA9IG9wZW4oYnVmLCBPX1JET05M WSk7Ci0gICAgaWYgKGZkID09IC0xKSB7Ci0gICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0Zmls ZSwgIi0tIENBTk5PVCBPUEVOIFJFR0lTVEVSUyAtLVxuIik7Ci0gICAgICByZXR1cm4gKC0xKTsK LSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwotICB9CisgIGNwaWQgPSB0cnVzc2lu Zm8tPmN1cnRocmVhZC0+dGlkOwogCi0gIGxzZWVrKGZkLCAwTCwgMCk7Ci0gIGlmIChyZWFkKGZk LCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVncykpIHsKKyAgaWYgKHB0cmFjZShQ VF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkgPCAwKSB7CiAgICAgZnByaW50Zih0 cnVzc2luZm8tPm91dGZpbGUsICItLSBDQU5OT1QgUkVBRCBSRUdJU1RFUlMgLS1cbiIpOwogICAg IHJldHVybiAoLTEpOwogICB9CkBAIC0zMDksNyArMjg3LDcgQEAKIAlpZiAoZXJyb3JwKQogCSAg YXNwcmludGYoJnRlbXAsICIweCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9mZnNldF0pOwog CWVsc2UKLQkgIHRlbXAgPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdz LCByZXR2YWwsIHRydXNzaW5mbyk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwg ZnNjLmFyZ3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0gdGVtcDsKICAg ICAgIH0KICAgICB9Cj09PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVz cy9tYWluLmMjMjQgKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3RydXNzL3Vzci5i aW4vdHJ1c3MvbWFpbi5jIzYgKHRleHQra28pID09PT0gY29udGVudApAQCAtMzksMTEgKzM5LDEw IEBACiAgKi8KIAogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5cy9pb2N0bC5o PgotI2luY2x1ZGUgPHN5cy9waW9jdGwuaD4KICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KICNpbmNs dWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPHN5 cy9zeXNjdGwuaD4KIAogI2luY2x1ZGUgPGN0eXBlLmg+CiAjaW5jbHVkZSA8ZXJyLmg+CkBAIC01 OSwxMyArNTgsOCBAQAogI2luY2x1ZGUgInRydXNzLmgiCiAjaW5jbHVkZSAiZXh0ZXJuLmgiCiAK LS8qCi0gKiBJdCdzIGRpZmZpY3VsdCB0byBwYXJhbWV0ZXJpemUgdGhpcyBiZWNhdXNlIGl0IG11 c3QgYmUKLSAqIGFjY2Vzc2libGUgaW4gYSBzaWduYWwgaGFuZGxlci4KLSAqLworI2RlZmluZSBN QVhBUkdTIDUKIAotaW50IFByb2NmZDsKLQogc3RhdGljIHZvaWQKIHVzYWdlKHZvaWQpCiB7CkBA IC0xMTksMTggKzExMywxOSBAQAogc2V0X2V0eXBlKHN0cnVjdCB0cnVzc2luZm8gKnRydXNzaW5m bykKIHsKIAlzdHJ1Y3QgZXhfdHlwZXMgKmZ1bmNzOwotCWNoYXIgZXR5cGVbMjRdOwogCWNoYXIg cHJvZ3RbMzJdOwotCWludCBmZDsKKwkKKwlzaXplX3QgbGVuID0gc2l6ZW9mKHByb2d0KTsKKwlp bnQgbWliWzRdOworCWludCBlcnJvcjsKIAotCXNwcmludGYoZXR5cGUsICIvcHJvYy8lZC9ldHlw ZSIsIHRydXNzaW5mby0+cGlkKTsKLQlpZiAoKGZkID0gb3BlbihldHlwZSwgT19SRE9OTFkpKSA9 PSAtMSkgewotCQlzdHJjcHkocHJvZ3QsICJGcmVlQlNEIGEub3V0Iik7Ci0JfSBlbHNlIHsKLQkJ aW50IGxlbiA9IHJlYWQoZmQsIHByb2d0LCBzaXplb2YocHJvZ3QpKTsKLQkJcHJvZ3RbbGVuLTFd ID0gJ1wwJzsKLQkJY2xvc2UoZmQpOwotCX0KKwltaWJbMF0gPSBDVExfS0VSTjsKKwltaWJbMV0g PSBLRVJOX1BST0M7CisJbWliWzJdID0gS0VSTl9QUk9DX1NWX05BTUU7CisJbWliWzNdID0gdHJ1 c3NpbmZvLT5waWQ7CisJZXJyb3IgPSBzeXNjdGwobWliLCA0LCBwcm9ndCwgJmxlbiwgTlVMTCwg MCk7CisJaWYgKGVycm9yICE9IDApCisJCWVycigyLCAiY2FuIG5vdCBnZXQgZXR5cGUiKTsKIAog CWZvciAoZnVuY3MgPSBleF90eXBlczsgZnVuY3MtPnR5cGU7IGZ1bmNzKyspCiAJCWlmICghc3Ry Y21wKGZ1bmNzLT50eXBlLCBwcm9ndCkpCkBAIC0xNjcsMTQgKzE2MiwxMiBAQAogCWludCBjOwog CWludCBpOwogCWNoYXIgKipjb21tYW5kOwotCXN0cnVjdCBwcm9jZnNfc3RhdHVzIHBmczsKIAlz dHJ1Y3QgZXhfdHlwZXMgKmZ1bmNzOwotCWludCBpbl9leGVjLCBzaWdleGl0LCBpbml0aWFsX29w ZW47CisJaW50IHNpZ2V4aXQsIGluaXRpYWxfb3BlbjsKIAljaGFyICpmbmFtZTsKIAlzdHJ1Y3Qg dHJ1c3NpbmZvICp0cnVzc2luZm87CiAJY2hhciAqc2lnbmFtZTsKIAotCWluX2V4ZWMgPSAwOwog CXNpZ2V4aXQgPSAwOwogCWZuYW1lID0gTlVMTDsKIAlpbml0aWFsX29wZW4gPSAxOwpAQCAtMTg0 LDkgKzE3NywxMiBAQAogCWlmICh0cnVzc2luZm8gPT0gTlVMTCkKIAkJZXJyeCgxLCAibWFsbG9j KCkgZmFpbGVkIik7CiAJYnplcm8odHJ1c3NpbmZvLCBzaXplb2Yoc3RydWN0IHRydXNzaW5mbykp OworCQogCXRydXNzaW5mby0+b3V0ZmlsZSA9IHN0ZGVycjsKIAl0cnVzc2luZm8tPnN0cnNpemUg PSAzMjsKLQorCXRydXNzaW5mby0+cHJfd2h5ID0gU19OT05FOworCXRydXNzaW5mby0+Y3VydGhy ZWFkID0gTlVMTDsKKwlTTElTVF9JTklUKCZ0cnVzc2luZm8tPnRocmVhZGxpc3QpOwogCXdoaWxl ICgoYyA9IGdldG9wdChhYywgYXYsICJwOm86ZmFlZERzOlMiKSkgIT0gLTEpIHsKIAkJc3dpdGNo IChjKSB7CiAJCWNhc2UgJ3AnOgkvKiBzcGVjaWZpZWQgcGlkICovCkBAIC0yNDUsNiArMjQxLDcg QEAKIAkJc2lnbmFsKFNJR1RFUk0sIFNJR19JR04pOwogCQlzaWduYWwoU0lHUVVJVCwgU0lHX0lH Tik7CiAJfSBlbHNlIHsKKwkJc3RhcnRfdHJhY2luZyh0cnVzc2luZm8tPnBpZCk7CiAJCXNpZ25h bChTSUdJTlQsIHJlc3RvcmVfcHJvYyk7CiAJCXNpZ25hbChTSUdURVJNLCByZXN0b3JlX3Byb2Mp OwogCQlzaWduYWwoU0lHUVVJVCwgcmVzdG9yZV9wcm9jKTsKQEAgLTI1NywxOCArMjU0LDkgQEAK IAkgKi8KIAogU1RBUlRfVFJBQ0U6Ci0JUHJvY2ZkID0gc3RhcnRfdHJhY2luZygKLQkgICAgdHJ1 c3NpbmZvLT5waWQsIGluaXRpYWxfb3BlbiwKLQkgICAgU19FWEVDIHwgU19TQ0UgfCBTX1NDWCB8 IFNfQ09SRSB8IFNfRVhJVCB8Ci0JICAgICgodHJ1c3NpbmZvLT5mbGFncyAmIE5PU0lHUykgPyAw IDogU19TSUcpLAotCSAgICAoKHRydXNzaW5mby0+ZmxhZ3MgJiBGT0xMT1dGT1JLUykgPyBQRl9G T1JLIDogMCkpOworCWZ1bmNzID0gc2V0X2V0eXBlKHRydXNzaW5mbyk7CisKIAlpbml0aWFsX29w ZW4gPSAwOwotCWlmIChQcm9jZmQgPT0gLTEpCi0JCXJldHVybiAoMCk7Ci0KLQlwZnMud2h5ID0g MDsKLQotCWZ1bmNzID0gc2V0X2V0eXBlKHRydXNzaW5mbyk7CiAJLyoKIAkgKiBBdCB0aGlzIHBv aW50LCBpdCdzIGEgc2ltcGxlIGxvb3AsIHdhaXRpbmcgZm9yIHRoZSBwcm9jZXNzIHRvCiAJICog c3RvcCwgZmluZGluZyBvdXQgd2h5LCBwcmludGluZyBvdXQgd2h5LCBhbmQgdGhlbiBjb250aW51 aW5nIGl0LgpAQCAtMjc4LDExOCArMjY2LDkyIEBACiAJY2xvY2tfZ2V0dGltZShDTE9DS19SRUFM VElNRSwgJnRydXNzaW5mby0+c3RhcnRfdGltZSk7CiAKIAlkbyB7Ci0JCWludCB2YWwgPSAwOwog CQlzdHJ1Y3QgdGltZXNwZWMgdGltZWRpZmY7CisJCXdhaXRldmVudCh0cnVzc2luZm8pOwogCi0J CWlmIChpb2N0bChQcm9jZmQsIFBJT0NXQUlULCAmcGZzKSA9PSAtMSkKLQkJCXdhcm4oIlBJT0NX QUlUIHRvcCBvZiBsb29wIik7Ci0JCWVsc2UgewotCQkJc3dpdGNoKGkgPSBwZnMud2h5KSB7Ci0J CQljYXNlIFNfU0NFOgotCQkJCWZ1bmNzLT5lbnRlcl9zeXNjYWxsKHRydXNzaW5mbywgcGZzLnZh bCk7Ci0JCQkJY2xvY2tfZ2V0dGltZShDTE9DS19SRUFMVElNRSwKLQkJCQkgICAgJnRydXNzaW5m by0+YmVmb3JlKTsKLQkJCQlicmVhazsKLQkJCWNhc2UgU19TQ1g6Ci0JCQkJY2xvY2tfZ2V0dGlt ZShDTE9DS19SRUFMVElNRSwKLQkJCQkgICAgJnRydXNzaW5mby0+YWZ0ZXIpOwotCQkJCS8qCi0J CQkJICogVGhpcyBpcyBzbyB3ZSBkb24ndCBnZXQgdHdvIG1lc3NhZ2VzIGZvcgotCQkJCSAqIGFu IGV4ZWMgLS0gb25lIGZvciB0aGUgU19FWEVDLCBhbmQgb25lIGZvcgotCQkJCSAqIHRoZSBzeXNj YWxsIGV4aXQuICBJdCBhbHNvLCBjb252ZW5pZW50bHksCi0JCQkJICogZW5zdXJlcyB0aGF0IHRo ZSBmaXJzdCBtZXNzYWdlIHByaW50ZWQgb3V0Ci0JCQkJICogaXNuJ3QgdGhlIHJldHVybi1mcm9t LXN5c2NhbGwgdXNlZCB0bwotCQkJCSAqIGNyZWF0ZSB0aGUgcHJvY2Vzcy4KLQkJCQkgKi8KLQkJ CQlpZiAoaW5fZXhlYykgewotCQkJCQlpbl9leGVjID0gMDsKLQkJCQkJYnJlYWs7Ci0JCQkJfQor CQlzd2l0Y2goaSA9IHRydXNzaW5mby0+cHJfd2h5KSB7CisJCWNhc2UgU19TQ0U6CisJCQlmdW5j cy0+ZW50ZXJfc3lzY2FsbCh0cnVzc2luZm8sIE1BWEFSR1MpOworCQkJY2xvY2tfZ2V0dGltZShD TE9DS19SRUFMVElNRSwKKwkJCSAgICAmdHJ1c3NpbmZvLT5iZWZvcmUpOworCQkJYnJlYWs7CisJ CWNhc2UgU19TQ1g6CisJCQljbG9ja19nZXR0aW1lKENMT0NLX1JFQUxUSU1FLAorCQkJICAgICZ0 cnVzc2luZm8tPmFmdGVyKTsKIAotCQkJCWlmICh0cnVzc2luZm8tPmluX2ZvcmsgJiYKLQkJCQkg ICAgKHRydXNzaW5mby0+ZmxhZ3MgJiBGT0xMT1dGT1JLUykpIHsKLQkJCQkJaW50IGNoaWxkcGlk OworCQkJaWYgKHRydXNzaW5mby0+Y3VydGhyZWFkLT5pbl9mb3JrICYmCisJCQkgICAgKHRydXNz aW5mby0+ZmxhZ3MgJiBGT0xMT1dGT1JLUykpIHsKKwkJCQlpbnQgY2hpbGRwaWQ7CiAKLQkJCQkJ dHJ1c3NpbmZvLT5pbl9mb3JrID0gMDsKLQkJCQkJY2hpbGRwaWQgPQotCQkJCQkgICAgZnVuY3Mt PmV4aXRfc3lzY2FsbCh0cnVzc2luZm8sCi0JCQkJCQlwZnMudmFsKTsKKwkJCQl0cnVzc2luZm8t PmN1cnRocmVhZC0+aW5fZm9yayA9IDA7CisJCQkJY2hpbGRwaWQgPQorCQkJCSAgICBmdW5jcy0+ ZXhpdF9zeXNjYWxsKHRydXNzaW5mbywKKwkJCQkJdHJ1c3NpbmZvLT5wcl9kYXRhKTsKIAotCQkJ CQkvKgotCQkJCQkgKiBGb3JrIGEgbmV3IGNvcHkgb2Ygb3Vyc2VsZiB0byB0cmFjZQotCQkJCQkg KiB0aGUgY2hpbGQgb2YgdGhlIG9yaWdpbmFsIHRyYWNlZAotCQkJCQkgKiBwcm9jZXNzLgotCQkJ CQkgKi8KLQkJCQkJaWYgKGZvcmsoKSA9PSAwKSB7Ci0JCQkJCQl0cnVzc2luZm8tPnBpZCA9IGNo aWxkcGlkOwotCQkJCQkJZ290byBTVEFSVF9UUkFDRTsKLQkJCQkJfQotCQkJCQlicmVhazsKKwkJ CQkvKgorCQkJCSAqIEZvcmsgYSBuZXcgY29weSBvZiBvdXJzZWxmIHRvIHRyYWNlCisJCQkJICog dGhlIGNoaWxkIG9mIHRoZSBvcmlnaW5hbCB0cmFjZWQKKwkJCQkgKiBwcm9jZXNzLgorCQkJCSAq LworCQkJCWlmIChmb3JrKCkgPT0gMCkgeworCQkJCQl0cnVzc2luZm8tPnBpZCA9IGNoaWxkcGlk OworCQkJCQlzdGFydF90cmFjaW5nKHRydXNzaW5mby0+cGlkKTsKKwkJCQkJZ290byBTVEFSVF9U UkFDRTsKIAkJCQl9Ci0JCQkJZnVuY3MtPmV4aXRfc3lzY2FsbCh0cnVzc2luZm8sIHBmcy52YWwp OwogCQkJCWJyZWFrOwotCQkJY2FzZSBTX1NJRzoKLQkJCQlpZiAodHJ1c3NpbmZvLT5mbGFncyAm IEZPTExPV0ZPUktTKQotCQkJCQlmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiU1ZDogIiwK LQkJCQkJICAgIHRydXNzaW5mby0+cGlkKTsKLQkJCQlpZiAodHJ1c3NpbmZvLT5mbGFncyAmIEFC U09MVVRFVElNRVNUQU1QUykgewotCQkJCQl0aW1lc3BlY3N1YnQoJnRydXNzaW5mby0+YWZ0ZXIs Ci0JCQkJCSAgICAmdHJ1c3NpbmZvLT5zdGFydF90aW1lLCAmdGltZWRpZmYpOwotCQkJCQlmcHJp bnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiVsZC4lMDlsZCAiLAotCQkJCQkgICAgKGxvbmcpdGlt ZWRpZmYudHZfc2VjLAotCQkJCQkgICAgdGltZWRpZmYudHZfbnNlYyk7Ci0JCQkJfQotCQkJCWlm ICh0cnVzc2luZm8tPmZsYWdzICYgUkVMQVRJVkVUSU1FU1RBTVBTKSB7Ci0JCQkJCXRpbWVzcGVj c3VidCgmdHJ1c3NpbmZvLT5hZnRlciwKLQkJCQkJICAgICZ0cnVzc2luZm8tPmJlZm9yZSwgJnRp bWVkaWZmKTsKLQkJCQkJZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQgIiwK LQkJCQkJICAgIChsb25nKXRpbWVkaWZmLnR2X3NlYywKLQkJCQkJICAgIHRpbWVkaWZmLnR2X25z ZWMpOwotCQkJCX0KLQkJCQlzaWduYW1lID0gc3Ryc2lnKHBmcy52YWwpOwotCQkJCWZwcmludGYo dHJ1c3NpbmZvLT5vdXRmaWxlLAotCQkJCSAgICAiU0lHTkFMICVsdSAoJXMpXG4iLCBwZnMudmFs LAotCQkJCSAgICBzaWduYW1lID09IE5VTEwgPyAiPyIgOiBzaWduYW1lKTsKLQkJCQlmcmVlKHNp Z25hbWUpOwotCQkJCXNpZ2V4aXQgPSBwZnMudmFsOworCQkJfQorCQkJZnVuY3MtPmV4aXRfc3lz Y2FsbCh0cnVzc2luZm8sIE1BWEFSR1MpOworCQkJYnJlYWs7CisJCWNhc2UgU19TSUc6CisJCQlp ZiAodHJ1c3NpbmZvLT5mbGFncyAmIE5PU0lHUykKIAkJCQlicmVhazsKLQkJCWNhc2UgU19FWElU OgotCQkJCWlmICh0cnVzc2luZm8tPmZsYWdzICYgRk9MTE9XRk9SS1MpCi0JCQkJCWZwcmludGYo dHJ1c3NpbmZvLT5vdXRmaWxlLCAiJTVkOiAiLAotCQkJCQkgICAgdHJ1c3NpbmZvLT5waWQpOwot CQkJCWlmICh0cnVzc2luZm8tPmZsYWdzICYgQUJTT0xVVEVUSU1FU1RBTVBTKSB7Ci0JCQkJCXRp bWVzcGVjc3VidCgmdHJ1c3NpbmZvLT5hZnRlciwKLQkJCQkJICAgICZ0cnVzc2luZm8tPnN0YXJ0 X3RpbWUsICZ0aW1lZGlmZik7Ci0JCQkJCWZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiJWxk LiUwOWxkICIsCi0JCQkJCSAgICAobG9uZyl0aW1lZGlmZi50dl9zZWMsCi0JCQkJCSAgICB0aW1l ZGlmZi50dl9uc2VjKTsKLQkJCQl9Ci0JCQkJaWYgKHRydXNzaW5mby0+ZmxhZ3MgJiBSRUxBVElW RVRJTUVTVEFNUFMpIHsKLQkJCQkgIHRpbWVzcGVjc3VidCgmdHJ1c3NpbmZvLT5hZnRlciwKLQkJ CQkgICAgICAmdHJ1c3NpbmZvLT5iZWZvcmUsICZ0aW1lZGlmZik7Ci0JCQkJICBmcHJpbnRmKHRy dXNzaW5mby0+b3V0ZmlsZSwgIiVsZC4lMDlsZCAiLAotCQkJCSAgICAobG9uZyl0aW1lZGlmZi50 dl9zZWMsIHRpbWVkaWZmLnR2X25zZWMpOwotCQkJCX0KLQkJCQlmcHJpbnRmKHRydXNzaW5mby0+ b3V0ZmlsZSwKLQkJCQkgICAgInByb2Nlc3MgZXhpdCwgcnZhbCA9ICVsdVxuIiwgcGZzLnZhbCk7 Ci0JCQkJYnJlYWs7Ci0JCQljYXNlIFNfRVhFQzoKLQkJCQlmdW5jcyA9IHNldF9ldHlwZSh0cnVz c2luZm8pOwotCQkJCWluX2V4ZWMgPSAxOwotCQkJCWJyZWFrOwotCQkJZGVmYXVsdDoKLQkJCQlm cHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwKLQkJCQkgICAgIlByb2Nlc3Mgc3RvcHBlZCBiZWNh dXNlIG9mOiAgJWRcbiIsIGkpOwotCQkJCWJyZWFrOworCQkJaWYgKHRydXNzaW5mby0+ZmxhZ3Mg JiBGT0xMT1dGT1JLUykKKwkJCQlmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIiU1ZDogIiwK KwkJCQkgICAgdHJ1c3NpbmZvLT5waWQpOworCQkJaWYgKHRydXNzaW5mby0+ZmxhZ3MgJiBBQlNP TFVURVRJTUVTVEFNUFMpIHsKKwkJCQl0aW1lc3BlY3N1YnQoJnRydXNzaW5mby0+YWZ0ZXIsCisJ CQkJICAgICZ0cnVzc2luZm8tPnN0YXJ0X3RpbWUsICZ0aW1lZGlmZik7CisJCQkJZnByaW50Zih0 cnVzc2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQgIiwKKwkJCQkgICAgKGxvbmcpdGltZWRpZmYu dHZfc2VjLAorCQkJCSAgICB0aW1lZGlmZi50dl9uc2VjKTsKKwkJCX0KKwkJCWlmICh0cnVzc2lu Zm8tPmZsYWdzICYgUkVMQVRJVkVUSU1FU1RBTVBTKSB7CisJCQkJdGltZXNwZWNzdWJ0KCZ0cnVz c2luZm8tPmFmdGVyLAorCQkJCSAgICAmdHJ1c3NpbmZvLT5iZWZvcmUsICZ0aW1lZGlmZik7CisJ CQkJZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICIlbGQuJTA5bGQgIiwKKwkJCQkgICAgKGxv bmcpdGltZWRpZmYudHZfc2VjLAorCQkJCSAgICB0aW1lZGlmZi50dl9uc2VjKTsKKwkJCX0KKwkJ CXNpZ25hbWUgPSBzdHJzaWcodHJ1c3NpbmZvLT5wcl9kYXRhKTsKKwkJCWZwcmludGYodHJ1c3Np bmZvLT5vdXRmaWxlLAorCQkJICAgICJTSUdOQUwgJXUgKCVzKVxuIiwgdHJ1c3NpbmZvLT5wcl9k YXRhLAorCQkJICAgIHNpZ25hbWUgPT0gTlVMTCA/ICI/IiA6IHNpZ25hbWUpOworCQkJZnJlZShz aWduYW1lKTsKKwkJCWJyZWFrOworCQljYXNlIFNfRVhJVDoKKwkJCWlmICh0cnVzc2luZm8tPmZs YWdzICYgRk9MTE9XRk9SS1MpCisJCQkJZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICIlNWQ6 ICIsCisJCQkJICAgIHRydXNzaW5mby0+cGlkKTsKKwkJCWlmICh0cnVzc2luZm8tPmZsYWdzICYg QUJTT0xVVEVUSU1FU1RBTVBTKSB7CisJCQkJdGltZXNwZWNzdWJ0KCZ0cnVzc2luZm8tPmFmdGVy LAorCQkJCSAgICAmdHJ1c3NpbmZvLT5zdGFydF90aW1lLCAmdGltZWRpZmYpOworCQkJCWZwcmlu dGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiJWxkLiUwOWxkICIsCisJCQkJICAgIChsb25nKXRpbWVk aWZmLnR2X3NlYywKKwkJCQkgICAgdGltZWRpZmYudHZfbnNlYyk7CisJCQl9CisJCQlpZiAodHJ1 c3NpbmZvLT5mbGFncyAmIFJFTEFUSVZFVElNRVNUQU1QUykgeworCQkJICB0aW1lc3BlY3N1YnQo JnRydXNzaW5mby0+YWZ0ZXIsCisJCQkgICAgICAmdHJ1c3NpbmZvLT5iZWZvcmUsICZ0aW1lZGlm Zik7CisJCQkgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiJWxkLiUwOWxkICIsCisJCQkg ICAgKGxvbmcpdGltZWRpZmYudHZfc2VjLCB0aW1lZGlmZi50dl9uc2VjKTsKIAkJCX0KKwkJCWZw cmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLAorCQkJICAgICJwcm9jZXNzIGV4aXQsIHJ2YWwgPSAl dVxuIiwgdHJ1c3NpbmZvLT5wcl9kYXRhKTsKKwkJCWJyZWFrOworCQlkZWZhdWx0OgorCQkJYnJl YWs7CiAJCX0KLQkJaWYgKGlvY3RsKFByb2NmZCwgUElPQ0NPTlQsIHZhbCkgPT0gLTEpIHsKLQkJ CWlmIChraWxsKHRydXNzaW5mby0+cGlkLCAwKSA9PSAtMSAmJiBlcnJubyA9PSBFU1JDSCkKLQkJ CQlicmVhazsKLQkJCWVsc2UKLQkJCQl3YXJuKCJQSU9DQ09OVCIpOwotCQl9Ci0JfSB3aGlsZSAo cGZzLndoeSAhPSBTX0VYSVQpOworCX0gd2hpbGUgKHRydXNzaW5mby0+cHJfd2h5ICE9IFNfRVhJ VCk7CiAJZmZsdXNoKHRydXNzaW5mby0+b3V0ZmlsZSk7CiAJaWYgKHNpZ2V4aXQpIHsKIAkJc3Ry dWN0IHJsaW1pdCBybHA7CkBAIC00MDAsNSArMzYyLDYgQEAKIAkJKHZvaWQpIHNpZ25hbChzaWdl eGl0LCBTSUdfREZMKTsKIAkJKHZvaWQpIGtpbGwoZ2V0cGlkKCksIHNpZ2V4aXQpOwogCX0KKwkK IAlyZXR1cm4gKDApOwogfQo9PT09IC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3Vzci5iaW4v dHJ1c3MvcG93ZXJwYy1mYnNkLmMjMSAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3Uv dHJ1c3MvdXNyLmJpbi90cnVzcy9wb3dlcnBjLWZic2QuYyM0ICh0ZXh0K2tvKSA9PT09IGNvbnRl bnQKQEAgLTQxLDggKzQxLDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5j bHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgorI2luY2x1ZGUgPHN5 cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5jbHVkZSA8bWFjaGlu ZS9yZWcuaD4KQEAgLTYyLDcgKzYxLDYgQEAKICNpbmNsdWRlICJzeXNjYWxsLmgiCiAjaW5jbHVk ZSAiZXh0ZXJuLmgiCiAKLXN0YXRpYyBpbnQgZmQgPSAtMTsKIHN0YXRpYyBpbnQgY3BpZCA9IC0x OwogCiAjaW5jbHVkZSAic3lzY2FsbHMuaCIKQEAgLTEyMCwxOSArMTE4LDEwIEBACiAgIHVuc2ln bmVkIGludCByZWdhcmdzOwogICBzdHJ1Y3Qgc3lzY2FsbCAqc2M7CiAKLSAgaWYgKGZkID09IC0x IHx8IHRydXNzaW5mby0+cGlkICE9IGNwaWQpIHsKLSAgICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVk L3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7Ci0gICAgZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKTsKLSAg ICBpZiAoZmQgPT0gLTEpIHsKLSAgICAgIGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0g Q0FOTk9UIE9QRU4gUkVHSVNURVJTIC0tXG4iKTsKLSAgICAgIHJldHVybjsKLSAgICB9Ci0gICAg Y3BpZCA9IHRydXNzaW5mby0+cGlkOwotICB9CisgIGNwaWQgPSB0cnVzc2luZm8tPmN1cnRocmVh ZC0+dGlkOwogCiAgIGNsZWFyX2ZzYygpOwotICBsc2VlayhmZCwgMEwsIDApOwotICBpZiAocmVh ZChmZCwgJnJlZ3MsIHNpemVvZihyZWdzKSkgIT0gc2l6ZW9mKHJlZ3MpKSB7CisgIGlmIChwdHJh Y2UoUFRfR0VUUkVHUywgY3BpZCwgKGNhZGRyX3QpJnJlZ3MsIDApIDwgMCkgewogICAgIGZwcmlu dGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIFJFQUQgUkVHSVNURVJTIC0tXG4iKTsK ICAgICByZXR1cm47CiAgIH0KQEAgLTE2Nyw3ICsxNTYsNyBAQAogICAgIHx8ICFzdHJjbXAoZnNj Lm5hbWUsICJyZm9yayIpCiAgICAgfHwgIXN0cmNtcChmc2MubmFtZSwgInZmb3JrIikpKSkKICAg ewotICAgIHRydXNzaW5mby0+aW5fZm9yayA9IDE7CisgICAgdHJ1c3NpbmZvLT5jdXJ0aHJlYWQt PmluX2ZvcmsgPSAxOwogICB9CiAKICAgaWYgKG5hcmdzID09IDApCkBAIC0xNzYsOSArMTY1LDE2 IEBACiAgIGZzYy5hcmdzID0gbWFsbG9jKCgxK25hcmdzKSAqIHNpemVvZih1bnNpZ25lZCBsb25n KSk7CiAKICAgaWYgKG5hcmdzID4gcmVnYXJncykgeworICAgIHN0cnVjdCBwdHJhY2VfaW9fZGVz YyBpb3JlcXVlc3Q7CiAgICAgbWVtbW92ZSgmZnNjLmFyZ3NbMF0sIGFyZ3MsIHJlZ2FyZ3MgKiBz aXplb2YoZnNjLmFyZ3NbMF0pKTsKLSAgICBsc2VlayhQcm9jZmQsIHJlZ3MuZml4cmVnWzFdICsg OCwgU0VFS19TRVQpOwotICAgIHJlYWQoUHJvY2ZkLCAmZnNjLmFyZ3NbcmVnYXJnc10sIChuYXJn cyAtIHJlZ2FyZ3MpICogc2l6ZW9mKGZzYy5hcmdzWzBdKSk7CisKKyAgICBpb3JlcXVlc3QucGlv ZF9vcCA9IFBJT0RfUkVBRF9EOworICAgIGlvcmVxdWVzdC5waW9kX29mZnMgPSAodm9pZCAqKShy ZWdzLmZpeHJlZ1sxXSArIDgpOworICAgIGlvcmVxdWVzdC5waW9kX2FkZHIgPSAmZnNjLmFyZ3Nb cmVnYXJnc107CisgICAgaW9yZXF1ZXN0LnBpb2RfbGVuID0gKG5hcmdzIC0gcmVnYXJncykgKiBz aXplb2YoZnNjLmFyZ3NbMF0pOworICAgIHB0cmFjZShQVF9JTywgY3BpZCwgKGNhZGRyX3QpJmlv cmVxdWVzdCwgMCk7CisgICAgaWYgKGlvcmVxdWVzdC5waW9kX2xlbiA9PSAwKQorICAgICAgIHJl dHVybjsKICAgfSBlbHNlIHsKICAgICBtZW1tb3ZlKCZmc2MuYXJnc1swXSwgYXJncywgbmFyZ3Mg KiBzaXplb2YoZnNjLmFyZ3NbMF0pKTsKICAgfQpAQCAtMjIwLDcgKzIxNiw3IEBACiAJICAgICAg aSA8IChmc2MubmFyZ3MgLSAxKSA/ICIsIiA6ICIiKTsKICNlbmRpZgogICAgICAgaWYgKHNjICYm ICEoc2MtPmFyZ3NbaV0udHlwZSAmIE9VVCkpIHsKLQlmc2Muc19hcmdzW2ldID0gcHJpbnRfYXJn KFByb2NmZCwgJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZvKTsKKwlmc2Muc19h cmdzW2ldID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwgZnNjLmFyZ3MsIDAsIHRydXNzaW5mbyk7 CiAgICAgICB9CiAgICAgfQogI2lmIERFQlVHCkBAIC0yNzUsMjUgKzI3MSwxNSBAQAogbG9uZwog cG93ZXJwY19zeXNjYWxsX2V4aXQoc3RydWN0IHRydXNzaW5mbyAqdHJ1c3NpbmZvLCBpbnQgc3lz Y2FsbF9udW0gX191bnVzZWQpCiB7Ci0gIGNoYXIgYnVmWzMyXTsKICAgc3RydWN0IHJlZyByZWdz OwogICBsb25nIHJldHZhbDsKICAgaW50IGk7CiAgIGludCBlcnJvcnA7CiAgIHN0cnVjdCBzeXNj YWxsICpzYzsKIAotICBpZiAoZmQgPT0gLTEgfHwgdHJ1c3NpbmZvLT5waWQgIT0gY3BpZCkgewot ICAgIHNwcmludGYoYnVmLCAiL3Byb2MvJWQvcmVncyIsIHRydXNzaW5mby0+cGlkKTsKLSAgICBm ZCA9IG9wZW4oYnVmLCBPX1JET05MWSk7Ci0gICAgaWYgKGZkID09IC0xKSB7Ci0gICAgICBmcHJp bnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIi0tIENBTk5PVCBPUEVOIFJFR0lTVEVSUyAtLVxuIik7 Ci0gICAgICByZXR1cm4gKC0xKTsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwot ICB9CisgIGNwaWQgPSB0cnVzc2luZm8tPmN1cnRocmVhZC0+dGlkOwogCi0gIGxzZWVrKGZkLCAw TCwgMCk7Ci0gIGlmIChyZWFkKGZkLCAmcmVncywgc2l6ZW9mKHJlZ3MpKSAhPSBzaXplb2YocmVn cykpIHsKKyAgaWYgKHB0cmFjZShQVF9HRVRSRUdTLCBjcGlkLCAoY2FkZHJfdCkmcmVncywgMCkg PCAwKSB7CiAgICAgZnByaW50Zih0cnVzc2luZm8tPm91dGZpbGUsICJcbiIpOwogICAgIHJldHVy biAoLTEpOwogICB9CkBAIC0zMzIsNyArMzE4LDcgQEAKIAlpZiAoZXJyb3JwKQogCSAgYXNwcmlu dGYoJnRlbXAsICIweCVseCIsIGZzYy5hcmdzW3NjLT5hcmdzW2ldLm9mZnNldF0pOwogCWVsc2UK LQkgIHRlbXAgPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFyZ3NbaV0sIGZzYy5hcmdzLCByZXR2 YWwsIHRydXNzaW5mbyk7CisJICB0ZW1wID0gcHJpbnRfYXJnKCZzYy0+YXJnc1tpXSwgZnNjLmFy Z3MsIHJldHZhbCwgdHJ1c3NpbmZvKTsKIAlmc2Muc19hcmdzW2ldID0gdGVtcDsKICAgICAgIH0K ICAgICB9Cj09PT0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9zcmMvdXNyLmJpbi90cnVzcy9zZXR1 cC5jIzExICh0ZXh0K2tvKSAtIC8vZGVwb3QvdXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3Ry dXNzL3NldHVwLmMjNyAodGV4dCtrbykgPT09PSBjb250ZW50CkBAIC0zOCwxMSArMzgsMTIgQEAK ICAqLwogCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+Ci0jaW5jbHVkZSA8c3lzL2lvY3RsLmg+Ci0j aW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUg PHN5cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvd2FpdC5oPgogCiAjaW5jbHVkZSA8ZXJyLmg+ CisjaW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxmY250bC5oPgogI2luY2x1ZGUgPHNpZ25h bC5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CkBAIC01MSwxMCArNTIsMTIgQEAKICNpbmNsdWRlIDx0 aW1lLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKKyNpbmNsdWRlIDxtYWNoaW5lL3JlZy5oPgor CiAjaW5jbHVkZSAidHJ1c3MuaCIKICNpbmNsdWRlICJleHRlcm4uaCIKIAotc3RhdGljIGludCBl dmZsYWdzID0gMDsKK3N0YXRpYyBpbnQgY2hpbGRfcGlkOwogCiAvKgogICogc2V0dXBfYW5kX3dh aXQoKSBpcyBjYWxsZWQgdG8gc3RhcnQgYSBwcm9jZXNzLiAgQWxsIGl0IHJlYWxseSBkb2VzCkBA IC02Niw3NSArNjksMjggQEAKIGludAogc2V0dXBfYW5kX3dhaXQoY2hhciAqY29tbWFuZFtdKQog ewotCXN0cnVjdCBwcm9jZnNfc3RhdHVzIHBmczsKLQljaGFyIGJ1ZlszMl07Ci0JaW50IGZkOwog CWludCBwaWQ7Ci0JaW50IGZsYWdzOwotCWludCBsb29wOworCWludCB3YWl0dmFsOwogCi0JcGlk ID0gZm9yaygpOworCXBpZCA9IHZmb3JrKCk7CiAJaWYgKHBpZCA9PSAtMSkgewogCQllcnIoMSwg ImZvcmsgZmFpbGVkIik7CiAJfQogCWlmIChwaWQgPT0gMCkgewkvKiBDaGlsZCAqLwotCQlpbnQg bWFzayA9IFNfRVhFQyB8IFNfRVhJVDsKLQkJZmQgPSBvcGVuKCIvcHJvYy9jdXJwcm9jL21lbSIs IE9fV1JPTkxZKTsKLQkJaWYgKGZkID09IC0xKQotCQkJZXJyKDIsICJjYW5ub3Qgb3BlbiAvcHJv Yy9jdXJwcm9jL21lbSIpOwotCQlmY250bChmZCwgRl9TRVRGRCwgMSk7Ci0JCWlmIChpb2N0bChm ZCwgUElPQ0JJUywgbWFzaykgPT0gLTEpCi0JCQllcnIoMywgIlBJT0NCSVMiKTsKLQkJZmxhZ3Mg PSBQRl9MSU5HRVI7Ci0JCS8qCi0JCSAqIFRoZSBQRl9MSU5HRVIgZmxhZyB0ZWxscyBwcm9jZnMg bm90IHRvIHdha2UgdXAgdGhlCi0JCSAqIHByb2Nlc3Mgb24gbGFzdCBjbG9zZTsgbm9ybWFsbHks IHRoaXMgaXMgdGhlIGJlaGF2aW91cgotCQkgKiB3ZSB3YW50LgotCQkgKi8KLQkJaWYgKGlvY3Rs KGZkLCBQSU9DU0ZMLCBmbGFncykgPT0gLTEpCi0JCQl3YXJuKCJjYW5ub3Qgc2V0IFBGX0xJTkdF UiIpOworCQlwdHJhY2UoUFRfVFJBQ0VfTUUsIDAsIDAsIDApOworCQlzZXRwZ2lkICgwLCAwKTsg CiAJCWV4ZWN2cChjb21tYW5kWzBdLCBjb21tYW5kKTsKLQkJbWFzayA9IH4wOwotCQlpb2N0bChm ZCwgUElPQ0JJQywgfjApOwotCQllcnIoNCwgImV4ZWN2cCAlcyIsIGNvbW1hbmRbMF0pOworCQll cnIoMSwgImV4ZWN2cCAlcyIsIGNvbW1hbmRbMF0pOwogCX0KKwkKIAkvKiBPbmx5IGluIHRoZSBw YXJlbnQgaGVyZSAqLwotCi0JaWYgKHdhaXRwaWQocGlkLCBOVUxMLCBXTk9IQU5HKSAhPSAwKSB7 Ci0JCS8qCi0JCSAqIFByb2Nlc3MgZXhpdGVkIGJlZm9yZSBpdCBnb3QgdG8gdXMgLS0gbWVhbmlu ZyB0aGUgZXhlYyBmYWlsZWQKLQkJICogbWlzZXJhYmx5IC0tIHNvIHdlIGp1c3QgcXVpZXRseSBl eGl0LgotCQkgKi8KLQkJZXhpdCgxKTsKKwlpZiAod2FpdHBpZChwaWQsICZ3YWl0dmFsLCAwKSA8 IC0xKSB7CisJCWVycigxLCAidW5leHBlY3Qgc3RvcCBpbiB3YWl0cGlkIik7CisJCXJldHVybiAw OwogCX0KIAotCXNwcmludGYoYnVmLCAiL3Byb2MvJWQvbWVtIiwgcGlkKTsKLQotCS8qIFRyeSA2 IHRpbWVzIHRvIHRyYWNlIG91ciBjaGlsZCwgd2FpdGluZyAxLzIgc2Vjb25kIGVhY2ggdGltZSAq LwotCWZvciAobG9vcD02IDs7IGxvb3AtLSkgewotCQlpZiAobG9vcCAhPSA2KQotCQkJdXNsZWVw KDUwMDAwMCk7Ci0JCWlmICgoZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKSkgPT0gLTEpIHsKLQkJCWlm IChsb29wID4gMCkKLQkJCQljb250aW51ZTsKLQkJCWVsc2UKLQkJCQllcnIoNSwgImNhbm5vdCBv cGVuMSAlcyIsIGJ1Zik7Ci0JCX0KLQkJaWYgKGlvY3RsKGZkLCBQSU9DV0FJVCwgJnBmcykgPT0g LTEpIHsKLQkJCWlmIChsb29wID49IDApCi0JCQkJY29udGludWU7Ci0JCQllbHNlCi0JCQkJZXJy KDYsICJQSU9DV0FJVCIpOwotCQl9Ci0JCWlmIChwZnMud2h5ID09IFNfRVhJVCkgewotCQkJd2Fy bngoInByb2Nlc3MgZXhpdGVkIGJlZm9yZSBleGVjJ2luZyIpOwotCQkJaW9jdGwoZmQsIFBJT0ND T05ULCAwKTsKLQkJCXdhaXQoMCk7Ci0JCQlleGl0KDcpOwotCQl9IGVsc2UKLQkJCWJyZWFrOwot CX0KLQljbG9zZShmZCk7CisJY2hpbGRfcGlkID0gcGlkOworCQogCXJldHVybiAocGlkKTsKIH0K IApAQCAtMTQ1LDQ1ICsxMDEsMjQgQEAKICAqLwogCiBpbnQKLXN0YXJ0X3RyYWNpbmcoaW50IHBp ZCwgaW50IGZhaWxpc2ZhdGFsLCBpbnQgZXZlbnRmbGFncywgaW50IGZsYWdzKQorc3RhcnRfdHJh Y2luZyhpbnQgcGlkKQogewotCWludCBmZDsKLQljaGFyIGJ1ZlszMl07Ci0Jc3RydWN0IHByb2Nm c19zdGF0dXMgdG1wOworCWludCB3YWl0dmFsOworCWludCByZXQ7CisJaW50IHJldHJ5ID0gMTA7 CiAKLQlzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL21lbSIsIHBpZCk7Ci0JLyogdXNsZWVwKDUwMDAw MCk7ICovCisJZG8geworCQlyZXQgPSBwdHJhY2UoUFRfQVRUQUNILCBwaWQsIE5VTEwsIDApOwor CQl1c2xlZXAoMjAwKTsKKwl9IHdoaWxlKHJldCAmJiByZXRyeS0tID4gMCk7CisJaWYgKHJldCkK KwkJZXJyKDEsICJjYW4gbm90IGF0dGFjaCB0byB0YXJnZXQgcHJvY2VzcyIpOwogCi0JZmQgPSBv cGVuKGJ1ZiwgT19SRFdSKTsKLQlpZiAoZmQgPT0gLTEpIHsKLQkJLyoKLQkJICogVGhlIHByb2Nl c3MgbWF5IGhhdmUgcnVuIGF3YXkgYmVmb3JlIHdlIGNvdWxkIHN0YXJ0IC0tIHRoaXMKLQkJICog aGFwcGVucyB3aXRoIFNVR0lEIHByb2dyYW1zLiAgU28gd2UgbmVlZCB0byBzZWUgaWYgaXQgc3Rp bGwKLQkJICogZXhpc3RzIGJlZm9yZSB3ZSBjb21wbGFpbiBiaXR0ZXJseS4KLQkJICovCi0JCWlm ICghZmFpbGlzZmF0YWwgJiYga2lsbChwaWQsIDApID09IC0xKQotCQkJcmV0dXJuICgtMSk7Ci0J CWVycig4LCAiY2Fubm90IG9wZW4yICVzIiwgYnVmKTsKLQl9CisJY2hpbGRfcGlkID0gcGlkOwkK KwlpZiAod2FpdHBpZChwaWQsICZ3YWl0dmFsLCAwKSA8IC0xKSAKKwkJZXJyKDEsICJVbmV4cGVj dCBzdG9wIGluIHdhaXRwaWQiKTsKIAotCWlmIChpb2N0bChmZCwgUElPQ1NUQVRVUywgJnRtcCkg PT0gLTEpIHsKLQkJZXJyKDEwLCAiY2Fubm90IGdldCBwcm9jZnMgc3RhdHVzIHN0cnVjdCIpOwot CX0KLQlldmZsYWdzID0gdG1wLmV2ZW50czsKLQotCWlmIChpb2N0bChmZCwgUElPQ0JJUywgZXZl bnRmbGFncykgPT0gLTEpCi0JCWVycig5LCAiY2Fubm90IHNldCBwcm9jZnMgZXZlbnQgYml0IG1h c2siKTsKLQotCS8qCi0JICogVGhpcyBjbGVhcnMgdGhlIFBGX0xJTkdFUiBzZXQgYWJvdmUgaW4g c2V0dXBfYW5kX3dhaXQoKTsKLQkgKiBpZiB0cnVzcyBoYXBwZW5zIHRvIGRpZSBiZWZvcmUgdGhp cywgdGhlbiB0aGUgcHJvY2VzcwotCSAqIG5lZWRzIHRvIGJlIHdva2VuIHVwIHZpYSBwcm9jY3Rs LgotCSAqLwotCi0JaWYgKGlvY3RsKGZkLCBQSU9DU0ZMLCBmbGFncykgPT0gLTEpCi0JCXdhcm4o ImNhbm5vdCBjbGVhciBQRl9MSU5HRVIiKTsKLQotCXJldHVybiAoZmQpOworCXJldHVybiAoMCk7 CiB9CiAKIC8qCkBAIC0xOTMsMTAgKzEyOCw3NCBAQAogICogcHJvY2Vzcy4KICAqLwogdm9pZAot cmVzdG9yZV9wcm9jKGludCBzaWdubyBfX3VudXNlZCkgeworcmVzdG9yZV9wcm9jKGludCBzaWdu byBfX3VudXNlZCkKK3sKKwlpbnQgd2FpdHZhbDsKKwkKKwlraWxsKGNoaWxkX3BpZCwgU0lHU1RP UCk7CisJaWYgKHdhaXRwaWQoY2hpbGRfcGlkLCAmd2FpdHZhbCwgMCkgPCAtMSkKKwkJZXJyKDEs ICJVbmV4cGVjdGVkIHN0b3AgaW4gd2FpdHBpZCIpOwogCi0JaW9jdGwoUHJvY2ZkLCBQSU9DQklD LCB+MCk7Ci0JaWYgKGV2ZmxhZ3MpCi0JCWlvY3RsKFByb2NmZCwgUElPQ0JJUywgZXZmbGFncyk7 CisJaWYgKHB0cmFjZShQVF9ERVRBQ0gsIGNoaWxkX3BpZCwgKGNhZGRyX3QpMSwgMCkgPCAwKQor CQllcnIoMSwgIkNhbiBub3QgZGV0YWNoIHRoZSBwcm9jZXNzIik7CisJCisJa2lsbChjaGlsZF9w aWQsIFNJR0NPTlQpOwogCWV4aXQoMCk7CiB9CisKK3ZvaWQgZmluZF90aHJlYWQoc3RydWN0IHRy dXNzaW5mbyAqaW5mbywgbHdwaWRfdCBsd3BpZCkKK3sKKwlpbmZvLT5jdXJ0aHJlYWQgPSBOVUxM OworCXN0cnVjdCB0aHJlYWRpbmZvICpucDsKKwlTTElTVF9GT1JFQUNIKG5wLCAmaW5mby0+dGhy ZWFkbGlzdCwgZW50cmllcykgeworCWlmIChucC0+dGlkID09IGx3cGlkKSB7CisJCWluZm8tPmN1 cnRocmVhZCA9IG5wOworCQlyZXR1cm47CisJCX0KKwl9CisKKwlucCA9IChzdHJ1Y3QgdGhyZWFk aW5mbyAqKW1hbGxvYyhzaXplb2Yoc3RydWN0IHRocmVhZGluZm8pKTsKKwlpZiAobnAgPT0gTlVM TCkKKwkJZXJyeCgxLCAibWFsbG9jKCkgZmFpbGVkIik7CisJbnAtPnRpZCA9IGx3cGlkOworCW5w LT5pbl9mb3JrID0gMDsKKwlucC0+aW5fc3lzY2FsbCA9IDA7CisJU0xJU1RfSU5TRVJUX0hFQUQo JmluZm8tPnRocmVhZGxpc3QsIG5wLCBlbnRyaWVzKTsKKwlpbmZvLT5jdXJ0aHJlYWQgPSBucDsK K30KKwordm9pZCB3YWl0ZXZlbnQoc3RydWN0IHRydXNzaW5mbyAqaW5mbykKK3sKKwlpbnQgd2Fp dHZhbDsKKwkKKwlwdHJhY2UoUFRfU1lTQ0FMTCwgaW5mby0+cGlkLCAoY2FkZHJfdCkxLCAwKTsK KworCWlmICh3YWl0cGlkKGluZm8tPnBpZCwgJndhaXR2YWwsIDApIDwgLTEpIHsKKwkJZXJyKDEs ICJVbmV4cGVjdGVkIHN0b3AgaW4gd2FpdHBpZCIpOworCX0KKwkKKwlpZiAoV0lGQ09OVElOVUVE KHdhaXR2YWwpKSB7CisJCWluZm8tPnByX3doeSA9IFNfTk9ORTsKKwkJcmV0dXJuOworCX0KKwlp ZiAoV0lGRVhJVEVEKHdhaXR2YWwpKSB7CisJCWluZm8tPnByX3doeSA9IFNfRVhJVDsKKwkJaW5m by0+cHJfZGF0YSA9IFdFWElUU1RBVFVTKHdhaXR2YWwpOworCQlyZXR1cm47CisJfQorCWlmIChX SUZTVE9QUEVEKHdhaXR2YWwpIHx8IChXSUZTSUdOQUxFRCh3YWl0dmFsKSkpIHsKKwkJc3RydWN0 IHB0cmFjZV9sd3BpbmZvIGx3cGluZm87CisJCXB0cmFjZShQVF9MV1BJTkZPLCBpbmZvLT5waWQs IChjYWRkcl90KSZsd3BpbmZvLCBzaXplb2YobHdwaW5mbykpOwkKKwkJZmluZF90aHJlYWQoaW5m bywgbHdwaW5mby5wbF9sd3BpZCk7CisJCXN3aXRjaChXU1RPUFNJRyh3YWl0dmFsKSkgeworCQlj YXNlIFNJR1RSQVA6CisJCQlpbmZvLT5wcl93aHkgPSBpbmZvLT5jdXJ0aHJlYWQtPmluX3N5c2Nh bGw/U19TQ1g6U19TQ0U7CisJCQlpbmZvLT5jdXJ0aHJlYWQtPmluX3N5c2NhbGwgPSAxIC0gaW5m by0+Y3VydGhyZWFkLT5pbl9zeXNjYWxsOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQlpbmZv LT5wcl93aHkgPSBTX1NJRzsKKwkJCWluZm8tPnByX2RhdGEgPSBXU1RPUFNJRyh3YWl0dmFsKTsK KwkJCWJyZWFrOworCQl9CisJfQorfQo9PT09IC8vZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3Vz ci5iaW4vdHJ1c3Mvc3BhcmM2NC1mYnNkLmMjOSAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93 YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy9zcGFyYzY0LWZic2QuYyMzICh0ZXh0K2tvKSA9PT09 IGNvbnRlbnQKQEAgLTQ1LDggKzQ1LDcgQEAKICAqLwogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+ Ci0jaW5jbHVkZSA8c3lzL2lvY3RsLmg+Ci0jaW5jbHVkZSA8c3lzL3Bpb2N0bC5oPgorI2luY2x1 ZGUgPHN5cy9wdHJhY2UuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogCiAjaW5jbHVkZSA8 bWFjaGluZS9mcmFtZS5oPgpAQCAtNjgsNyArNjcsNiBAQAogI2luY2x1ZGUgInN5c2NhbGwuaCIK ICNpbmNsdWRlICJleHRlcm4uaCIKIAotc3RhdGljIGludCBmZCA9IC0xOwogc3RhdGljIGludCBj cGlkID0gLTE7CiAKICNpbmNsdWRlICJzeXNjYWxscy5oIgpAQCAtMTE4LDI2ICsxMTYsMTggQEAK IAogdm9pZAogc3BhcmM2NF9zeXNjYWxsX2VudHJ5KHN0cnVjdCB0cnVzc2luZm8gKnRydXNzaW5m bywgaW50IG5hcmdzKSB7Ci0gIGNoYXIgYnVmWzMyXTsKICAgc3RydWN0IHJlZyByZWdzOwogICBp bnQgc3lzY2FsbF9udW07CiAgIGludCBpOwogICBzdHJ1Y3Qgc3lzY2FsbCAqc2M7CiAgIGludCBp bmRpciA9IDA7CS8qIGluZGlyZWN0IHN5c3RlbSBjYWxsICovCisgIHN0cnVjdCBwdHJhY2VfaW9f ZGVzYyBpb3JlcXVlc3Q7CiAKLSAgaWYgKGZkID09IC0xIHx8IHRydXNzaW5mby0+cGlkICE9IGNw aWQpIHsKLSAgICBzcHJpbnRmKGJ1ZiwgIi9wcm9jLyVkL3JlZ3MiLCB0cnVzc2luZm8tPnBpZCk7 Ci0gICAgZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAg IGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0t XG4iKTsKLSAgICAgIHJldHVybjsKLSAgICB9Ci0gICAgY3BpZCA9IHRydXNzaW5mby0+cGlkOwot ICB9CisgIGNwaWQgPSB0cnVzc2luZm8tPmN1cnRocmVhZC0+dGlkOwogCiAgIGNsZWFyX2ZzYygp OwotICBsc2VlayhmZCwgMEwsIDApOwotICBpZiAocmVhZChmZCwgJnJlZ3MsIHNpemVvZihyZWdz KSkgIT0gc2l6ZW9mKHJlZ3MpKSB7CisgIAorICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQs IChjYWRkcl90KSZyZWdzLCAwKSA8IDApIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0Zmls ZSwgIi0tIENBTk5PVCBSRUFEIFJFR0lTVEVSUyAtLVxuIik7CiAgICAgcmV0dXJuOwogICB9CkBA IC0xNjUsNyArMTU1LDcgQEAKICAgICB8fCAhc3RyY21wKGZzYy5uYW1lLCAicmZvcmsiKQogICAg IHx8ICFzdHJjbXAoZnNjLm5hbWUsICJ2Zm9yayIpKSkpCiAgIHsKLSAgICB0cnVzc2luZm8tPmlu X2ZvcmsgPSAxOworICAgIHRydXNzaW5mby0+Y3VydGhyZWFkLT5pbl9mb3JrID0gMTsKICAgfQog CiAgIGlmIChuYXJncyA9PSAwKQpAQCAtMTg2LDkgKzE3NiwxNCBAQAogCSAqIG9uIHRoZSBzdGFj aywgYXMgaXMgbm9ybWFsIGZvciBvdGhlciBwcm9jZXNzb3JzLgogCSAqIFRoZSBmYWxsLXRocm91 Z2ggZm9yIGFsbCBvZiB0aGVzZSBpcyBkZWxpYmVyYXRlISEhCiAJICovCi0JbHNlZWsoUHJvY2Zk LCByZWdzLnJfb3V0WzZdICsgU1BPRkYgKwotCSAgICBvZmZzZXRvZihzdHJ1Y3QgZnJhbWUsIGZy X3BhZFs2XSksIFNFRUtfU0VUKTsKLQlyZWFkKGZkLCAmZnNjLmFyZ3NbNl0sIChuYXJncyAtIDYp ICogc2l6ZW9mKGZzYy5hcmdzWzBdKSk7CisJaW9yZXF1ZXN0LnBpb2Rfb3AgPSBQSU9EX1JFQURf RDsKKwlpb3JlcXVlc3QucGlvZF9vZmZzID0gKHZvaWQgKikocmVncy5yX291dFs2XSArIFNQT0ZG ICsKKyAgICAgICAgICAgIG9mZnNldG9mKHN0cnVjdCBmcmFtZSwgZnJfcGFkWzZdKTsKKwlpb3Jl cXVlc3QucGlvZF9hZGRyID0gJmZzYy5hcmdzWzZdOworCWlvcmVxdWVzdC5waW9kX2xlbiA9IChu YXJncyAtIDYpICogc2l6ZW9mKGZzYy5hcmdzWzBdKTsKKwlwdHJhY2UoUFRfSU8sIGNwaWQsIChj YWRkcl90KSZpb3JlcXVlc3QsIDApOworCWlmIChpb3JlcXVlc3QucGlvZF9sZW4gPT0gMCkgcmV0 dXJuOworCiAgIGNhc2UgNjoJZnNjLmFyZ3NbNV0gPSByZWdzLnJfb3V0WzVdOwogICBjYXNlIDU6 CWZzYy5hcmdzWzRdID0gcmVncy5yX291dFs0XTsKICAgY2FzZSA0Oglmc2MuYXJnc1szXSA9IHJl Z3Mucl9vdXRbM107CkBAIC0yNDAsNyArMjM1LDcgQEAKIAkgICAgICBpIDwgKGZzYy5uYXJncyAt IDEpID8gIiwiIDogIiIpOwogI2VuZGlmCiAgICAgICBpZiAoc2MgJiYgIShzYy0+YXJnc1tpXS50 eXBlICYgT1VUKSkgewotCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9hcmcoUHJvY2ZkLCAmc2MtPmFy Z3NbaV0sIGZzYy5hcmdzLCAwLCB0cnVzc2luZm8pOworCWZzYy5zX2FyZ3NbaV0gPSBwcmludF9h cmcoJnNjLT5hcmdzW2ldLCBmc2MuYXJncywgMCwgdHJ1c3NpbmZvKTsKICAgICAgIH0KICAgICB9 CiAjaWYgREVCVUcKQEAgLTMwMiwxOCArMjk3LDkgQEAKICAgaW50IGVycm9ycDsKICAgc3RydWN0 IHN5c2NhbGwgKnNjOwogCi0gIGlmIChmZCA9PSAtMSB8fCB0cnVzc2luZm8tPnBpZCAhPSBjcGlk KSB7Ci0gICAgc3ByaW50ZihidWYsICIvcHJvYy8lZC9yZWdzIiwgdHJ1c3NpbmZvLT5waWQpOwot ICAgIGZkID0gb3BlbihidWYsIE9fUkRPTkxZKTsKLSAgICBpZiAoZmQgPT0gLTEpIHsKLSAgICAg IGZwcmludGYodHJ1c3NpbmZvLT5vdXRmaWxlLCAiLS0gQ0FOTk9UIE9QRU4gUkVHSVNURVJTIC0t XG4iKTsKLSAgICAgIHJldHVybiAoLTEpOwotICAgIH0KLSAgICBjcGlkID0gdHJ1c3NpbmZvLT5w aWQ7Ci0gIH0KKyAgY3BpZCA9IHRydXNzaW5mby0+Y3VydGhyZWFkLT50aWQ7CiAKLSAgbHNlZWso ZmQsIDBMLCAwKTsKLSAgaWYgKHJlYWQoZmQsICZyZWdzLCBzaXplb2YocmVncykpICE9IHNpemVv ZihyZWdzKSkgeworICBpZiAocHRyYWNlKFBUX0dFVFJFR1MsIGNwaWQsIChjYWRkcl90KSZyZWdz LCAwKSA8IDApIHsKICAgICBmcHJpbnRmKHRydXNzaW5mby0+b3V0ZmlsZSwgIlxuIik7CiAgICAg cmV0dXJuICgtMSk7CiAgIH0KQEAgLTM0NCw3ICszMzAsNyBAQAogCWlmIChlcnJvcnApCiAJICBh c3ByaW50ZigmdGVtcCwgIjB4JWx4IiwgZnNjLmFyZ3Nbc2MtPmFyZ3NbaV0ub2Zmc2V0XSk7CiAJ ZWxzZQotCSAgdGVtcCA9IHByaW50X2FyZyhQcm9jZmQsICZzYy0+YXJnc1tpXSwgZnNjLmFyZ3Ms IHJldHZhbCwgdHJ1c3NpbmZvKTsKKwkgIHRlbXAgPSBwcmludF9hcmcoJnNjLT5hcmdzW2ldLCBm c2MuYXJncywgcmV0dmFsLCB0cnVzc2luZm8pOwogCWZzYy5zX2FyZ3NbaV0gPSB0ZW1wOwogICAg ICAgfQogICAgIH0KPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmluL3RydXNz L3N5c2NhbGwuaCMxMiAodGV4dCtrbykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNy LmJpbi90cnVzcy9zeXNjYWxsLmgjMiAodGV4dCtrbykgPT09PSBjb250ZW50CkBAIC02MSw3ICs2 MSw3IEBACiAKIHN0cnVjdCBzeXNjYWxsICpnZXRfc3lzY2FsbChjb25zdCBjaGFyKik7CiBjaGFy ICpnZXRfc3RyaW5nKGludCwgdm9pZCosIGludCk7Ci1jaGFyICpwcmludF9hcmcoaW50LCBzdHJ1 Y3Qgc3lzY2FsbF9hcmdzICosIHVuc2lnbmVkIGxvbmcqLCBsb25nLCBzdHJ1Y3QgdHJ1c3NpbmZv ICopOworY2hhciAqcHJpbnRfYXJnKHN0cnVjdCBzeXNjYWxsX2FyZ3MgKiwgdW5zaWduZWQgbG9u ZyosIGxvbmcsIHN0cnVjdCB0cnVzc2luZm8gKik7CiB2b2lkIHByaW50X3N5c2NhbGwoc3RydWN0 IHRydXNzaW5mbyAqLCBjb25zdCBjaGFyICosIGludCwgY2hhciAqKik7CiB2b2lkIHByaW50X3N5 c2NhbGxfcmV0KHN0cnVjdCB0cnVzc2luZm8gKiwgY29uc3QgY2hhciAqLCBpbnQsIGNoYXIgKios IGludCwKICAgICBsb25nKTsKPT09PSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy91c3IuYmlu L3RydXNzL3N5c2NhbGxzLmMjMzggKHRleHQra28pIC0gLy9kZXBvdC91c2VyL2hvd2FyZHN1L3Ry dXNzL3Vzci5iaW4vdHJ1c3Mvc3lzY2FsbHMuYyMyICh0ZXh0K2tvKSA9PT09IGNvbnRlbnQKQEAg LTQxLDYgKzQxLDcgQEAKIAogI2luY2x1ZGUgPHN5cy9tbWFuLmg+CiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+CisjaW5jbHVkZSA8c3lzL3B0cmFjZS5oPgogI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4K ICNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy91bi5oPgpAQCAtNDA4LDkgKzQw OSwxMyBAQAogICovCiAKIHN0YXRpYyBpbnQKLWdldF9zdHJ1Y3QoaW50IHByb2NmZCwgdm9pZCAq b2Zmc2V0LCB2b2lkICpidWYsIGludCBsZW4pIHsKLQotCWlmIChwcmVhZChwcm9jZmQsIGJ1Ziwg bGVuLCAodWludHB0cl90KW9mZnNldCkgIT0gbGVuKQorZ2V0X3N0cnVjdChpbnQgcGlkLCB2b2lk ICpvZmZzZXQsIHZvaWQgKmJ1ZiwgaW50IGxlbikgeworCXN0cnVjdCBwdHJhY2VfaW9fZGVzYyBp b3JlcXVlc3Q7CisJaW9yZXF1ZXN0LnBpb2Rfb3AgPSBQSU9EX1JFQURfRDsKKwlpb3JlcXVlc3Qu cGlvZF9vZmZzID0gb2Zmc2V0OworCWlvcmVxdWVzdC5waW9kX2FkZHIgPSBidWY7CisJaW9yZXF1 ZXN0LnBpb2RfbGVuID0gbGVuOworCWlmIChwdHJhY2UoUFRfSU8sIHBpZCwgKGNhZGRyX3QpJmlv cmVxdWVzdCwgMCkgIT0gbGVuKQogCQlyZXR1cm4gLTE7CiAJcmV0dXJuIDA7CiB9CkBAIC00MjMs MzcgKzQyOCwyMSBAQAogICovCiAKIGNoYXIgKgotZ2V0X3N0cmluZyhpbnQgcHJvY2ZkLCB2b2lk ICpvZmZzZXQsIGludCBtYXgpIHsKK2dldF9zdHJpbmcoaW50IHBpZCwgdm9pZCAqb2Zmc2V0LCBp bnQgbWF4KSB7CiAJY2hhciAqYnVmOwotCWludCBzaXplLCBsZW4sIGMsIGZkOwotCUZJTEUgKnA7 CisJc3RydWN0IHB0cmFjZV9pb19kZXNjIGlvcmVxdWVzdDsKKwlpZiAobWF4ID4gMTAyNCB8fCBt YXggPD0gMCkKKwkJbWF4ID0gMTAyNDsKKworCWJ1ZiA9IG1hbGxvYyhtYXgpOworCWlmIChidWYg PT0gTlVMTCkgcmV0dXJuIE5VTEw7CisJaW9yZXF1ZXN0LnBpb2Rfb3AgPSBQSU9EX1JFQURfRDsK Kwlpb3JlcXVlc3QucGlvZF9vZmZzID0gb2Zmc2V0OworCWlvcmVxdWVzdC5waW9kX2FkZHIgPSBi dWY7CisJaW9yZXF1ZXN0LnBpb2RfbGVuID0gbWF4OworCXB0cmFjZShQVF9JTywgcGlkLCAoY2Fk ZHJfdCkmaW9yZXF1ZXN0LCAwKTsKKwlidWZbbWF4IC0gMV0gPSAnXDAnOwogCi0JaWYgKChmZCA9 IGR1cChwcm9jZmQpKSA9PSAtMSkKLQkJZXJyKDEsICJkdXAiKTsKLQlpZiAoKHAgPSBmZG9wZW4o ZmQsICJyIikpID09IE5VTEwpCi0JCWVycigxLCAiZmRvcGVuIik7Ci0JYnVmID0gbWFsbG9jKCBz aXplID0gKG1heCA/IG1heCArIDEgOiA2NCApICk7Ci0JbGVuID0gMDsKLQlidWZbMF0gPSAwOwot CWlmIChmc2Vla28ocCwgKHVpbnRwdHJfdClvZmZzZXQsIFNFRUtfU0VUKSA9PSAwKSB7Ci0JCXdo aWxlICgoYyA9IGZnZXRjKHApKSAhPSBFT0YpIHsKLQkJCWJ1ZltsZW4rK10gPSBjOwotCQkJaWYg KGMgPT0gMCB8fCBsZW4gPT0gbWF4KQotCQkJCWJyZWFrOwotCQkJaWYgKGxlbiA9PSBzaXplKSB7 Ci0JCQkJY2hhciAqdG1wOwotCQkJCXRtcCA9IHJlYWxsb2MoYnVmLCBzaXplKzY0KTsKLQkJCQlp ZiAodG1wID09IE5VTEwpIHsKLQkJCQkJYnVmW2xlbl0gPSAwOwotCQkJCQlicmVhazsKLQkJCQl9 Ci0JCQkJc2l6ZSArPSA2NDsKLQkJCQlidWYgPSB0bXA7Ci0JCQl9Ci0JCX0KLQkJYnVmW2xlbl0g PSAwOwotCX0KLQlmY2xvc2UocCk7CiAJcmV0dXJuIChidWYpOwogfQogCkBAIC00NjksOSArNDU4 LDkgQEAKICAqLwogCiBjaGFyICoKLXByaW50X2FyZyhpbnQgZmQsIHN0cnVjdCBzeXNjYWxsX2Fy Z3MgKnNjLCB1bnNpZ25lZCBsb25nICphcmdzLCBsb25nIHJldHZhbCwgc3RydWN0IHRydXNzaW5m byAqdHJ1c3NpbmZvKSB7CitwcmludF9hcmcoc3RydWN0IHN5c2NhbGxfYXJncyAqc2MsIHVuc2ln bmVkIGxvbmcgKmFyZ3MsIGxvbmcgcmV0dmFsLCBzdHJ1Y3QgdHJ1c3NpbmZvICp0cnVzc2luZm8p IHsKICAgY2hhciAqdG1wID0gTlVMTDsKLQorICBpbnQgcGlkID0gdHJ1c3NpbmZvLT5waWQ7CiAg IHN3aXRjaCAoc2MtPnR5cGUgJiBBUkdfTUFTSykgewogICBjYXNlIEhleDoKICAgICBhc3ByaW50 ZigmdG1wLCAiMHglbHgiLCBhcmdzW3NjLT5vZmZzZXRdKTsKQEAgLTQ4Niw3ICs0NzUsNyBAQAog ICAgIHsKICAgICAgIC8qIE5VTEwtdGVybWluYXRlZCBzdHJpbmcuICovCiAgICAgICBjaGFyICp0 bXAyOwotICAgICAgdG1wMiA9IGdldF9zdHJpbmcoZmQsICh2b2lkKilhcmdzW3NjLT5vZmZzZXRd LCAwKTsKKyAgICAgIHRtcDIgPSBnZXRfc3RyaW5nKHBpZCwgKHZvaWQqKWFyZ3Nbc2MtPm9mZnNl dF0sIDApOwogICAgICAgYXNwcmludGYoJnRtcCwgIlwiJXNcIiIsIHRtcDIpOwogICAgICAgZnJl ZSh0bXAyKTsKICAgICB9CkBAIC01MTQsNyArNTAzLDcgQEAKICAgICAgICAgbGVuID0gbWF4X3N0 cmluZzsKICAgICAgICAgdHJ1bmNhdGVkID0gMTsKICAgICAgIH0KLSAgICAgIGlmIChsZW4gJiYg Z2V0X3N0cnVjdChmZCwgKHZvaWQqKWFyZ3Nbc2MtPm9mZnNldF0sICZ0bXAyLCBsZW4pICE9IC0x KSB7CisgICAgICBpZiAobGVuICYmIGdldF9zdHJ1Y3QocGlkLCAodm9pZCopYXJnc1tzYy0+b2Zm c2V0XSwgJnRtcDIsIGxlbikgIT0gLTEpIHsKICAgICAgICAgdG1wMyA9IG1hbGxvYyhsZW4gKiA0 ICsgMSk7CiAgICAgICAgIHdoaWxlIChsZW4pIHsKICAgICAgICAgICBpZiAoc3RydmlzeCh0bXAz LCB0bXAyLCBsZW4sIFZJU19DU1RZTEV8VklTX1RBQnxWSVNfTkwpIDw9IG1heF9zdHJpbmcpCkBA IC01MzUsNyArNTI0LDcgQEAKICAgICAgIGNoYXIgKnN0cmluZzsKICAgICAgIGNoYXIgKnN0cmFy cmF5WzEwMF07CS8qIFhYWCBUaGlzIGlzIHVnbHkuICovCiAKLSAgICAgIGlmIChnZXRfc3RydWN0 KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICopJnN0cmFycmF5LAorICAgICAg aWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICopJnN0 cmFycmF5LAogICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKHN0cmFycmF5KSkgPT0gLTEpIHsK IAllcnIoMSwgImdldF9zdHJ1Y3QgJXAiLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0pOwogICAg ICAgfQpAQCAtNTQ0LDcgKzUzMyw3IEBACiAKICAgICAgIC8qIEZpbmQgb3V0IGhvdyBsYXJnZSBv ZiBhIGJ1ZmZlciB3ZSdsbCBuZWVkLiAqLwogICAgICAgd2hpbGUgKHN0cmFycmF5W251bV0gIT0g TlVMTCkgewotCXN0cmluZyA9IGdldF9zdHJpbmcoZmQsICh2b2lkKilzdHJhcnJheVtudW1dLCAw KTsKKwlzdHJpbmcgPSBnZXRfc3RyaW5nKHBpZCwgKHZvaWQqKXN0cmFycmF5W251bV0sIDApOwog ICAgICAgICBzaXplICs9IHN0cmxlbihzdHJpbmcpOwogCWZyZWUoc3RyaW5nKTsKIAludW0rKzsK QEAgLTU1NSw3ICs1NDQsNyBAQAogCiAgICAgICB0bXAyICs9IHNwcmludGYodG1wMiwgIiBbIik7 CiAgICAgICBmb3IgKGkgPSAwOyBpIDwgbnVtOyBpKyspIHsKLQlzdHJpbmcgPSBnZXRfc3RyaW5n KGZkLCAodm9pZCopc3RyYXJyYXlbaV0sIDApOworCXN0cmluZyA9IGdldF9zdHJpbmcocGlkLCAo dm9pZCopc3RyYXJyYXlbaV0sIDApOwogICAgICAgICB0bXAyICs9IHNwcmludGYodG1wMiwgIiBc IiVzXCIlYyIsIHN0cmluZywgKGkrMSA9PSBudW0pID8gJyAnIDogJywnKTsKIAlmcmVlKHN0cmlu Zyk7CiAgICAgICB9CkBAIC01ODUsNyArNTc0LDcgQEAKIAl0bXAgPSBzdHJkdXAoIiIpOwogCWJy ZWFrOwogICAgICAgfQotICAgICAgdG1wMiA9IGdldF9zdHJpbmcoZmQsICh2b2lkKilhcmdzW3Nj LT5vZmZzZXRdLCByZXR2YWwpOworICAgICAgdG1wMiA9IGdldF9zdHJpbmcocGlkLCAodm9pZCop YXJnc1tzYy0+b2Zmc2V0XSwgcmV0dmFsKTsKICAgICAgIGFzcHJpbnRmKCZ0bXAsICJcIiVzXCIi LCB0bXAyKTsKICAgICAgIGZyZWUodG1wMik7CiAgICAgfQpAQCAtNjA4LDcgKzU5Nyw3IEBACiAg IGNhc2UgVW10eDoKICAgICB7CiAgICAgICBzdHJ1Y3QgdW10eCB1bXR4OwotICAgICAgaWYgKGdl dF9zdHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnVtdHgsIHNpemVvZih1bXR4 KSkgIT0gLTEpCisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zm c2V0XSwgJnVtdHgsIHNpemVvZih1bXR4KSkgIT0gLTEpCiAJYXNwcmludGYoJnRtcCwgInsweCVs eH0iLCAobG9uZyl1bXR4LnVfb3duZXIpOwogICAgICAgZWxzZQogCWFzcHJpbnRmKCZ0bXAsICIw eCVseCIsIGFyZ3Nbc2MtPm9mZnNldF0pOwpAQCAtNjE3LDcgKzYwNiw3IEBACiAgIGNhc2UgVGlt ZXNwZWM6CiAgICAgewogICAgICAgc3RydWN0IHRpbWVzcGVjIHRzOwotICAgICAgaWYgKGdldF9z dHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnRzLCBzaXplb2YodHMpKSAhPSAt MSkKKyAgICAgIGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAm dHMsIHNpemVvZih0cykpICE9IC0xKQogCWFzcHJpbnRmKCZ0bXAsICJ7JWxkLiUwOWxkfSIsIChs b25nKXRzLnR2X3NlYywgdHMudHZfbnNlYyk7CiAgICAgICBlbHNlCiAJYXNwcmludGYoJnRtcCwg IjB4JWx4IiwgYXJnc1tzYy0+b2Zmc2V0XSk7CkBAIC02MjYsNyArNjE1LDcgQEAKICAgY2FzZSBU aW1ldmFsOgogICAgIHsKICAgICAgIHN0cnVjdCB0aW1ldmFsIHR2OwotICAgICAgaWYgKGdldF9z dHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnR2LCBzaXplb2YodHYpKSAhPSAt MSkKKyAgICAgIGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCAm dHYsIHNpemVvZih0dikpICE9IC0xKQogCWFzcHJpbnRmKCZ0bXAsICJ7JWxkLiUwNmxkfSIsIChs b25nKXR2LnR2X3NlYywgdHYudHZfdXNlYyk7CiAgICAgICBlbHNlCiAJYXNwcmludGYoJnRtcCwg IjB4JWx4IiwgYXJnc1tzYy0+b2Zmc2V0XSk7CkBAIC02MzUsNyArNjI0LDcgQEAKICAgY2FzZSBU aW1ldmFsMjoKICAgICB7CiAgICAgICBzdHJ1Y3QgdGltZXZhbCB0dlsyXTsKLSAgICAgIGlmIChn ZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZ0diwgc2l6ZW9mKHR2KSkg IT0gLTEpCisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0 XSwgJnR2LCBzaXplb2YodHYpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAieyVsZC4lMDZsZCwg JWxkLiUwNmxkfSIsCiAJICAobG9uZyl0dlswXS50dl9zZWMsIHR2WzBdLnR2X3VzZWMsCiAJICAo bG9uZyl0dlsxXS50dl9zZWMsIHR2WzFdLnR2X3VzZWMpOwpAQCAtNjQ2LDcgKzYzNSw3IEBACiAg IGNhc2UgSXRpbWVydmFsOgogICAgIHsKICAgICAgIHN0cnVjdCBpdGltZXJ2YWwgaXR2OwotICAg ICAgaWYgKGdldF9zdHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJml0diwgc2l6 ZW9mKGl0dikpICE9IC0xKQorICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nb c2MtPm9mZnNldF0sICZpdHYsIHNpemVvZihpdHYpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAi eyVsZC4lMDZsZCwgJWxkLiUwNmxkfSIsCiAJICAgIChsb25nKWl0di5pdF9pbnRlcnZhbC50dl9z ZWMsCiAJICAgIGl0di5pdF9pbnRlcnZhbC50dl91c2VjLApAQCAtNjcwLDcgKzY1OSw3IEBACiAK ICAgICAgIGlmICgocGZkID0gbWFsbG9jKGJ5dGVzKSkgPT0gTlVMTCkKIAllcnIoMSwgIkNhbm5v dCBtYWxsb2MgJWQgYnl0ZXMgZm9yIHBvbGxmZCBhcnJheSIsIGJ5dGVzKTsKLSAgICAgIGlmIChn ZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sIHBmZCwgYnl0ZXMpICE9IC0x KSB7CisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwg cGZkLCBieXRlcykgIT0gLTEpIHsKIAogCXVzZWQgPSAwOwogCXRtcHNpemUgPSAxICsgcGVyX2Zk ICogbnVtZmRzICsgMjsKQEAgLTcwOSw3ICs2OTgsNyBAQAogCiAgICAgICBpZiAoKGZkcyA9IG1h bGxvYyhieXRlcykpID09IE5VTEwpCiAJZXJyKDEsICJDYW5ub3QgbWFsbG9jICVkIGJ5dGVzIGZv ciBmZF9zZXQgYXJyYXkiLCBieXRlcyk7Ci0gICAgICBpZiAoZ2V0X3N0cnVjdChmZCwgKHZvaWQg KilhcmdzW3NjLT5vZmZzZXRdLCBmZHMsIGJ5dGVzKSAhPSAtMSkgeworICAgICAgaWYgKGdldF9z dHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sIGZkcywgYnl0ZXMpICE9IC0xKSB7 CiAJdXNlZCA9IDA7CiAJdG1wc2l6ZSA9IDEgKyBudW1mZHMgKiBwZXJfZmQgKyAyOwogCWlmICgo dG1wID0gbWFsbG9jKHRtcHNpemUpKSA9PSBOVUxMKQpAQCAtNzQ5LDcgKzczOCw3IEBACiAgICAg ICBpbnQgaSwgdXNlZDsKIAogICAgICAgc2lnID0gYXJnc1tzYy0+b2Zmc2V0XTsKLSAgICAgIGlm IChnZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICopJnNzLAor ICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lk ICopJnNzLAogICAgICAgICAgIHNpemVvZihzcykpID09IC0xKQogICAgICAgewogCWFzcHJpbnRm KCZ0bXAsICIweCVseCIsIGFyZ3Nbc2MtPm9mZnNldF0pOwpAQCAtODUzLDcgKzg0Miw3IEBACiAg ICAgICB9CiAKICAgICAgIC8qIHl1Y2s6IGdldCBzc19sZW4gKi8KLSAgICAgIGlmIChnZXRfc3Ry dWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICopJnNzLAorICAgICAgaWYg KGdldF9zdHJ1Y3QocGlkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICopJnNzLAog CXNpemVvZihzcy5zc19sZW4pICsgc2l6ZW9mKHNzLnNzX2ZhbWlseSkpID09IC0xKQogCWVycigx LCAiZ2V0X3N0cnVjdCAlcCIsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSk7CiAgICAgICAvKgpA QCAtODc0LDcgKzg2Myw3IEBACiAJCSAgICAgIGJyZWFrOwogCSAgICAgIH0KICAgICAgIH0KLSAg ICAgIGlmIChnZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICh2b2lkICop JnNzLCBzcy5zc19sZW4pCisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tz Yy0+b2Zmc2V0XSwgKHZvaWQgKikmc3MsIHNzLnNzX2xlbikKIAkgID09IC0xKSB7CiAJICBlcnIo MiwgImdldF9zdHJ1Y3QgJXAiLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0pOwogICAgICAgfQpA QCAtOTEzLDcgKzkwMiw3IEBACiAgICAgICBjaGFyICpoYW5kOwogICAgICAgY29uc3QgY2hhciAq aDsKIAotICAgICAgaWYgKGdldF9zdHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwg JnNhLCBzaXplb2Yoc2EpKSAhPSAtMSkgeworICAgICAgaWYgKGdldF9zdHJ1Y3QocGlkLCAodm9p ZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZzYSwgc2l6ZW9mKHNhKSkgIT0gLTEpIHsKIAogCWFzcHJp bnRmKCZoYW5kLCAiJXAiLCBzYS5zYV9oYW5kbGVyKTsKIAlpZiAoc2Euc2FfaGFuZGxlciA9PSBT SUdfREZMKQpAQCAtOTU2LDcgKzk0NSw3IEBACiAgICAgICAJYnl0ZXMgPSBzaXplb2Yoc3RydWN0 IGtldmVudCkgKiBudW1ldmVudHM7CiAgICAgICBpZiAoKGtlID0gbWFsbG9jKGJ5dGVzKSkgPT0g TlVMTCkKICAgICAgICAgZXJyKDEsICJDYW5ub3QgbWFsbG9jICVkIGJ5dGVzIGZvciBrZXZlbnQg YXJyYXkiLCBieXRlcyk7Ci0gICAgICBpZiAobnVtZXZlbnRzID49IDAgJiYgZ2V0X3N0cnVjdChm ZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRdLCBrZSwgYnl0ZXMpICE9IC0xKSB7CisgICAgICBp ZiAobnVtZXZlbnRzID49IDAgJiYgZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJnc1tzYy0+b2Zm c2V0XSwga2UsIGJ5dGVzKSAhPSAtMSkgewogCXVzZWQgPSAwOwogCXRtcHNpemUgPSAxICsgcGVy X2tlICogbnVtZXZlbnRzICsgMjsKIAlpZiAoKHRtcCA9IG1hbGxvYyh0bXBzaXplKSkgPT0gTlVM TCkKQEAgLTk4Niw3ICs5NzUsNyBAQAogICBjYXNlIFN0YXQ6CiAgICAgewogICAgICAgc3RydWN0 IHN0YXQgc3Q7Ci0gICAgICBpZiAoZ2V0X3N0cnVjdChmZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZz ZXRdLCAmc3QsIHNpemVvZihzdCkpICE9IC0xKSB7CisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQs ICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnN0LCBzaXplb2Yoc3QpKSAhPSAtMSkgewogCWNo YXIgbW9kZVsxMl07CiAJc3RybW9kZShzdC5zdF9tb2RlLCBtb2RlKTsKIAlhc3ByaW50ZigmdG1w LCAie21vZGU9JXMsaW5vZGU9JWpkLHNpemU9JWpkLGJsa3NpemU9JWxkfSIsCkBAIC05OTksNyAr OTg4LDcgQEAKICAgY2FzZSBSdXNhZ2U6CiAgICAgewogICAgICAgc3RydWN0IHJ1c2FnZSBydTsK LSAgICAgIGlmIChnZXRfc3RydWN0KGZkLCAodm9pZCAqKWFyZ3Nbc2MtPm9mZnNldF0sICZydSwg c2l6ZW9mKHJ1KSkgIT0gLTEpCisgICAgICBpZiAoZ2V0X3N0cnVjdChwaWQsICh2b2lkICopYXJn c1tzYy0+b2Zmc2V0XSwgJnJ1LCBzaXplb2YocnUpKSAhPSAtMSkKIAlhc3ByaW50ZigmdG1wLCAi e3U9JWxkLiUwNmxkLHM9JWxkLiUwNmxkLGluPSVsZCxvdXQ9JWxkfSIsCiAJICAobG9uZylydS5y dV91dGltZS50dl9zZWMsIHJ1LnJ1X3V0aW1lLnR2X3VzZWMsCiAJICAobG9uZylydS5ydV9zdGlt ZS50dl9zZWMsIHJ1LnJ1X3N0aW1lLnR2X3VzZWMsCkBAIC0xMDExLDcgKzEwMDAsNyBAQAogICBj YXNlIFJsaW1pdDoKICAgICB7CiAgICAgICBzdHJ1Y3QgcmxpbWl0IHJsOwotICAgICAgaWYgKGdl dF9zdHJ1Y3QoZmQsICh2b2lkICopYXJnc1tzYy0+b2Zmc2V0XSwgJnJsLCBzaXplb2YocmwpKSAh PSAtMSkKKyAgICAgIGlmIChnZXRfc3RydWN0KHBpZCwgKHZvaWQgKilhcmdzW3NjLT5vZmZzZXRd LCAmcmwsIHNpemVvZihybCkpICE9IC0xKQogCWFzcHJpbnRmKCZ0bXAsICJ7Y3VyPSVqdSxtYXg9 JWp1fSIsCiAJICBybC5ybGltX2N1ciwgcmwucmxpbV9tYXgpOwogICAgICAgZWxzZQo9PT09IC8v ZGVwb3QvdmVuZG9yL2ZyZWVic2Qvc3JjL3Vzci5iaW4vdHJ1c3MvdHJ1c3MuMSMxMiAodGV4dCtr bykgLSAvL2RlcG90L3VzZXIvaG93YXJkc3UvdHJ1c3MvdXNyLmJpbi90cnVzcy90cnVzcy4xIzMg KHRleHQra28pID09PT0gY29udGVudApAQCAtMjMsNyArMjMsNyBAQAogdXRpbGl0eSB0cmFjZXMg dGhlIHN5c3RlbSBjYWxscyBjYWxsZWQgYnkgdGhlIHNwZWNpZmllZCBwcm9jZXNzIG9yIHByb2dy YW0uCiBPdXRwdXQgaXMgdG8gdGhlIHNwZWNpZmllZCBvdXRwdXQgZmlsZSwgb3Igc3RhbmRhcmQg ZXJyb3IgYnkgZGVmYXVsdC4KIEl0IGRvZXMgdGhpcyBieSBzdG9wcGluZyBhbmQgcmVzdGFydGlu ZyB0aGUgcHJvY2VzcyBiZWluZyBtb25pdG9yZWQgdmlhCi0uWHIgcHJvY2ZzIDUgLgorLlhyIHB0 cmFjZSAyIC4KIC5QcAogVGhlIG9wdGlvbnMgYXJlIGFzIGZvbGxvd3M6CiAuQmwgLXRhZyAtd2lk dGggaW5kZW50CkBAIC03OSwxMyArNzksNiBAQAogLkFyIGNvbW1hbmQKIG9wdGlvbnMgYXJlIG11 dHVhbGx5IGV4Y2x1c2l2ZS4pCiAuRWwKLS5QcAotVGhlCi0uWHIgcHJvY2N0bCA4Ci11dGlsaXR5 IGNhbiBiZSB1c2VkIHRvIGNsZWFyIHRyYWNlcG9pbnRzIGluIGEgc3R1Y2sgcHJvY2VzcwotbGVm dCBiZWhpbmQgaWYKLS5ObQotdGVybWluYXRlcyBhYm5vcm1hbGx5LgogLlNoIEVYQU1QTEVTCiAj IEZvbGxvdyB0aGUgc3lzdGVtIGNhbGxzIHVzZWQgaW4gZWNob2luZyAiaGVsbG8iCiAuRGwgJCB0 cnVzcyAvYmluL2VjaG8gaGVsbG8KQEAgLTk2LDggKzg5LDcgQEAKIC5TaCBTRUUgQUxTTwogLlhy IGtkdW1wIDEgLAogLlhyIGt0cmFjZSAxICwKLS5YciBwcm9jZnMgNSAsCi0uWHIgcHJvY2N0bCA4 CisuWHIgcHRyYWNlIDIgMiAKIC5TaCBISVNUT1JZCiBUaGUKIC5ObQo9PT09IC8vZGVwb3QvdmVu ZG9yL2ZyZWVic2Qvc3JjL3Vzci5iaW4vdHJ1c3MvdHJ1c3MuaCM1ICh0ZXh0K2tvKSAtIC8vZGVw b3QvdXNlci9ob3dhcmRzdS90cnVzcy91c3IuYmluL3RydXNzL3RydXNzLmgjNCAodGV4dCtrbykg PT09PSBjb250ZW50CkBAIC0yNSw2ICsyNSw4IEBACiAgKiAkRnJlZUJTRDogc3JjL3Vzci5iaW4v dHJ1c3MvdHJ1c3MuaCx2IDEuNyAyMDA2LzA1LzE1IDIxOjE4OjI4IHBhdiBFeHAgJAogICovCiAK KyNpbmNsdWRlIDxzeXMvcXVldWUuaD4KKwogI2RlZmluZSBGT0xMT1dGT1JLUyAgICAgICAgMHgw MDAwMDAwMQogI2RlZmluZSBSRUxBVElWRVRJTUVTVEFNUFMgMHgwMDAwMDAwMgogI2RlZmluZSBB QlNPTFVURVRJTUVTVEFNUFMgMHgwMDAwMDAwNApAQCAtMzIsMTcgKzM0LDMwIEBACiAjZGVmaW5l IEVYRUNWRUFSR1MgICAgICAgICAweDAwMDAwMDEwCiAjZGVmaW5lIEVYRUNWRUVOVlMgICAgICAg ICAweDAwMDAwMDIwCiAKK3N0cnVjdCB0aHJlYWRpbmZvCit7CisJU0xJU1RfRU5UUlkodGhyZWFk aW5mbykgZW50cmllczsKKwlsd3BpZF90IHRpZDsKKwlpbnQgaW5fc3lzY2FsbDsKKwlpbnQgaW5f Zm9yazsKK307CisKIHN0cnVjdCB0cnVzc2luZm8KIHsKIAlpbnQgcGlkOwogCWludCBmbGFnczsK LQlpbnQgaW5fZm9yazsKKwlpbnQgcHJfd2h5OworCWludCBwcl9kYXRhOwogCWludCBzdHJzaXpl OwogCUZJTEUgKm91dGZpbGU7CiAKIAlzdHJ1Y3QgdGltZXNwZWMgc3RhcnRfdGltZTsKIAlzdHJ1 Y3QgdGltZXNwZWMgYmVmb3JlOwogCXN0cnVjdCB0aW1lc3BlYyBhZnRlcjsKKworCXN0cnVjdCB0 aHJlYWRpbmZvICpjdXJ0aHJlYWQ7CisJCisJU0xJU1RfSEVBRCgsIHRocmVhZGluZm8pIHRocmVh ZGxpc3Q7CiB9OwogCiAjZGVmaW5lIHRpbWVzcGVjc3VidCh0dnAsIHV2cCwgdnZwKQkJCQkJXApA QCAtNTQsMyArNjksMTAgQEAKIAkJCSh2dnApLT50dl9uc2VjICs9IDEwMDAwMDAwMDA7CQkJXAog CQl9CQkJCQkJCVwKIAl9IHdoaWxlICgwKQorCisjZGVmaW5lIFNfTk9ORSAgMAorI2RlZmluZSBT X1NDRSAgIDEKKyNkZWZpbmUgU19TQ1ggICAyCisjZGVmaW5lIFNfRVhJVCAgMworI2RlZmluZSBT X1NJRyAgIDQKKyNkZWZpbmUgU19FWEVDICA1Cg== ------=_Part_3006_3639545.1175846663809-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 08:37:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5050216A403 for ; Fri, 6 Apr 2007 08:37:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4D413C489 for ; Fri, 6 Apr 2007 08:37:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HZjwQ-0006ot-Bu for freebsd-current@freebsd.org; Fri, 06 Apr 2007 10:37:06 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 10:37:06 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Apr 2007 10:37:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 06 Apr 2007 10:36:52 +0200 Lines: 31 Message-ID: References: <20070406025700.GB98545@garage.freebsd.pl> <4615BCA4.7030109@cyberwang.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8019E83B9A38C0B69DF3330" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <4615BCA4.7030109@cyberwang.net> X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-fs@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 08:37:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8019E83B9A38C0B69DF3330 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sean Bryant wrote: > Is it fully 128bit? From wikipedia, which is by no means an=20 > authoritative source but I have no idea if this was ever an issue. It's 64-bit even in Solaris. The "128-bitness" is only in the storage=20 format, not for file system ops visible to applications. (AFAIK). --------------enigD8019E83B9A38C0B69DF3330 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGFgaqldnAQVacBcgRAs9hAKDxnpY3Zm3B67GQdmWn3is1YuxOuACg8pTs bNlky88GFDHZeJHri6gxXy0= =3S7W -----END PGP SIGNATURE----- --------------enigD8019E83B9A38C0B69DF3330-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 09:28:35 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E16616A408; Fri, 6 Apr 2007 09:28:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0130713C480; Fri, 6 Apr 2007 09:28:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7B40B47019; Fri, 6 Apr 2007 05:28:34 -0400 (EDT) Date: Fri, 6 Apr 2007 05:28:34 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alex Dupre In-Reply-To: <4615F62A.5090001@FreeBSD.org> Message-ID: <20070406052701.E30801@fledge.watson.org> References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 09:28:35 -0000 On Fri, 6 Apr 2007, Alex Dupre wrote: > Pawel Jakub Dawidek wrote: >> I'm happy to inform that the ZFS file system is now part of the FreeBSD >> operating system. > > Congratulations! You're great! > >> - There is no support for booting off of ZFS file system. > > Even booting kernel from a removable ufs media and then mounting a zfs root > via vfs.root.mountfrom? I believe the key issue here is that the boot loader doesn't yet support ZFS. In 6.x and 7.x, the mechanism for mounting the root file system is identical to all other file systems, so it should be possible to use any file system as the root file system as long as you get can get the kernel up and running. And, in the case of ZFS, the ZFS module loaded (since it currently must be a module). This is really exciting work and I'm very glad to see this in the tree! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 10:36:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31EA516A402 for ; Fri, 6 Apr 2007 10:36:41 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out09.ilk.de [194.121.104.9]) by mx1.freebsd.org (Postfix) with ESMTP id A376113C4AE for ; Fri, 6 Apr 2007 10:36:40 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool43.ka.ilk.net [212.86.194.43]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l36A4Sjo000750; Fri, 6 Apr 2007 12:04:29 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.4+Sun/8.13.4) with ESMTP id l36A2Y2E024451; Fri, 6 Apr 2007 12:02:35 +0200 (CEST) Message-ID: <46161B38.9090706@smo.de> Date: Fri, 06 Apr 2007 12:04:40 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070323 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <86zm5nrllc.fsf@dwp.des.no> In-Reply-To: <86zm5nrllc.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , FreeBSD Stable , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 10:36:41 -0000 Dag-Erling Smørgrav wrote: > "Nikolas Britton" writes: > >>Can anything in the list below be removed from CURRENT? > > > No. Modern i386 and amd64 still have an ISA bus, and devices > connected to that bus, even if they don't have ISA slots. Some mainboards for industrial use even have them today... And the main CPU is a Pentium 4 or AMD 64 ;) Philipp -- www.familie-ost.info/~pj From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 10:40:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11C2916A402; Fri, 6 Apr 2007 10:40:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 91C9D13C458; Fri, 6 Apr 2007 10:40:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DEA0F48804; Fri, 6 Apr 2007 12:40:13 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 55BDF45684; Fri, 6 Apr 2007 12:40:08 +0200 (CEST) Date: Fri, 6 Apr 2007 12:40:04 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070406104004.GB1251@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4615BCA4.7030109@cyberwang.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 10:40:16 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 10:36:52AM +0200, Ivan Voras wrote: > Sean Bryant wrote: >=20 > >Is it fully 128bit? From wikipedia, which is by no means an authoritativ= e source but I have no idea if this was ever an issue. >=20 > It's 64-bit even in Solaris. The "128-bitness" is only in the storage for= mat, not for file system ops visible to applications. >=20 > (AFAIK). That's correct. We are limited by POSIX, but the on-disk format is 128bit. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFiOEForvXbEpPzQRAjS9AJ92Ftsf8C3KXHf6W1DqvBUqz0smtwCgnHhu M9ZZpig8KBlHuOJB2EnB/K0= =Yydo -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 05:21:01 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C66516A405; Fri, 6 Apr 2007 05:21:01 +0000 (UTC) (envelope-from Richard.Elling@Sun.COM) Received: from nwk-ea-fw-1.sun.com (nwk-ea-fw-1.sun.com [192.18.42.249]) by mx1.freebsd.org (Postfix) with ESMTP id 2197313C48C; Fri, 6 Apr 2007 05:21:00 +0000 (UTC) (envelope-from Richard.Elling@Sun.COM) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3659x0Q018931; Thu, 5 Apr 2007 22:09:59 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JG200F0190EDN00@d1-sfbay-10.sun.com> (original mail from Richard.Elling@Sun.COM); Thu, 05 Apr 2007 22:09:59 -0700 (PDT) Received: from [192.168.129.30] ([66.166.41.125]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JG200MSS90LD7SK@d1-sfbay-10.sun.com>; Thu, 05 Apr 2007 22:09:59 -0700 (PDT) Date: Thu, 05 Apr 2007 22:10:33 -0700 From: Richard Elling In-reply-to: <20070406025700.GB98545@garage.freebsd.pl> Sender: Richard.Elling@Sun.COM To: Pawel Jakub Dawidek Message-id: <4615D649.2060808@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20070406025700.GB98545@garage.freebsd.pl> User-Agent: Thunderbird 2.0b2 (X11/20070227) X-Mailman-Approved-At: Fri, 06 Apr 2007 11:25:45 +0000 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 05:21:01 -0000 Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. Well done, team! Everyone who cares about their data will be happy :-) -- richard From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 05:21:20 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D23716A403 for ; Fri, 6 Apr 2007 05:21:20 +0000 (UTC) (envelope-from rcorreia@wizy.org) Received: from sapo.pt (relay1.ptmail.sapo.pt [212.55.154.21]) by mx1.freebsd.org (Postfix) with SMTP id 6F31813C4AD for ; Fri, 6 Apr 2007 05:21:18 +0000 (UTC) (envelope-from rcorreia@wizy.org) Received: (qmail 21918 invoked from network); 6 Apr 2007 04:54:38 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.208) by relay1 with SMTP; 6 Apr 2007 04:54:38 -0000 Received: (qmail 1060 invoked from network); 6 Apr 2007 04:54:38 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.01439 seconds) Received: from unknown (HELO wizy.org) (wizeman_pt@sapo.pt@[85.240.128.185]) (envelope-sender ) by mta13 (qmail-ldap-1.03) with SMTP for ; 6 Apr 2007 04:54:38 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wizy.org (Postfix) with ESMTP id CB436FB88F7; Fri, 6 Apr 2007 05:54:37 +0100 (WEST) Message-ID: <4615D28D.8030909@wizy.org> Date: Fri, 06 Apr 2007 05:54:37 +0100 From: Ricardo Correia User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Apr 2007 11:25:59 +0000 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 05:21:20 -0000 Hi Pawel, Pawel Jakub Dawidek wrote: > Other than that, ZFS should be fully-functional. Congratulations, nice work! :) I'm interested in the cross-platform portability of ZFS pools, so I have one question: did you implement the Solaris ZFS whole-disk support (specifically, the creation and recognition of the EFI/GPT label)? Unfortunately some tools in Linux (parted and cfdisk) have trouble recognizing the EFI partition created by ZFS/Solaris.. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 06:02:38 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1D4716A401; Fri, 6 Apr 2007 06:02:38 +0000 (UTC) (envelope-from rich.teer@rite-group.com) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9A26613C483; Fri, 6 Apr 2007 06:02:36 +0000 (UTC) (envelope-from rich.teer@rite-group.com) Received: from pd3mr5so.prod.shaw.ca (pd3mr5so-qfe3.prod.shaw.ca [10.0.141.12]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JG200G7N8IWS060@l-daemon>; Thu, 05 Apr 2007 22:59:20 -0600 (MDT) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd3mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JG200KHD8IXN6F1@pd3mr5so.prod.shaw.ca>; Thu, 05 Apr 2007 22:59:21 -0600 (MDT) Received: from mail.rite-group.com ([24.70.222.81]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JG200H6Q8IW2DH0@l-daemon>; Thu, 05 Apr 2007 22:59:20 -0600 (MDT) Received: from marrakesh (marrakesh [192.168.0.2]) by mail.rite-group.com (8.12.10+Sun/8.12.10) with ESMTP id l364xIt5020070; Thu, 05 Apr 2007 21:59:18 -0700 (PDT) Date: Thu, 05 Apr 2007 21:58:47 -0700 (PDT) From: Rich Teer In-reply-to: <20070406025700.GB98545@garage.freebsd.pl> X-X-Sender: rich@marrakesh To: Pawel Jakub Dawidek Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20070406025700.GB98545@garage.freebsd.pl> X-Mailman-Approved-At: Fri, 06 Apr 2007 11:26:08 +0000 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 06:02:38 -0000 > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. This is fantastic news! At the risk of raking over ye olde arguments, as the old saying goes: "Dual licensing? We don't need no stinkeen dual licensing!". :-) -- Rich Teer, SCSA, SCNA, SCSECA, OGB member CEO, My Online Home Inventory Voice: +1 (250) 979-1638 URLs: http://www.rite-group.com/rich http://www.myonlinehomeinventory.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 11:29:26 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8CDF16A406; Fri, 6 Apr 2007 11:29:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0D13F13C487; Fri, 6 Apr 2007 11:29:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3AC5D48805; Fri, 6 Apr 2007 13:29:24 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7CC4845B26; Fri, 6 Apr 2007 13:29:16 +0200 (CEST) Date: Fri, 6 Apr 2007 13:29:11 +0200 From: Pawel Jakub Dawidek To: Ricardo Correia Message-ID: <20070406112911.GC1251@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4615D28D.8030909@wizy.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="adJ1OR3c6QgCpb/j" Content-Disposition: inline In-Reply-To: <4615D28D.8030909@wizy.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 11:29:26 -0000 --adJ1OR3c6QgCpb/j Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 05:54:37AM +0100, Ricardo Correia wrote: > I'm interested in the cross-platform portability of ZFS pools, so I have > one question: did you implement the Solaris ZFS whole-disk support > (specifically, the creation and recognition of the EFI/GPT label)? >=20 > Unfortunately some tools in Linux (parted and cfdisk) have trouble > recognizing the EFI partition created by ZFS/Solaris.. I'm not yet setup to move disks between FreeBSD and Solaris, but my first goal was to integrate it with FreeBSD's GEOM framework. We support cache flushing operations on any GEOM provider (disk, partition, slice, anything disk-like), so bascially currently I treat everything as a whole disk (because I simply can), but don't do any EFI/GPT labeling. I'll try to move data from Solaris' disk to FreeBSD and see what happen. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --adJ1OR3c6QgCpb/j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFi8HForvXbEpPzQRAqkkAKDoeFVtTc0mTpQX1p+3b/K6H6NfjgCfdJOR SQwudd1BSO/2tsivsqBPBlI= =M1fQ -----END PGP SIGNATURE----- --adJ1OR3c6QgCpb/j-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 11:52:47 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7E3216A403 for ; Fri, 6 Apr 2007 11:52:47 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.freebsd.org (Postfix) with ESMTP id 8678D13C4AE for ; Fri, 6 Apr 2007 11:52:47 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id 9B9181DD510 for ; Fri, 6 Apr 2007 12:30:53 +0100 (BST) X-Virus-Scanned: amavisd-new at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x134M0zztfVz for ; Fri, 6 Apr 2007 12:30:48 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 4CCE11DD500; Fri, 6 Apr 2007 12:30:48 +0100 (BST) Date: Fri, 6 Apr 2007 12:30:48 +0100 From: David Taylor To: FreeBSD Current Message-ID: <20070406113048.GA49739@outcold.yadt.co.uk> Mail-Followup-To: FreeBSD Current References: <46128475.9060602@FreeBSD.org> <4613D6F3.4080701@mac.com> <461434A6.3080001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <461434A6.3080001@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Surviving /dev/null disappearance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 11:52:47 -0000 On Wed, 04 Apr 2007, Maxim Sobolev wrote: > Chuck Swiger wrote: > >Andrew Pantyukhin wrote: > >>On 4/3/07, Maxim Sobolev wrote: > >>>Patch ld(1) to detect the condition and don't unlink the device node? > >> > >>Yes, but there has to be a generic solution, so that > >>we don't reinvent the wheel for every one of the > >>thousands apps that may do this. > >> > >>Isn't there some safety-net wrapper function that > >>refuses to remove device nodes and maybe some other > >>types of files? > > > >Why not set a filesystem flag like schg on device nodes under a devfs > >tree...? > > Well, I suspect that it may cause ld(1) fail instead. What we want it to > do is to not perform unlink(2) before open(2) when -o argument is device > node. I think calling ld with it's output set to a device node is basically pilot error. ld unlinks files rather than truncating them for good reasons --- to avoid overwriting libraries that are in use (the unlinked file is still around on disk until the last fd referencing it is closed). -- David Taylor From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 11:56:11 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69F6E16A403; Fri, 6 Apr 2007 11:56:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id C907F13C483; Fri, 6 Apr 2007 11:56:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 91B26487FB; Fri, 6 Apr 2007 13:56:08 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 01C8D487F5; Fri, 6 Apr 2007 13:56:01 +0200 (CEST) Date: Fri, 6 Apr 2007 13:55:57 +0200 From: Pawel Jakub Dawidek To: Robert Watson Message-ID: <20070406115557.GF1251@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> <20070406052701.E30801@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mjqg7Yu+0hL22rav" Content-Disposition: inline In-Reply-To: <20070406052701.E30801@fledge.watson.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=ALL_TRUSTED,BAYES_00, CONGRATULATIONS autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Alex Dupre Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 11:56:11 -0000 --Mjqg7Yu+0hL22rav Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 05:28:34AM -0400, Robert Watson wrote: >=20 > On Fri, 6 Apr 2007, Alex Dupre wrote: >=20 > >Pawel Jakub Dawidek wrote: > >>I'm happy to inform that the ZFS file system is now part of the FreeBSD > >>operating system. > > > >Congratulations! You're great! > > > >> - There is no support for booting off of ZFS file system. > > > >Even booting kernel from a removable ufs media and then mounting a zfs r= oot via vfs.root.mountfrom? >=20 > I believe the key issue here is that the boot loader doesn't yet support = ZFS. In 6.x and 7.x, the mechanism for mounting the root file system is ide= ntical to all other file=20 > systems, so it should be possible to use any file system as the root file= system as long as you get can get the kernel up and running. And, in the c= ase of ZFS, the ZFS=20 > module loaded (since it currently must be a module). You are right in general, but it isn't really true for ZFS currently. There are two very small issues: 1. Prefered way to mount ZFS file system is via 'zfs mount' command, but=20 it can be mounted using old way as well, so this really shouldn't be an issue. 2. ZFS kernel module read /etc/zfs/zpool.cache file on load by accessing it via file system. We would need to change it to load this file via loader. Shouldn't be hard. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Mjqg7Yu+0hL22rav Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFjVNForvXbEpPzQRAlt/AKCjPfv8Bkk5HSCREwpamwBfj6tiFQCg2Slh 4AK9fL4HM2XxKlbZuCz0sQM= =MYNi -----END PGP SIGNATURE----- --Mjqg7Yu+0hL22rav-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 12:35:05 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D09916A403; Fri, 6 Apr 2007 12:35:05 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id E3BD613C455; Fri, 6 Apr 2007 12:35:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 26DA845696; Fri, 6 Apr 2007 14:35:01 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A9FA4569A; Fri, 6 Apr 2007 14:34:52 +0200 (CEST) Date: Fri, 6 Apr 2007 14:34:47 +0200 From: Pawel Jakub Dawidek To: Ricardo Correia Message-ID: <20070406123447.GC3519@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4615D28D.8030909@wizy.org> <20070406112911.GC1251@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ" Content-Disposition: inline In-Reply-To: <20070406112911.GC1251@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 12:35:05 -0000 --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 01:29:11PM +0200, Pawel Jakub Dawidek wrote: > On Fri, Apr 06, 2007 at 05:54:37AM +0100, Ricardo Correia wrote: > > I'm interested in the cross-platform portability of ZFS pools, so I have > > one question: did you implement the Solaris ZFS whole-disk support > > (specifically, the creation and recognition of the EFI/GPT label)? > >=20 > > Unfortunately some tools in Linux (parted and cfdisk) have trouble > > recognizing the EFI partition created by ZFS/Solaris.. >=20 > I'm not yet setup to move disks between FreeBSD and Solaris, but my > first goal was to integrate it with FreeBSD's GEOM framework. >=20 > We support cache flushing operations on any GEOM provider (disk, > partition, slice, anything disk-like), so bascially currently I treat > everything as a whole disk (because I simply can), but don't do any > EFI/GPT labeling. I'll try to move data from Solaris' disk to FreeBSD > and see what happen. First try: GEOM: ad6: corrupt or invalid GPT detected. GEOM: ad6: GPT rejected -- may not be recoverable. :) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFj5nForvXbEpPzQRAmZtAJ9NNlTPy4RdnLvFTmWm5Jz2HvNw3ACeOgqK NcarHt0SfokjjcpDqK0XQzA= =m8c4 -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 12:59:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCC1716A401; Fri, 6 Apr 2007 12:59:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A86D913C43E; Fri, 6 Apr 2007 12:59:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 019451A3C1C; Fri, 6 Apr 2007 05:59:41 -0700 (PDT) Date: Fri, 6 Apr 2007 05:59:40 -0700 From: Alfred Perlstein To: Howard Su Message-ID: <20070406125940.GN2382@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Robert Watson , current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 12:59:40 -0000 * Howard Su [070406 01:04] wrote: > Thanks to Robert to point out that my original patch didn't work > against a threaded application. I fixed that. Please try the new > patch. > > I tested this patch under i386 box only with libthr and libpthread. Ok, one nit and one potential issue I'd like to know about. nit: you have new functions like this "void fun(args)", they should be in the form of "void\nfun(args)" (newline after return type) possible issue: is get_string equivelant to the procfs version? meaning, if there's a string that ends at a strange place in the address space will it work any differently? note how the procfs version does a fgetc(3) over and over and stops reading if it hits \0, while the version you have tried to read the entire buf. Can that cause issues? > > Howard > > On 4/4/07, Howard Su wrote: > >Following the suggestion in idea page, I proposed the attached patch. > >I didn't change any kernel part because I think PTRACE(2) is > >functional although man page didn't document it. > > > >I tested the patch under i386 and amd64 box. The help on testing and > >code review will be appreciated. > > > >To test, please try the following commands: > >1. truss ps > >basic stuff > >2. truss -o output ps > >output the result to file > >3. truss -f -o output sh -c "ps" > >test follow fork > >4. start TOP(1) in another session, the > >truss -p > > > >-- > >-Howard > > > > > > > -- > -Howard > ==== //depot/vendor/freebsd/src/usr.bin/truss/Makefile#9 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/Makefile#1 (text+ko) ==== identical > ==== //depot/vendor/freebsd/src/usr.bin/truss/amd64-fbsd.c#6 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/amd64-fbsd.c#5 (text+ko) ==== content > @@ -43,8 +43,7 @@ > */ > > #include > -#include > -#include > +#include > #include > > #include > @@ -63,7 +62,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "syscalls.h" > @@ -113,25 +111,16 @@ > > void > amd64_syscall_entry(struct trussinfo *trussinfo, int nargs) { > - char buf[32]; > struct reg regs; > int syscall_num; > int i, reg; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > } > @@ -163,7 +152,7 @@ > || !strcmp(fsc.name, "rfork") > || !strcmp(fsc.name, "vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > @@ -181,8 +170,13 @@ > } > } > if (nargs > i) { > - lseek(Procfd, regs.r_rsp + sizeof(register_t), SEEK_SET); > - if (read(Procfd, &fsc.args[i], (nargs-i) * sizeof(register_t)) == -1) > + struct ptrace_io_desc iorequest; > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = (void *)(regs.r_rsp + sizeof(register_t)); > + iorequest.piod_addr = &fsc.args[i]; > + iorequest.piod_len = (nargs - i) * sizeof(register_t); > + ptrace(PT_IO, cpid, (caddr_t)&iorequest, 0); > + if (iorequest.piod_len == 0) > return; > } > > @@ -223,7 +217,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -279,25 +273,16 @@ > long > amd64_syscall_exit(struct trussinfo *trussinfo, int syscall_num __unused) > { > - char buf[32]; > struct reg regs; > long retval; > int i; > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return (-1); > } > @@ -328,7 +313,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/extern.h#10 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/extern.h#3 (text+ko) ==== content > @@ -32,8 +32,9 @@ > */ > > extern int setup_and_wait(char **); > -extern int start_tracing(int, int, int, int); > +extern int start_tracing(int); > extern void restore_proc(int); > +extern void waitevent(struct trussinfo *); > extern const char *ioctlname(register_t val); > extern char *strsig(int sig); > #ifdef __alpha__ > @@ -63,4 +64,3 @@ > extern long sparc64_syscall_exit(struct trussinfo *, int); > #endif > > -extern int Procfd; > ==== //depot/vendor/freebsd/src/usr.bin/truss/i386-fbsd.c#17 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/i386-fbsd.c#4 (text+ko) ==== content > @@ -43,9 +43,8 @@ > */ > > #include > -#include > -#include > #include > +#include > > #include > #include > @@ -63,7 +62,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "syscalls.h" > @@ -113,26 +111,18 @@ > > void > i386_syscall_entry(struct trussinfo *trussinfo, int nargs) { > - char buf[32]; > struct reg regs; > int syscall_num; > int i; > unsigned int parm_offset; > struct syscall *sc = NULL; > + struct ptrace_io_desc iorequest; > + cpid = trussinfo->curthread->tid; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > - > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > } > @@ -146,13 +136,11 @@ > syscall_num = regs.r_eax; > switch (syscall_num) { > case SYS_syscall: > - lseek(Procfd, parm_offset, SEEK_SET); > - read(Procfd, &syscall_num, sizeof(int)); > + syscall_num = ptrace(PT_READ_D, cpid, (caddr_t)parm_offset, 0); > parm_offset += sizeof(int); > break; > case SYS___syscall: > - lseek(Procfd, parm_offset, SEEK_SET); > - read(Procfd, &syscall_num, sizeof(int)); > + syscall_num = ptrace(PT_READ_D, cpid, (caddr_t)parm_offset, 0); > parm_offset += sizeof(quad_t); > break; > } > @@ -169,15 +157,19 @@ > || !strcmp(fsc.name, "rfork") > || !strcmp(fsc.name, "vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > return; > > fsc.args = malloc((1+nargs) * sizeof(unsigned long)); > - lseek(Procfd, parm_offset, SEEK_SET); > - if (read(Procfd, fsc.args, nargs * sizeof(unsigned long)) == -1) > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = (void *)parm_offset; > + iorequest.piod_addr = fsc.args; > + iorequest.piod_len = nargs * sizeof(unsigned long); > + ptrace(PT_IO, cpid, (caddr_t)&iorequest, 0); > + if (iorequest.piod_len == 0) > return; > > if (fsc.name) > @@ -218,7 +210,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -274,28 +266,20 @@ > long > i386_syscall_exit(struct trussinfo *trussinfo, int syscall_num __unused) > { > - char buf[32]; > struct reg regs; > long retval; > int i; > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return (-1); > } > + > retval = regs.r_eax; > errorp = !!(regs.r_eflags & PSL_C); > > @@ -323,7 +307,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/i386-linux.c#16 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/i386-linux.c#4 (text+ko) ==== content > @@ -41,8 +41,7 @@ > */ > > #include > -#include > -#include > +#include > > #include > #include > @@ -60,7 +59,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "linux_syscalls.h" > @@ -108,28 +106,20 @@ > > void > i386_linux_syscall_entry(struct trussinfo *trussinfo, int nargs) { > - char buf[32]; > struct reg regs; > int syscall_num; > int i; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > - } > + } > syscall_num = regs.r_eax; > > fsc.number = syscall_num; > @@ -143,7 +133,7 @@ > && ((!strcmp(fsc.name, "linux_fork") > || !strcmp(fsc.name, "linux_vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > @@ -200,7 +190,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -264,28 +254,19 @@ > long > i386_linux_syscall_exit(struct trussinfo *trussinfo, int syscall_num __unused) > { > - char buf[32]; > struct reg regs; > long retval; > int i; > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > + cpid = trussinfo->curthread->tid; > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) > + { > + fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > + return (-1); > } > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > - fprintf(trussinfo->outfile, "\n"); > - return (-1); > - } > retval = regs.r_eax; > errorp = !!(regs.r_eflags & PSL_C); > > @@ -313,7 +294,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/i386.conf#1 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/i386.conf#1 (text+ko) ==== identical > ==== //depot/vendor/freebsd/src/usr.bin/truss/i386linux.conf#1 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/i386linux.conf#1 (text+ko) ==== identical > ==== //depot/vendor/freebsd/src/usr.bin/truss/ia64-fbsd.c#9 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/ia64-fbsd.c#3 (text+ko) ==== content > @@ -43,8 +43,7 @@ > */ > > #include > -#include > -#include > +#include > #include > > #include > @@ -62,7 +61,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "syscalls.h" > @@ -112,26 +110,16 @@ > > void > ia64_syscall_entry(struct trussinfo *trussinfo, int nargs) { > - char buf[32]; > struct reg regs; > int syscall_num; > int i; > unsigned long *parm_offset; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->id; > > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > } > @@ -158,7 +146,7 @@ > || !strcmp(fsc.name, "rfork") > || !strcmp(fsc.name, "vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > @@ -204,7 +192,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -260,25 +248,15 @@ > long > ia64_syscall_exit(struct trussinfo *trussinfo, int syscall_num __unused) > { > - char buf[32]; > struct reg regs; > long retval; > int i; > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return (-1); > } > @@ -309,7 +287,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/main.c#24 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/main.c#6 (text+ko) ==== content > @@ -39,11 +39,10 @@ > */ > > #include > -#include > -#include > #include > #include > #include > +#include > > #include > #include > @@ -59,13 +58,8 @@ > #include "truss.h" > #include "extern.h" > > -/* > - * It's difficult to parameterize this because it must be > - * accessible in a signal handler. > - */ > +#define MAXARGS 5 > > -int Procfd; > - > static void > usage(void) > { > @@ -119,18 +113,19 @@ > set_etype(struct trussinfo *trussinfo) > { > struct ex_types *funcs; > - char etype[24]; > char progt[32]; > - int fd; > + > + size_t len = sizeof(progt); > + int mib[4]; > + int error; > > - sprintf(etype, "/proc/%d/etype", trussinfo->pid); > - if ((fd = open(etype, O_RDONLY)) == -1) { > - strcpy(progt, "FreeBSD a.out"); > - } else { > - int len = read(fd, progt, sizeof(progt)); > - progt[len-1] = '\0'; > - close(fd); > - } > + mib[0] = CTL_KERN; > + mib[1] = KERN_PROC; > + mib[2] = KERN_PROC_SV_NAME; > + mib[3] = trussinfo->pid; > + error = sysctl(mib, 4, progt, &len, NULL, 0); > + if (error != 0) > + err(2, "can not get etype"); > > for (funcs = ex_types; funcs->type; funcs++) > if (!strcmp(funcs->type, progt)) > @@ -167,14 +162,12 @@ > int c; > int i; > char **command; > - struct procfs_status pfs; > struct ex_types *funcs; > - int in_exec, sigexit, initial_open; > + int sigexit, initial_open; > char *fname; > struct trussinfo *trussinfo; > char *signame; > > - in_exec = 0; > sigexit = 0; > fname = NULL; > initial_open = 1; > @@ -184,9 +177,12 @@ > if (trussinfo == NULL) > errx(1, "malloc() failed"); > bzero(trussinfo, sizeof(struct trussinfo)); > + > trussinfo->outfile = stderr; > trussinfo->strsize = 32; > - > + trussinfo->pr_why = S_NONE; > + trussinfo->curthread = NULL; > + SLIST_INIT(&trussinfo->threadlist); > while ((c = getopt(ac, av, "p:o:faedDs:S")) != -1) { > switch (c) { > case 'p': /* specified pid */ > @@ -245,6 +241,7 @@ > signal(SIGTERM, SIG_IGN); > signal(SIGQUIT, SIG_IGN); > } else { > + start_tracing(trussinfo->pid); > signal(SIGINT, restore_proc); > signal(SIGTERM, restore_proc); > signal(SIGQUIT, restore_proc); > @@ -257,18 +254,9 @@ > */ > > START_TRACE: > - Procfd = start_tracing( > - trussinfo->pid, initial_open, > - S_EXEC | S_SCE | S_SCX | S_CORE | S_EXIT | > - ((trussinfo->flags & NOSIGS) ? 0 : S_SIG), > - ((trussinfo->flags & FOLLOWFORKS) ? PF_FORK : 0)); > + funcs = set_etype(trussinfo); > + > initial_open = 0; > - if (Procfd == -1) > - return (0); > - > - pfs.why = 0; > - > - funcs = set_etype(trussinfo); > /* > * At this point, it's a simple loop, waiting for the process to > * stop, finding out why, printing out why, and then continuing it. > @@ -278,118 +266,92 @@ > clock_gettime(CLOCK_REALTIME, &trussinfo->start_time); > > do { > - int val = 0; > struct timespec timediff; > + waitevent(trussinfo); > > - if (ioctl(Procfd, PIOCWAIT, &pfs) == -1) > - warn("PIOCWAIT top of loop"); > - else { > - switch(i = pfs.why) { > - case S_SCE: > - funcs->enter_syscall(trussinfo, pfs.val); > - clock_gettime(CLOCK_REALTIME, > - &trussinfo->before); > - break; > - case S_SCX: > - clock_gettime(CLOCK_REALTIME, > - &trussinfo->after); > - /* > - * This is so we don't get two messages for > - * an exec -- one for the S_EXEC, and one for > - * the syscall exit. It also, conveniently, > - * ensures that the first message printed out > - * isn't the return-from-syscall used to > - * create the process. > - */ > - if (in_exec) { > - in_exec = 0; > - break; > - } > + switch(i = trussinfo->pr_why) { > + case S_SCE: > + funcs->enter_syscall(trussinfo, MAXARGS); > + clock_gettime(CLOCK_REALTIME, > + &trussinfo->before); > + break; > + case S_SCX: > + clock_gettime(CLOCK_REALTIME, > + &trussinfo->after); > > - if (trussinfo->in_fork && > - (trussinfo->flags & FOLLOWFORKS)) { > - int childpid; > + if (trussinfo->curthread->in_fork && > + (trussinfo->flags & FOLLOWFORKS)) { > + int childpid; > > - trussinfo->in_fork = 0; > - childpid = > - funcs->exit_syscall(trussinfo, > - pfs.val); > + trussinfo->curthread->in_fork = 0; > + childpid = > + funcs->exit_syscall(trussinfo, > + trussinfo->pr_data); > > - /* > - * Fork a new copy of ourself to trace > - * the child of the original traced > - * process. > - */ > - if (fork() == 0) { > - trussinfo->pid = childpid; > - goto START_TRACE; > - } > - break; > + /* > + * Fork a new copy of ourself to trace > + * the child of the original traced > + * process. > + */ > + if (fork() == 0) { > + trussinfo->pid = childpid; > + start_tracing(trussinfo->pid); > + goto START_TRACE; > } > - funcs->exit_syscall(trussinfo, pfs.val); > break; > - case S_SIG: > - if (trussinfo->flags & FOLLOWFORKS) > - fprintf(trussinfo->outfile, "%5d: ", > - trussinfo->pid); > - if (trussinfo->flags & ABSOLUTETIMESTAMPS) { > - timespecsubt(&trussinfo->after, > - &trussinfo->start_time, &timediff); > - fprintf(trussinfo->outfile, "%ld.%09ld ", > - (long)timediff.tv_sec, > - timediff.tv_nsec); > - } > - if (trussinfo->flags & RELATIVETIMESTAMPS) { > - timespecsubt(&trussinfo->after, > - &trussinfo->before, &timediff); > - fprintf(trussinfo->outfile, "%ld.%09ld ", > - (long)timediff.tv_sec, > - timediff.tv_nsec); > - } > - signame = strsig(pfs.val); > - fprintf(trussinfo->outfile, > - "SIGNAL %lu (%s)\n", pfs.val, > - signame == NULL ? "?" : signame); > - free(signame); > - sigexit = pfs.val; > + } > + funcs->exit_syscall(trussinfo, MAXARGS); > + break; > + case S_SIG: > + if (trussinfo->flags & NOSIGS) > break; > - case S_EXIT: > - if (trussinfo->flags & FOLLOWFORKS) > - fprintf(trussinfo->outfile, "%5d: ", > - trussinfo->pid); > - if (trussinfo->flags & ABSOLUTETIMESTAMPS) { > - timespecsubt(&trussinfo->after, > - &trussinfo->start_time, &timediff); > - fprintf(trussinfo->outfile, "%ld.%09ld ", > - (long)timediff.tv_sec, > - timediff.tv_nsec); > - } > - if (trussinfo->flags & RELATIVETIMESTAMPS) { > - timespecsubt(&trussinfo->after, > - &trussinfo->before, &timediff); > - fprintf(trussinfo->outfile, "%ld.%09ld ", > - (long)timediff.tv_sec, timediff.tv_nsec); > - } > - fprintf(trussinfo->outfile, > - "process exit, rval = %lu\n", pfs.val); > - break; > - case S_EXEC: > - funcs = set_etype(trussinfo); > - in_exec = 1; > - break; > - default: > - fprintf(trussinfo->outfile, > - "Process stopped because of: %d\n", i); > - break; > + if (trussinfo->flags & FOLLOWFORKS) > + fprintf(trussinfo->outfile, "%5d: ", > + trussinfo->pid); > + if (trussinfo->flags & ABSOLUTETIMESTAMPS) { > + timespecsubt(&trussinfo->after, > + &trussinfo->start_time, &timediff); > + fprintf(trussinfo->outfile, "%ld.%09ld ", > + (long)timediff.tv_sec, > + timediff.tv_nsec); > + } > + if (trussinfo->flags & RELATIVETIMESTAMPS) { > + timespecsubt(&trussinfo->after, > + &trussinfo->before, &timediff); > + fprintf(trussinfo->outfile, "%ld.%09ld ", > + (long)timediff.tv_sec, > + timediff.tv_nsec); > + } > + signame = strsig(trussinfo->pr_data); > + fprintf(trussinfo->outfile, > + "SIGNAL %u (%s)\n", trussinfo->pr_data, > + signame == NULL ? "?" : signame); > + free(signame); > + break; > + case S_EXIT: > + if (trussinfo->flags & FOLLOWFORKS) > + fprintf(trussinfo->outfile, "%5d: ", > + trussinfo->pid); > + if (trussinfo->flags & ABSOLUTETIMESTAMPS) { > + timespecsubt(&trussinfo->after, > + &trussinfo->start_time, &timediff); > + fprintf(trussinfo->outfile, "%ld.%09ld ", > + (long)timediff.tv_sec, > + timediff.tv_nsec); > + } > + if (trussinfo->flags & RELATIVETIMESTAMPS) { > + timespecsubt(&trussinfo->after, > + &trussinfo->before, &timediff); > + fprintf(trussinfo->outfile, "%ld.%09ld ", > + (long)timediff.tv_sec, timediff.tv_nsec); > } > + fprintf(trussinfo->outfile, > + "process exit, rval = %u\n", trussinfo->pr_data); > + break; > + default: > + break; > } > - if (ioctl(Procfd, PIOCCONT, val) == -1) { > - if (kill(trussinfo->pid, 0) == -1 && errno == ESRCH) > - break; > - else > - warn("PIOCCONT"); > - } > - } while (pfs.why != S_EXIT); > + } while (trussinfo->pr_why != S_EXIT); > fflush(trussinfo->outfile); > if (sigexit) { > struct rlimit rlp; > @@ -400,5 +362,6 @@ > (void) signal(sigexit, SIG_DFL); > (void) kill(getpid(), sigexit); > } > + > return (0); > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/powerpc-fbsd.c#1 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/powerpc-fbsd.c#4 (text+ko) ==== content > @@ -41,8 +41,7 @@ > */ > > #include > -#include > -#include > +#include > #include > > #include > @@ -62,7 +61,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "syscalls.h" > @@ -120,19 +118,10 @@ > unsigned int regargs; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > } > @@ -167,7 +156,7 @@ > || !strcmp(fsc.name, "rfork") > || !strcmp(fsc.name, "vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > @@ -176,9 +165,16 @@ > fsc.args = malloc((1+nargs) * sizeof(unsigned long)); > > if (nargs > regargs) { > + struct ptrace_io_desc iorequest; > memmove(&fsc.args[0], args, regargs * sizeof(fsc.args[0])); > - lseek(Procfd, regs.fixreg[1] + 8, SEEK_SET); > - read(Procfd, &fsc.args[regargs], (nargs - regargs) * sizeof(fsc.args[0])); > + > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = (void *)(regs.fixreg[1] + 8); > + iorequest.piod_addr = &fsc.args[regargs]; > + iorequest.piod_len = (nargs - regargs) * sizeof(fsc.args[0]); > + ptrace(PT_IO, cpid, (caddr_t)&iorequest, 0); > + if (iorequest.piod_len == 0) > + return; > } else { > memmove(&fsc.args[0], args, nargs * sizeof(fsc.args[0])); > } > @@ -220,7 +216,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -275,25 +271,15 @@ > long > powerpc_syscall_exit(struct trussinfo *trussinfo, int syscall_num __unused) > { > - char buf[32]; > struct reg regs; > long retval; > int i; > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "\n"); > return (-1); > } > @@ -332,7 +318,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/setup.c#11 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/setup.c#7 (text+ko) ==== content > @@ -38,11 +38,12 @@ > */ > > #include > -#include > -#include > +#include > +#include > #include > > #include > +#include > #include > #include > #include > @@ -51,10 +52,12 @@ > #include > #include > > +#include > + > #include "truss.h" > #include "extern.h" > > -static int evflags = 0; > +static int child_pid; > > /* > * setup_and_wait() is called to start a process. All it really does > @@ -66,75 +69,28 @@ > int > setup_and_wait(char *command[]) > { > - struct procfs_status pfs; > - char buf[32]; > - int fd; > int pid; > - int flags; > - int loop; > + int waitval; > > - pid = fork(); > + pid = vfork(); > if (pid == -1) { > err(1, "fork failed"); > } > if (pid == 0) { /* Child */ > - int mask = S_EXEC | S_EXIT; > - fd = open("/proc/curproc/mem", O_WRONLY); > - if (fd == -1) > - err(2, "cannot open /proc/curproc/mem"); > - fcntl(fd, F_SETFD, 1); > - if (ioctl(fd, PIOCBIS, mask) == -1) > - err(3, "PIOCBIS"); > - flags = PF_LINGER; > - /* > - * The PF_LINGER flag tells procfs not to wake up the > - * process on last close; normally, this is the behaviour > - * we want. > - */ > - if (ioctl(fd, PIOCSFL, flags) == -1) > - warn("cannot set PF_LINGER"); > + ptrace(PT_TRACE_ME, 0, 0, 0); > + setpgid (0, 0); > execvp(command[0], command); > - mask = ~0; > - ioctl(fd, PIOCBIC, ~0); > - err(4, "execvp %s", command[0]); > + err(1, "execvp %s", command[0]); > } > + > /* Only in the parent here */ > - > - if (waitpid(pid, NULL, WNOHANG) != 0) { > - /* > - * Process exited before it got to us -- meaning the exec failed > - * miserably -- so we just quietly exit. > - */ > - exit(1); > + if (waitpid(pid, &waitval, 0) < -1) { > + err(1, "unexpect stop in waitpid"); > + return 0; > } > > - sprintf(buf, "/proc/%d/mem", pid); > - > - /* Try 6 times to trace our child, waiting 1/2 second each time */ > - for (loop=6 ;; loop--) { > - if (loop != 6) > - usleep(500000); > - if ((fd = open(buf, O_RDWR)) == -1) { > - if (loop > 0) > - continue; > - else > - err(5, "cannot open1 %s", buf); > - } > - if (ioctl(fd, PIOCWAIT, &pfs) == -1) { > - if (loop >= 0) > - continue; > - else > - err(6, "PIOCWAIT"); > - } > - if (pfs.why == S_EXIT) { > - warnx("process exited before exec'ing"); > - ioctl(fd, PIOCCONT, 0); > - wait(0); > - exit(7); > - } else > - break; > - } > - close(fd); > + child_pid = pid; > + > return (pid); > } > > @@ -145,45 +101,24 @@ > */ > > int > -start_tracing(int pid, int failisfatal, int eventflags, int flags) > +start_tracing(int pid) > { > - int fd; > - char buf[32]; > - struct procfs_status tmp; > + int waitval; > + int ret; > + int retry = 10; > > - sprintf(buf, "/proc/%d/mem", pid); > - /* usleep(500000); */ > + do { > + ret = ptrace(PT_ATTACH, pid, NULL, 0); > + usleep(200); > + } while(ret && retry-- > 0); > + if (ret) > + err(1, "can not attach to target process"); > > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - /* > - * The process may have run away before we could start -- this > - * happens with SUGID programs. So we need to see if it still > - * exists before we complain bitterly. > - */ > - if (!failisfatal && kill(pid, 0) == -1) > - return (-1); > - err(8, "cannot open2 %s", buf); > - } > + child_pid = pid; > + if (waitpid(pid, &waitval, 0) < -1) > + err(1, "Unexpect stop in waitpid"); > > - if (ioctl(fd, PIOCSTATUS, &tmp) == -1) { > - err(10, "cannot get procfs status struct"); > - } > - evflags = tmp.events; > - > - if (ioctl(fd, PIOCBIS, eventflags) == -1) > - err(9, "cannot set procfs event bit mask"); > - > - /* > - * This clears the PF_LINGER set above in setup_and_wait(); > - * if truss happens to die before this, then the process > - * needs to be woken up via procctl. > - */ > - > - if (ioctl(fd, PIOCSFL, flags) == -1) > - warn("cannot clear PF_LINGER"); > - > - return (fd); > + return (0); > } > > /* > @@ -193,10 +128,74 @@ > * process. > */ > void > -restore_proc(int signo __unused) { > +restore_proc(int signo __unused) > +{ > + int waitval; > + > + kill(child_pid, SIGSTOP); > + if (waitpid(child_pid, &waitval, 0) < -1) > + err(1, "Unexpected stop in waitpid"); > > - ioctl(Procfd, PIOCBIC, ~0); > - if (evflags) > - ioctl(Procfd, PIOCBIS, evflags); > + if (ptrace(PT_DETACH, child_pid, (caddr_t)1, 0) < 0) > + err(1, "Can not detach the process"); > + > + kill(child_pid, SIGCONT); > exit(0); > } > + > +void find_thread(struct trussinfo *info, lwpid_t lwpid) > +{ > + info->curthread = NULL; > + struct threadinfo *np; > + SLIST_FOREACH(np, &info->threadlist, entries) { > + if (np->tid == lwpid) { > + info->curthread = np; > + return; > + } > + } > + > + np = (struct threadinfo *)malloc(sizeof(struct threadinfo)); > + if (np == NULL) > + errx(1, "malloc() failed"); > + np->tid = lwpid; > + np->in_fork = 0; > + np->in_syscall = 0; > + SLIST_INSERT_HEAD(&info->threadlist, np, entries); > + info->curthread = np; > +} > + > +void waitevent(struct trussinfo *info) > +{ > + int waitval; > + > + ptrace(PT_SYSCALL, info->pid, (caddr_t)1, 0); > + > + if (waitpid(info->pid, &waitval, 0) < -1) { > + err(1, "Unexpected stop in waitpid"); > + } > + > + if (WIFCONTINUED(waitval)) { > + info->pr_why = S_NONE; > + return; > + } > + if (WIFEXITED(waitval)) { > + info->pr_why = S_EXIT; > + info->pr_data = WEXITSTATUS(waitval); > + return; > + } > + if (WIFSTOPPED(waitval) || (WIFSIGNALED(waitval))) { > + struct ptrace_lwpinfo lwpinfo; > + ptrace(PT_LWPINFO, info->pid, (caddr_t)&lwpinfo, sizeof(lwpinfo)); > + find_thread(info, lwpinfo.pl_lwpid); > + switch(WSTOPSIG(waitval)) { > + case SIGTRAP: > + info->pr_why = info->curthread->in_syscall?S_SCX:S_SCE; > + info->curthread->in_syscall = 1 - info->curthread->in_syscall; > + break; > + default: > + info->pr_why = S_SIG; > + info->pr_data = WSTOPSIG(waitval); > + break; > + } > + } > +} > ==== //depot/vendor/freebsd/src/usr.bin/truss/sparc64-fbsd.c#9 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/sparc64-fbsd.c#3 (text+ko) ==== content > @@ -45,8 +45,7 @@ > */ > > #include > -#include > -#include > +#include > #include > > #include > @@ -68,7 +67,6 @@ > #include "syscall.h" > #include "extern.h" > > -static int fd = -1; > static int cpid = -1; > > #include "syscalls.h" > @@ -118,26 +116,18 @@ > > void > sparc64_syscall_entry(struct trussinfo *trussinfo, int nargs) { > - char buf[32]; > struct reg regs; > int syscall_num; > int i; > struct syscall *sc; > int indir = 0; /* indirect system call */ > + struct ptrace_io_desc iorequest; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDWR); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return; > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > clear_fsc(); > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "-- CANNOT READ REGISTERS --\n"); > return; > } > @@ -165,7 +155,7 @@ > || !strcmp(fsc.name, "rfork") > || !strcmp(fsc.name, "vfork")))) > { > - trussinfo->in_fork = 1; > + trussinfo->curthread->in_fork = 1; > } > > if (nargs == 0) > @@ -186,9 +176,14 @@ > * on the stack, as is normal for other processors. > * The fall-through for all of these is deliberate!!! > */ > - lseek(Procfd, regs.r_out[6] + SPOFF + > - offsetof(struct frame, fr_pad[6]), SEEK_SET); > - read(fd, &fsc.args[6], (nargs - 6) * sizeof(fsc.args[0])); > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = (void *)(regs.r_out[6] + SPOFF + > + offsetof(struct frame, fr_pad[6]); > + iorequest.piod_addr = &fsc.args[6]; > + iorequest.piod_len = (nargs - 6) * sizeof(fsc.args[0]); > + ptrace(PT_IO, cpid, (caddr_t)&iorequest, 0); > + if (iorequest.piod_len == 0) return; > + > case 6: fsc.args[5] = regs.r_out[5]; > case 5: fsc.args[4] = regs.r_out[4]; > case 4: fsc.args[3] = regs.r_out[3]; > @@ -240,7 +235,7 @@ > i < (fsc.nargs - 1) ? "," : ""); > #endif > if (sc && !(sc->args[i].type & OUT)) { > - fsc.s_args[i] = print_arg(Procfd, &sc->args[i], fsc.args, 0, trussinfo); > + fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); > } > } > #if DEBUG > @@ -302,18 +297,9 @@ > int errorp; > struct syscall *sc; > > - if (fd == -1 || trussinfo->pid != cpid) { > - sprintf(buf, "/proc/%d/regs", trussinfo->pid); > - fd = open(buf, O_RDONLY); > - if (fd == -1) { > - fprintf(trussinfo->outfile, "-- CANNOT OPEN REGISTERS --\n"); > - return (-1); > - } > - cpid = trussinfo->pid; > - } > + cpid = trussinfo->curthread->tid; > > - lseek(fd, 0L, 0); > - if (read(fd, ®s, sizeof(regs)) != sizeof(regs)) { > + if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { > fprintf(trussinfo->outfile, "\n"); > return (-1); > } > @@ -344,7 +330,7 @@ > if (errorp) > asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); > else > - temp = print_arg(Procfd, &sc->args[i], fsc.args, retval, trussinfo); > + temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); > fsc.s_args[i] = temp; > } > } > ==== //depot/vendor/freebsd/src/usr.bin/truss/syscall.h#12 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/syscall.h#2 (text+ko) ==== content > @@ -61,7 +61,7 @@ > > struct syscall *get_syscall(const char*); > char *get_string(int, void*, int); > -char *print_arg(int, struct syscall_args *, unsigned long*, long, struct trussinfo *); > +char *print_arg(struct syscall_args *, unsigned long*, long, struct trussinfo *); > void print_syscall(struct trussinfo *, const char *, int, char **); > void print_syscall_ret(struct trussinfo *, const char *, int, char **, int, > long); > ==== //depot/vendor/freebsd/src/usr.bin/truss/syscalls.c#38 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/syscalls.c#2 (text+ko) ==== content > @@ -41,6 +41,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -408,9 +409,13 @@ > */ > > static int > -get_struct(int procfd, void *offset, void *buf, int len) { > - > - if (pread(procfd, buf, len, (uintptr_t)offset) != len) > +get_struct(int pid, void *offset, void *buf, int len) { > + struct ptrace_io_desc iorequest; > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = offset; > + iorequest.piod_addr = buf; > + iorequest.piod_len = len; > + if (ptrace(PT_IO, pid, (caddr_t)&iorequest, 0) != len) > return -1; > return 0; > } > @@ -423,37 +428,21 @@ > */ > > char * > -get_string(int procfd, void *offset, int max) { > +get_string(int pid, void *offset, int max) { > char *buf; > - int size, len, c, fd; > - FILE *p; > + struct ptrace_io_desc iorequest; > + if (max > 1024 || max <= 0) > + max = 1024; > + > + buf = malloc(max); > + if (buf == NULL) return NULL; > + iorequest.piod_op = PIOD_READ_D; > + iorequest.piod_offs = offset; > + iorequest.piod_addr = buf; > + iorequest.piod_len = max; > + ptrace(PT_IO, pid, (caddr_t)&iorequest, 0); > + buf[max - 1] = '\0'; > > - if ((fd = dup(procfd)) == -1) > - err(1, "dup"); > - if ((p = fdopen(fd, "r")) == NULL) > - err(1, "fdopen"); > - buf = malloc( size = (max ? max + 1 : 64 ) ); > - len = 0; > - buf[0] = 0; > - if (fseeko(p, (uintptr_t)offset, SEEK_SET) == 0) { > - while ((c = fgetc(p)) != EOF) { > - buf[len++] = c; > - if (c == 0 || len == max) > - break; > - if (len == size) { > - char *tmp; > - tmp = realloc(buf, size+64); > - if (tmp == NULL) { > - buf[len] = 0; > - break; > - } > - size += 64; > - buf = tmp; > - } > - } > - buf[len] = 0; > - } > - fclose(p); > return (buf); > } > > @@ -469,9 +458,9 @@ > */ > > char * > -print_arg(int fd, struct syscall_args *sc, unsigned long *args, long retval, struct trussinfo *trussinfo) { > +print_arg(struct syscall_args *sc, unsigned long *args, long retval, struct trussinfo *trussinfo) { > char *tmp = NULL; > - > + int pid = trussinfo->pid; > switch (sc->type & ARG_MASK) { > case Hex: > asprintf(&tmp, "0x%lx", args[sc->offset]); > @@ -486,7 +475,7 @@ > { > /* NULL-terminated string. */ > char *tmp2; > - tmp2 = get_string(fd, (void*)args[sc->offset], 0); > + tmp2 = get_string(pid, (void*)args[sc->offset], 0); > asprintf(&tmp, "\"%s\"", tmp2); > free(tmp2); > } > @@ -514,7 +503,7 @@ > len = max_string; > truncated = 1; > } > - if (len && get_struct(fd, (void*)args[sc->offset], &tmp2, len) != -1) { > + if (len && get_struct(pid, (void*)args[sc->offset], &tmp2, len) != -1) { > tmp3 = malloc(len * 4 + 1); > while (len) { > if (strvisx(tmp3, tmp2, len, VIS_CSTYLE|VIS_TAB|VIS_NL) <= max_string) > @@ -535,7 +524,7 @@ > char *string; > char *strarray[100]; /* XXX This is ugly. */ > > - if (get_struct(fd, (void *)args[sc->offset], (void *)&strarray, > + if (get_struct(pid, (void *)args[sc->offset], (void *)&strarray, > sizeof(strarray)) == -1) { > err(1, "get_struct %p", (void *)args[sc->offset]); > } > @@ -544,7 +533,7 @@ > > /* Find out how large of a buffer we'll need. */ > while (strarray[num] != NULL) { > - string = get_string(fd, (void*)strarray[num], 0); > + string = get_string(pid, (void*)strarray[num], 0); > size += strlen(string); > free(string); > num++; > @@ -555,7 +544,7 @@ > > tmp2 += sprintf(tmp2, " ["); > for (i = 0; i < num; i++) { > - string = get_string(fd, (void*)strarray[i], 0); > + string = get_string(pid, (void*)strarray[i], 0); > tmp2 += sprintf(tmp2, " \"%s\"%c", string, (i+1 == num) ? ' ' : ','); > free(string); > } > @@ -585,7 +574,7 @@ > tmp = strdup(""); > break; > } > - tmp2 = get_string(fd, (void*)args[sc->offset], retval); > + tmp2 = get_string(pid, (void*)args[sc->offset], retval); > asprintf(&tmp, "\"%s\"", tmp2); > free(tmp2); > } > @@ -608,7 +597,7 @@ > case Umtx: > { > struct umtx umtx; > - if (get_struct(fd, (void *)args[sc->offset], &umtx, sizeof(umtx)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &umtx, sizeof(umtx)) != -1) > asprintf(&tmp, "{0x%lx}", (long)umtx.u_owner); > else > asprintf(&tmp, "0x%lx", args[sc->offset]); > @@ -617,7 +606,7 @@ > case Timespec: > { > struct timespec ts; > - if (get_struct(fd, (void *)args[sc->offset], &ts, sizeof(ts)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &ts, sizeof(ts)) != -1) > asprintf(&tmp, "{%ld.%09ld}", (long)ts.tv_sec, ts.tv_nsec); > else > asprintf(&tmp, "0x%lx", args[sc->offset]); > @@ -626,7 +615,7 @@ > case Timeval: > { > struct timeval tv; > - if (get_struct(fd, (void *)args[sc->offset], &tv, sizeof(tv)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &tv, sizeof(tv)) != -1) > asprintf(&tmp, "{%ld.%06ld}", (long)tv.tv_sec, tv.tv_usec); > else > asprintf(&tmp, "0x%lx", args[sc->offset]); > @@ -635,7 +624,7 @@ > case Timeval2: > { > struct timeval tv[2]; > - if (get_struct(fd, (void *)args[sc->offset], &tv, sizeof(tv)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &tv, sizeof(tv)) != -1) > asprintf(&tmp, "{%ld.%06ld, %ld.%06ld}", > (long)tv[0].tv_sec, tv[0].tv_usec, > (long)tv[1].tv_sec, tv[1].tv_usec); > @@ -646,7 +635,7 @@ > case Itimerval: > { > struct itimerval itv; > - if (get_struct(fd, (void *)args[sc->offset], &itv, sizeof(itv)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &itv, sizeof(itv)) != -1) > asprintf(&tmp, "{%ld.%06ld, %ld.%06ld}", > (long)itv.it_interval.tv_sec, > itv.it_interval.tv_usec, > @@ -670,7 +659,7 @@ > > if ((pfd = malloc(bytes)) == NULL) > err(1, "Cannot malloc %d bytes for pollfd array", bytes); > - if (get_struct(fd, (void *)args[sc->offset], pfd, bytes) != -1) { > + if (get_struct(pid, (void *)args[sc->offset], pfd, bytes) != -1) { > > used = 0; > tmpsize = 1 + per_fd * numfds + 2; > @@ -709,7 +698,7 @@ > > if ((fds = malloc(bytes)) == NULL) > err(1, "Cannot malloc %d bytes for fd_set array", bytes); > - if (get_struct(fd, (void *)args[sc->offset], fds, bytes) != -1) { > + if (get_struct(pid, (void *)args[sc->offset], fds, bytes) != -1) { > used = 0; > tmpsize = 1 + numfds * per_fd + 2; > if ((tmp = malloc(tmpsize)) == NULL) > @@ -749,7 +738,7 @@ > int i, used; > > sig = args[sc->offset]; > - if (get_struct(fd, (void *)args[sc->offset], (void *)&ss, > + if (get_struct(pid, (void *)args[sc->offset], (void *)&ss, > sizeof(ss)) == -1) > { > asprintf(&tmp, "0x%lx", args[sc->offset]); > @@ -853,7 +842,7 @@ > } > > /* yuck: get ss_len */ > - if (get_struct(fd, (void *)args[sc->offset], (void *)&ss, > + if (get_struct(pid, (void *)args[sc->offset], (void *)&ss, > sizeof(ss.ss_len) + sizeof(ss.ss_family)) == -1) > err(1, "get_struct %p", (void *)args[sc->offset]); > /* > @@ -874,7 +863,7 @@ > break; > } > } > - if (get_struct(fd, (void *)args[sc->offset], (void *)&ss, ss.ss_len) > + if (get_struct(pid, (void *)args[sc->offset], (void *)&ss, ss.ss_len) > == -1) { > err(2, "get_struct %p", (void *)args[sc->offset]); > } > @@ -913,7 +902,7 @@ > char *hand; > const char *h; > > - if (get_struct(fd, (void *)args[sc->offset], &sa, sizeof(sa)) != -1) { > + if (get_struct(pid, (void *)args[sc->offset], &sa, sizeof(sa)) != -1) { > > asprintf(&hand, "%p", sa.sa_handler); > if (sa.sa_handler == SIG_DFL) > @@ -956,7 +945,7 @@ > bytes = sizeof(struct kevent) * numevents; > if ((ke = malloc(bytes)) == NULL) > err(1, "Cannot malloc %d bytes for kevent array", bytes); > - if (numevents >= 0 && get_struct(fd, (void *)args[sc->offset], ke, bytes) != -1) { > + if (numevents >= 0 && get_struct(pid, (void *)args[sc->offset], ke, bytes) != -1) { > used = 0; > tmpsize = 1 + per_ke * numevents + 2; > if ((tmp = malloc(tmpsize)) == NULL) > @@ -986,7 +975,7 @@ > case Stat: > { > struct stat st; > - if (get_struct(fd, (void *)args[sc->offset], &st, sizeof(st)) != -1) { > + if (get_struct(pid, (void *)args[sc->offset], &st, sizeof(st)) != -1) { > char mode[12]; > strmode(st.st_mode, mode); > asprintf(&tmp, "{mode=%s,inode=%jd,size=%jd,blksize=%ld}", > @@ -999,7 +988,7 @@ > case Rusage: > { > struct rusage ru; > - if (get_struct(fd, (void *)args[sc->offset], &ru, sizeof(ru)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &ru, sizeof(ru)) != -1) > asprintf(&tmp, "{u=%ld.%06ld,s=%ld.%06ld,in=%ld,out=%ld}", > (long)ru.ru_utime.tv_sec, ru.ru_utime.tv_usec, > (long)ru.ru_stime.tv_sec, ru.ru_stime.tv_usec, > @@ -1011,7 +1000,7 @@ > case Rlimit: > { > struct rlimit rl; > - if (get_struct(fd, (void *)args[sc->offset], &rl, sizeof(rl)) != -1) > + if (get_struct(pid, (void *)args[sc->offset], &rl, sizeof(rl)) != -1) > asprintf(&tmp, "{cur=%ju,max=%ju}", > rl.rlim_cur, rl.rlim_max); > else > ==== //depot/vendor/freebsd/src/usr.bin/truss/truss.1#12 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/truss.1#3 (text+ko) ==== content > @@ -23,7 +23,7 @@ > utility traces the system calls called by the specified process or program. > Output is to the specified output file, or standard error by default. > It does this by stopping and restarting the process being monitored via > -.Xr procfs 5 . > +.Xr ptrace 2 . > .Pp > The options are as follows: > .Bl -tag -width indent > @@ -79,13 +79,6 @@ > .Ar command > options are mutually exclusive.) > .El > -.Pp > -The > -.Xr procctl 8 > -utility can be used to clear tracepoints in a stuck process > -left behind if > -.Nm > -terminates abnormally. > .Sh EXAMPLES > # Follow the system calls used in echoing "hello" > .Dl $ truss /bin/echo hello > @@ -96,8 +89,7 @@ > .Sh SEE ALSO > .Xr kdump 1 , > .Xr ktrace 1 , > -.Xr procfs 5 , > -.Xr procctl 8 > +.Xr ptrace 2 2 > .Sh HISTORY > The > .Nm > ==== //depot/vendor/freebsd/src/usr.bin/truss/truss.h#5 (text+ko) - //depot/user/howardsu/truss/usr.bin/truss/truss.h#4 (text+ko) ==== content > @@ -25,6 +25,8 @@ > * $FreeBSD: src/usr.bin/truss/truss.h,v 1.7 2006/05/15 21:18:28 pav Exp $ > */ > > +#include > + > #define FOLLOWFORKS 0x00000001 > #define RELATIVETIMESTAMPS 0x00000002 > #define ABSOLUTETIMESTAMPS 0x00000004 > @@ -32,17 +34,30 @@ > #define EXECVEARGS 0x00000010 > #define EXECVEENVS 0x00000020 > > +struct threadinfo > +{ > + SLIST_ENTRY(threadinfo) entries; > + lwpid_t tid; > + int in_syscall; > + int in_fork; > +}; > + > struct trussinfo > { > int pid; > int flags; > - int in_fork; > + int pr_why; > + int pr_data; > int strsize; > FILE *outfile; > > struct timespec start_time; > struct timespec before; > struct timespec after; > + > + struct threadinfo *curthread; > + > + SLIST_HEAD(, threadinfo) threadlist; > }; > > #define timespecsubt(tvp, uvp, vvp) \ > @@ -54,3 +69,10 @@ > (vvp)->tv_nsec += 1000000000; \ > } \ > } while (0) > + > +#define S_NONE 0 > +#define S_SCE 1 > +#define S_SCX 2 > +#define S_EXIT 3 > +#define S_SIG 4 > +#define S_EXEC 5 -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 13:40:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC63616A401 for ; Fri, 6 Apr 2007 13:40:13 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAC413C46A for ; Fri, 6 Apr 2007 13:40:13 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1032479ana for ; Fri, 06 Apr 2007 06:40:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RqckEGj3h4vKNgRkHA95b6n4v4GV5XnkbepoVFxbsTCNzoAcGu8FMfA4sRpL0LA9zX6tFXBDAY15HSLZ8Oes/WnQGbMFh2b/GhCxJIBmlwFtGwlDc6sywWBNDYLAd0vZKEZ0E/hZ4UtQRv3omKNQ1wng2siaqjnNglVI5qFVcMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jWBkoH3SZ+reWS2ToLDUaBUItHi83gp73RiCOw1Z7UlReiUprxGJpp47ggaGxjnXitu9JN6622eyR95/Zgd4K4js4x3vmOknc7BoJTNG+Uef5RZftQhT6ldqoANWJ5igiV8bbapHXSKtDorg/VYjHwX2+AVBTmplx+PVBx7uRJ0= Received: by 10.100.166.14 with SMTP id o14mr2077576ane.1175866811825; Fri, 06 Apr 2007 06:40:11 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 06:40:11 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 08:40:11 -0500 From: "Nikolas Britton" To: "Nikolas Britton" , "Peter Jeremy" , "FreeBSD Current" In-Reply-To: <20070405180711.GA60539@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> Cc: Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 13:40:13 -0000 On 4/5/07, Erik Trulsson wrote: > > > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > > (SSE2) processor. > > And 73.45% of all statistics are mainly made up of hot air. > ... > > What makes you think those stats are even half-way accurate or > useful. It is probably a highly biased sample. > I don't appreciate being called a lier. Maybe you should step up to the plate if you don't believe my statistics. AMD Semptron 1,259 AMD Athlon_64 2,796 AMD Athlon_XP 2,885 AMD Athlon 812 AMD Duron 741 AMD Opteron 625 AMD Turion_64 175 Intel Pentium_4 8,768 Intel Pentium_4M 291 Intel Pentium_M 1,722 Intel Pentium_3M 233 Intel Pentium_3 6,362 Intel Pentium_D 982 Intel Pentium_2 1,872 Intel Celeron_P2 888 Intel Celeron_P3 529 Intel Celeron_P4 4,224 Intel Celeron_M 299 Intel Xeon_P4 2,380 Intel Core 1,246 Generic i786 1 Generic i686_SSE 33 Generic i686_MMX 114 Generic i686 298 Generic i586_MMX 520 Generic i586 261 Generic i486 30 Unknown 99 Data source: http://www.bsdstats.org/cpus.php From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 13:52:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65EC916A403 for ; Fri, 6 Apr 2007 13:52:04 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2313613C457 for ; Fri, 6 Apr 2007 13:52:03 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1035629ana for ; Fri, 06 Apr 2007 06:52:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ife1f8O9IryQxfte4zL1gbygPL/9CTpRlnTmooHW7OGY8+oxuZ7cSMtUWGiMhJn2opNXvpJxf8V9BHoWHUlIRSIVhwj31pqWlyx6Ib/ZsKXTulBuqMqtc/tV9+4pqVIAH75GZNN3guNeHouwq1LaSdTaO4HeQGK+NomdN9RzTyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dYSSfdTs9zWEi7NxJIPlWymeAdOI7GxmhK8ICXWzdFxqKeICwaW/4O7P9iwuMgSZ5QvUkwNZ1S34V6teKGvwB0trdJ7jpTQfeO8i7ExPg2cnHT4rLDNzREboJ8U5au5MYAhM0qEAHctOuSjdAH53fXf391ihkgXwLwP4V3ibJhc= Received: by 10.100.31.2 with SMTP id e2mr2100888ane.1175867523567; Fri, 06 Apr 2007 06:52:03 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 06:52:03 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 08:52:03 -0500 From: "Nikolas Britton" To: "John Clark" In-Reply-To: <46153C79.4050404@metricsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <46153C79.4050404@metricsystems.com> Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 13:52:04 -0000 On 4/5/07, John Clark wrote: > Nikolas Britton schrieb: > > On 4/5/07, Peter Jeremy wrote: > >> [-stable removed since it's not relevant there] > >> > >> On 2007-Apr-05 04:58:17 -0500, Nikolas Britton > >> wrote: > >> >Can anything in the list below be removed from CURRENT? > >> > > >> >legacyfree1# cd dev/ > >> >legacyfree1# grep -irsn isa ./ | grep -i include > >> ... > >> >legacyfree1# grep -irsn mca ./ | grep -i include > >> ... > >> > >> Why do you believe anything in the list might need to be removed? > >> > > > > I'd like to also add that 6-STABLE should be the last branch to support: > > 1. ISA / EISA > > 2. PC98 Platform. > > 3. i486 > > 4. i586 > > > > 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > > (SSE2) processor. > > > > Arch Break Down > > i386 5586 94.02% > > amd64 305 5.13% > > sparc64 30 0.50% > > > > x86 Break Down: > > i486 30 0.074% > > ??? 51 0.125% > > i586 404 0.995% > > i686 14724 36.230% > > i786 25431 62.576% > > ----------------------------------- > > Tot: 40640 100% > > > Where to varients figure in, such as Celerons, or non-Intel processor > manufacturers It is broken down by processor capability's. For example, Celeron = (i686_MMX) Celeron 300Mhz = (i686_MMX) Celeron 933Mhz = (i686_MMX/SSE) Celeron 1700Mhz = (i686_SSE2) = (i786) Celeron M = (i686_SSE2) = (i786) Wikipedia was used for most of the conversions, i.e. http://en.wikipedia.org/wiki/List_of_Intel_Celeron_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors I have also post to this thread a more detail list. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:15:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9D6416A401 for ; Fri, 6 Apr 2007 14:15:53 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 97E6613C44C for ; Fri, 6 Apr 2007 14:15:53 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1041796ana for ; Fri, 06 Apr 2007 07:15:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lW/oBHsYBTnyPtup3GZEZaNo2A+KDyXKxmsYsuEjvsoaT0pfj2tnZE/fuWeljW2/607OHA9eFe1JKX5AtQkA5a68D6XF393/7lgEYEZeyVB7F6KNC7q6C0ghirUohKdFb4Al09In68wjei2jJDYTJdNOmYCOmC7lnvXfilroWa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kbnc0jAGWPALTNU9DRmrp16MQBitE7LLeX9dysx12jIS1IGhbLF8/inOdlwxSYuckgY57KQLBleylHtKIUMPEqkTs6hojheENn0hQBhnt78EUz8Ebu98Ixuy5/5FIcbrBcXyipTJAdHq3MjoSSSf0RE2JgTwEJg+4Rc4WnBZrMY= Received: by 10.100.167.7 with SMTP id p7mr2123920ane.1175868952759; Fri, 06 Apr 2007 07:15:52 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 07:15:52 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 09:15:52 -0500 From: "Nikolas Britton" To: "Warner Losh" In-Reply-To: <20070405.140109.39240822.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> Cc: peterjeremy@optushome.com.au, freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:15:53 -0000 On 4/5/07, Warner Losh wrote: > From: "Nikolas Britton" > Subject: Re: Do we need this junk? > Date: Thu, 5 Apr 2007 10:39:41 -0500 > > > On 4/5/07, Peter Jeremy wrote: > > > [-stable removed since it's not relevant there] > > > > > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: > > > >Can anything in the list below be removed from CURRENT? > > > > > > > >legacyfree1# cd dev/ > > > >legacyfree1# grep -irsn isa ./ | grep -i include > > > ... > > > >legacyfree1# grep -irsn mca ./ | grep -i include > > > ... > > > > > > Why do you believe anything in the list might need to be removed? > > > > > > > I'd like to also add that 6-STABLE should be the last branch to support: > > 1. ISA / EISA > > Not going to happen. Maybe EISA, but certainly not ISA, as machines > made today still need it. > > > 2. PC98 Platform. > > What do you care? I mean really, what do you care here. There are > Pentium II class machines that are perfectly good in this class of > machines. I have one and it runs just fine. > > > 3. i486 > > So you want to kill all the soekris boxes? Sorry, not going to > happen. > > > 4. i586 > > These machines still work, and are still popular in the embedded space > due to their lower power consumption. > > Warner > Well based on the stats I've posted maybe it's time to split FreeBSD i386 into two platforms, one for embedded/legacy systems and one for modern systems? The needs for each type of system are diametrically opposed, and the modern ones make up the majority of deployed systems. Perhaps FreeBSD i786 or IA32, with the minimum target being a Willamette based Pentium 4, aka SSE2? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:23:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8375616A402 for ; Fri, 6 Apr 2007 14:23:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 49E5613C465 for ; Fri, 6 Apr 2007 14:23:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C599C1CC22; Fri, 6 Apr 2007 16:23:26 +0200 (CEST) Date: Fri, 6 Apr 2007 16:23:26 +0200 From: Ed Schouten To: Nikolas Britton Message-ID: <20070406142326.GC6950@hoeg.nl> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:23:28 -0000 --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Nikolas Britton wrote: > Well based on the stats I've posted maybe it's time to split FreeBSD > i386 into two platforms, one for embedded/legacy systems and one for > modern systems? The needs for each type of system are diametrically > opposed, and the modern ones make up the majority of deployed systems. > Perhaps FreeBSD i786 or IA32, with the minimum target being a > Willamette based Pentium 4, aka SSE2? So what's the practical advantage of that? That would only break stuff. Compiling a kernel without these options practically does the same thing. --=20 Ed Schouten WWW: http://g-rave.nl/ --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFlfe52SDGA2eCwURArBjAJ90JaDe6YEH4/JM88vHb3Vc1i6fvgCeKfgs TBTBZM4xVgUf+pMN5c6oqL8= =zhTP -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:32:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8091216A404 for ; Fri, 6 Apr 2007 14:32:00 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3E16F13C459 for ; Fri, 6 Apr 2007 14:32:00 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1046139ana for ; Fri, 06 Apr 2007 07:31:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SH82cGVdcJZo+Ndaow5h4Jbrqmw3pwAAVMaUm6TDqLJG2wehPGnu//oW32PIxIPdy07NO00cJ0dGio+XPZ2Zj5lv1UolLJ0w2RvLMp8L1lj4HPS+mvk4Qj9kZwJKvw3XJQJmbqbdAFmBRaQ3GBaKXU2k5ojDUXLVRFTUzXuzQsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dqmSc82ISI54oE12PImm3uHiIJIKF7LtJx3NcGWhIDVsOfR5DmrpFp6MeMuwhTOMpkVZAGMuMUfFjhdXlzavTrkX02qtjPWrAnDu1dz3ikJ48XJscOB4bSS1pyVKRptKXOtCzHn7otkrq7s9X87r5EsN/4igCcA+OQaSbhkRKro= Received: by 10.100.190.8 with SMTP id n8mr2131271anf.1175869919173; Fri, 06 Apr 2007 07:31:59 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 07:31:59 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 09:31:59 -0500 From: "Nikolas Britton" To: "Ed Schouten" In-Reply-To: <20070406142326.GC6950@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:32:00 -0000 On 4/6/07, Ed Schouten wrote: > * Nikolas Britton wrote: > > Well based on the stats I've posted maybe it's time to split FreeBSD > > i386 into two platforms, one for embedded/legacy systems and one for > > modern systems? The needs for each type of system are diametrically > > opposed, and the modern ones make up the majority of deployed systems. > > Perhaps FreeBSD i786 or IA32, with the minimum target being a > > Willamette based Pentium 4, aka SSE2? > > So what's the practical advantage of that? That would only break stuff. > Compiling a kernel without these options practically does the same > thing. > Break what? The primary reason for doing this is optimization and simplification of support / development. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:44:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69FC916A406 for ; Fri, 6 Apr 2007 14:44:49 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 24CCE13C468 for ; Fri, 6 Apr 2007 14:44:48 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1049405ana for ; Fri, 06 Apr 2007 07:44:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=udOQZABgMNSU8KMLtJbGUyp6fXX8rQv7TCRXNdiYkjNbeFpwjU+q4Qqc9suNuaxpXp9CfI5Ppi2ALPnkeGRrR/YwJr46uV8ZiymYqgW8nb7d49i1KMb2FjN01eXxpXpBR6WBhTTw7lr0viqlJRwEVVoDelXlaU+51IfvLyhlhVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nvufhhGUFOkCNFOihY8VvB4WdXm6lM4pytsQDq7o7bQ8P8kdzSgVDGUhm9WwZ9GfSxbQMwkNmVQycldjYa+mk384JLB40dHGIQ5GcYnEzmV5/9YWjDApLfJjExeMxB8pxFqUbJ0+4bOW4cmg+b67Vhj2ttSIBS2XVnp7laFTJUE= Received: by 10.100.152.9 with SMTP id z9mr2152539and.1175870688342; Fri, 06 Apr 2007 07:44:48 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 07:44:48 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 09:44:48 -0500 From: "Nikolas Britton" To: "Scott Sipe" , "FreeBSD Current" In-Reply-To: <73EB6741-1441-4475-A9D8-4D0049BB8D9A@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <73EB6741-1441-4475-A9D8-4D0049BB8D9A@mindspring.com> Cc: Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:44:49 -0000 On 4/6/07, Scott Sipe wrote: > > On Apr 6, 2007, at 10:15 AM, Nikolas Britton wrote: > > > On 4/5/07, Warner Losh wrote: > >> From: "Nikolas Britton" > >> Subject: Re: Do we need this junk? > >> Date: Thu, 5 Apr 2007 10:39:41 -0500 > >> > >> > On 4/5/07, Peter Jeremy wrote: > >> > > [-stable removed since it's not relevant there] > >> > > > >> > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton > >> wrote: > >> > > >Can anything in the list below be removed from CURRENT? > >> > > > > >> > > >legacyfree1# cd dev/ > >> > > >legacyfree1# grep -irsn isa ./ | grep -i include > >> > > ... > >> > > >legacyfree1# grep -irsn mca ./ | grep -i include > >> > > ... > >> > > > >> > > Why do you believe anything in the list might need to be removed? > >> > > > >> > > >> > I'd like to also add that 6-STABLE should be the last branch to > >> support: > >> > 1. ISA / EISA > >> > >> Not going to happen. Maybe EISA, but certainly not ISA, as machines > >> made today still need it. > >> > >> > 2. PC98 Platform. > >> > >> What do you care? I mean really, what do you care here. There are > >> Pentium II class machines that are perfectly good in this class of > >> machines. I have one and it runs just fine. > >> > >> > 3. i486 > >> > >> So you want to kill all the soekris boxes? Sorry, not going to > >> happen. > >> > >> > 4. i586 > >> > >> These machines still work, and are still popular in the embedded > >> space > >> due to their lower power consumption. > >> > >> Warner > >> > > > > Well based on the stats I've posted maybe it's time to split FreeBSD > > i386 into two platforms, one for embedded/legacy systems and one for > > modern systems? The needs for each type of system are diametrically > > opposed, and the modern ones make up the majority of deployed systems. > > Perhaps FreeBSD i786 or IA32, with the minimum target being a > > Willamette based Pentium 4, aka SSE2? > > > > I was just wanted to let you know, that whoever you thought called > you a liar earlier, absolutely did not. They just said that they > didn't trust that the bsdstats.org statistics were representative-- > which they're not. > What data do you have to back that claim up? Unless you have real quantitative data to support your claims the bsdstats.org statistics stand as an accurate representative sample of the population... i.e. it's *1000% better the your sample size of one. *made up number. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:48:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34EA116A401 for ; Fri, 6 Apr 2007 14:48:01 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A0A1B13C455 for ; Fri, 6 Apr 2007 14:48:00 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l36Elxvk082263; Fri, 6 Apr 2007 16:47:59 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l36Elpj9081712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 16:47:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l36Elpue013259; Fri, 6 Apr 2007 16:47:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l36EloJR013258; Fri, 6 Apr 2007 16:47:50 +0200 (CEST) (envelope-from ticso) Date: Fri, 6 Apr 2007 16:47:50 +0200 From: Bernd Walter To: Nikolas Britton Message-ID: <20070406144749.GX8831@cicely12.cicely.de> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:48:01 -0000 On Fri, Apr 06, 2007 at 08:40:11AM -0500, Nikolas Britton wrote: > On 4/5/07, Erik Trulsson wrote: > >> > >> 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > >> (SSE2) processor. > > > >And 73.45% of all statistics are mainly made up of hot air. > > > ... > > > >What makes you think those stats are even half-way accurate or > >useful. It is probably a highly biased sample. > > > > I don't appreciate being called a lier. Maybe you should step up to > the plate if you don't believe my statistics. I personally have something about 40 486 in use right now and I'm not the only one. This is more then twice your number on 486 systems. These are rather new systems and there for a good reason. Just reaslise that your numbers can't be correct. Lots of people publishing their systems do this for penis enlarging purpose and this requires having a big system and biasing the statistics. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:55:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D10B16A40A for ; Fri, 6 Apr 2007 14:55:11 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id C9B9513C4B8 for ; Fri, 6 Apr 2007 14:55:10 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id l36Et9rh059040; Fri, 6 Apr 2007 16:55:09 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l36EsYjH032002; Fri, 6 Apr 2007 16:54:34 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l36EsYo4032001; Fri, 6 Apr 2007 16:54:34 +0200 (CEST) (envelope-from wb) Date: Fri, 6 Apr 2007 16:54:34 +0200 From: Wilko Bulte To: Nikolas Britton Message-ID: <20070406145434.GA31977@freebie.xs4all.nl> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <73EB6741-1441-4475-A9D8-4D0049BB8D9A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: FreeBSD Current , Scott Sipe Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:55:12 -0000 On Fri, Apr 06, 2007 at 09:44:48AM -0500, Nikolas Britton wrote.. > On 4/6/07, Scott Sipe wrote: > > > >On Apr 6, 2007, at 10:15 AM, Nikolas Britton wrote: > > > >> On 4/5/07, Warner Losh wrote: > >>> From: "Nikolas Britton" > >>> Subject: Re: Do we need this junk? > >>> Date: Thu, 5 Apr 2007 10:39:41 -0500 > >>> > >>> > On 4/5/07, Peter Jeremy wrote: > >>> > > [-stable removed since it's not relevant there] > >>> > > > >>> > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton > >>> wrote: > >>> > > >Can anything in the list below be removed from CURRENT? > >>> > > > > >>> > > >legacyfree1# cd dev/ > >>> > > >legacyfree1# grep -irsn isa ./ | grep -i include > >>> > > ... > >>> > > >legacyfree1# grep -irsn mca ./ | grep -i include > >>> > > ... > >>> > > > >>> > > Why do you believe anything in the list might need to be removed? > >>> > > > >>> > > >>> > I'd like to also add that 6-STABLE should be the last branch to > >>> support: > >>> > 1. ISA / EISA > >>> > >>> Not going to happen. Maybe EISA, but certainly not ISA, as machines > >>> made today still need it. > >>> > >>> > 2. PC98 Platform. > >>> > >>> What do you care? I mean really, what do you care here. There are > >>> Pentium II class machines that are perfectly good in this class of > >>> machines. I have one and it runs just fine. > >>> > >>> > 3. i486 > >>> > >>> So you want to kill all the soekris boxes? Sorry, not going to > >>> happen. > >>> > >>> > 4. i586 > >>> > >>> These machines still work, and are still popular in the embedded > >>> space > >>> due to their lower power consumption. > >>> > >>> Warner > >>> > >> > >> Well based on the stats I've posted maybe it's time to split FreeBSD > >> i386 into two platforms, one for embedded/legacy systems and one for > >> modern systems? The needs for each type of system are diametrically > >> opposed, and the modern ones make up the majority of deployed systems. > >> Perhaps FreeBSD i786 or IA32, with the minimum target being a > >> Willamette based Pentium 4, aka SSE2? > >> > > > >I was just wanted to let you know, that whoever you thought called > >you a liar earlier, absolutely did not. They just said that they > >didn't trust that the bsdstats.org statistics were representative-- > >which they're not. > > > > What data do you have to back that claim up? Unless you have real > quantitative data to support your claims the bsdstats.org statistics > stand as an accurate representative sample of the population... i.e. > it's *1000% better the your sample size of one. How about you going somewhere else, telling people what to do? There have been ample people explaining you why FreeBSD is the way it is, and why it is not due to change to reflect your tastes anytime soon. If you don't like that, tough. Go run Linux, Windows or whatever suits you and leave this list alone. Thank you, Wilko -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 14:56:39 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6432316A403 for ; Fri, 6 Apr 2007 14:56:39 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 10FB413C45E for ; Fri, 6 Apr 2007 14:56:38 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so526721nza for ; Fri, 06 Apr 2007 07:56:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WQvGEcxMnVSwNVGP3eTjEkQLN4aqGCNVljdS8SPNxL/w10kDWCrqIvJaP6LkKis4W4duDIdwrMRYT7+PrBdPdtHzCFivxZCBmyW/WsNHdsxdY4ogKMqCGMTvCjoxcmc64pOMAzks0vU9Kzn/8ZqPe/jKlFhvJkYPEDn1wbgCbsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o4ieAMsRyns4AyHa4jqEnE/8AtDAt8+Cb0XQPQOQ6qYjlLGPsXWQaDV3nrrVOMbxOQDJ+2q29t8Ve0g+rsdb7Zwfm3oy504sf/ZA2teU0j12xqcHRx1Mzv0KaTB6jDUdnYnVWMvmFGdLyEEH9A96gI5yNfbQarmvgm5mp/mdLeE= Received: by 10.115.93.16 with SMTP id v16mr1242283wal.1175871397869; Fri, 06 Apr 2007 07:56:37 -0700 (PDT) Received: by 10.114.241.12 with HTTP; Fri, 6 Apr 2007 07:56:37 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 22:56:37 +0800 From: "Howard Su" To: "Alfred Perlstein" In-Reply-To: <20070406125940.GN2382@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406125940.GN2382@elvis.mu.org> Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 14:56:39 -0000 On 4/6/07, Alfred Perlstein wrote: > > nit: you have new functions like this "void fun(args)", they should > be in the form of "void\nfun(args)" (newline after return type) I will do a style cleanup. > > possible issue: is get_string equivelant to the procfs version? > meaning, if there's a string that ends at a strange place in the > address space will it work any differently? I uses a different way. I preallocate a buf to use ptrace to fill it once. I limit the size to 1024 as a magic number. if the actual string length is smaller than 1024 and has a NUL teminate character, we will ignore the left chars. (little performance issue). if the actual length is larger than 1024, i place a NUL at 1024. so it will be also safe. I think this is not a perfect solution. I willing to change it to respect -s args. -s strsize Display strings using at most strsize characters. If the buffer is larger, "..." will be displayed at the end of the string. The default strsize is 32. > > note how the procfs version does a fgetc(3) over and over and > stops reading if it hits \0, while the version you have tried > to read the entire buf. Can that cause issues? > Thanks, Howard From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 15:13:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BE1A16A402 for ; Fri, 6 Apr 2007 15:13:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C65C913C4B8 for ; Fri, 6 Apr 2007 15:13:45 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l36FDbY9090343; Fri, 6 Apr 2007 09:13:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46166395.9090000@samsco.org> Date: Fri, 06 Apr 2007 09:13:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Nikolas Britton References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 06 Apr 2007 09:13:39 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 15:13:46 -0000 Nikolas Britton wrote: > On 4/6/07, Ed Schouten wrote: >> * Nikolas Britton wrote: >> > Well based on the stats I've posted maybe it's time to split FreeBSD >> > i386 into two platforms, one for embedded/legacy systems and one for >> > modern systems? The needs for each type of system are diametrically >> > opposed, and the modern ones make up the majority of deployed systems. >> > Perhaps FreeBSD i786 or IA32, with the minimum target being a >> > Willamette based Pentium 4, aka SSE2? >> >> So what's the practical advantage of that? That would only break stuff. >> Compiling a kernel without these options practically does the same >> thing. >> > > Break what? The primary reason for doing this is optimization and > simplification of support / development. Your input on the development process of FreeBSD has been received and will be filed for future consideration. Thank you for your concern. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 15:17:58 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49CCD16A403 for ; Fri, 6 Apr 2007 15:17:58 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id EF1B613C459 for ; Fri, 6 Apr 2007 15:17:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DAE8A8BCF47; Fri, 6 Apr 2007 17:17:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n9j81Wvli6O; Fri, 6 Apr 2007 17:17:54 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 98A408BCEEC; Fri, 6 Apr 2007 17:17:54 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l36FHsCA087532; Fri, 6 Apr 2007 17:17:54 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 6 Apr 2007 17:17:53 +0200 From: Roman Divacky To: Pawel Jakub Dawidek Message-ID: <20070406151753.GA87518@freebsd.org> References: <20070406025700.GB98545@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 15:17:58 -0000 On Fri, Apr 06, 2007 at 04:57:00AM +0200, Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. > > Commit log: > > Please welcome ZFS - The last word in file systems. this is incredibly great! thnx.. do you have any benchmark numbers? I saw some in your *con paper but since then we got new sx locks and you did some performance improvements as well.. I am just curious :) thnx again! roman From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 15:35:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A728816A403 for ; Fri, 6 Apr 2007 15:35:02 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6C14913C455 for ; Fri, 6 Apr 2007 15:35:02 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C0B021CC6E; Fri, 6 Apr 2007 17:35:00 +0200 (CEST) Date: Fri, 6 Apr 2007 17:35:00 +0200 From: Ed Schouten To: Nikolas Britton Message-ID: <20070406153500.GE6950@hoeg.nl> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7CZp05NP8/gJM8Cl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 15:35:02 -0000 --7CZp05NP8/gJM8Cl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Nikolas Britton wrote: > On 4/6/07, Ed Schouten wrote: > >* Nikolas Britton wrote: > >> Well based on the stats I've posted maybe it's time to split FreeBSD > >> i386 into two platforms, one for embedded/legacy systems and one for > >> modern systems? The needs for each type of system are diametrically > >> opposed, and the modern ones make up the majority of deployed systems. > >> Perhaps FreeBSD i786 or IA32, with the minimum target being a > >> Willamette based Pentium 4, aka SSE2? > > > >So what's the practical advantage of that? That would only break stuff. > >Compiling a kernel without these options practically does the same > >thing. > > >=20 > Break what? Renaming a platform is the root of all evil. Think about the big amount of ports and source code that just check for $arch =3D=3D "i386". That's the reason the i386 port is still named i386, though it doesn't even support i386 at all (got removed in 6.x). > The primary reason for doing this is optimization and simplification > of support / development. Indeed. You'll simplify development, because half of the developers is unable to run the bloody thing. Just run FreeBSD/amd64 if the legacy bits upset you. --=20 Ed Schouten WWW: http://g-rave.nl/ --7CZp05NP8/gJM8Cl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFmik52SDGA2eCwURAlQNAJ0WO0+/U2KKD8AmJE5SUMn4V9CzAACfQvgD cV4HOyu98jANhjfbWp9EGkg= =o278 -----END PGP SIGNATURE----- --7CZp05NP8/gJM8Cl-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 15:42:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91E1D16A402 for ; Fri, 6 Apr 2007 15:42:45 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2D04A13C469 for ; Fri, 6 Apr 2007 15:42:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l36FgZrL090451; Fri, 6 Apr 2007 09:42:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46166A5E.3090009@samsco.org> Date: Fri, 06 Apr 2007 09:42:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Ed Schouten References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> In-Reply-To: <20070406153500.GE6950@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 06 Apr 2007 09:42:36 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD Current , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 15:42:45 -0000 Ed Schouten wrote: > * Nikolas Britton wrote: >> On 4/6/07, Ed Schouten wrote: >>> * Nikolas Britton wrote: >>>> Well based on the stats I've posted maybe it's time to split FreeBSD >>>> i386 into two platforms, one for embedded/legacy systems and one for >>>> modern systems? The needs for each type of system are diametrically >>>> opposed, and the modern ones make up the majority of deployed systems. >>>> Perhaps FreeBSD i786 or IA32, with the minimum target being a >>>> Willamette based Pentium 4, aka SSE2? >>> So what's the practical advantage of that? That would only break stuff. >>> Compiling a kernel without these options practically does the same >>> thing. >>> >> Break what? > > Renaming a platform is the root of all evil. Think about the big amount > of ports and source code that just check for $arch == "i386". That's the > reason the i386 port is still named i386, though it doesn't even support > i386 at all (got removed in 6.x). > >> The primary reason for doing this is optimization and simplification >> of support / development. > > Indeed. You'll simplify development, because half of the developers is > unable to run the bloody thing. Just run FreeBSD/amd64 if the legacy > bits upset you. > Better yet, there are plenty of hobby OS's like DragonFlyBSD that have taken deliberate steps to remove "useless bits". I suggest Nikolas dictate development practices to them instead of us. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 15:57:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA60616A402 for ; Fri, 6 Apr 2007 15:57:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CBB8813C455 for ; Fri, 6 Apr 2007 15:57:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 47DF01A4D82; Fri, 6 Apr 2007 08:57:16 -0700 (PDT) Date: Fri, 6 Apr 2007 08:57:16 -0700 From: Alfred Perlstein To: Howard Su Message-ID: <20070406155716.GO2382@elvis.mu.org> References: <20070406125940.GN2382@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org Subject: Re: [Review] Remove procfs dependency of truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 15:57:15 -0000 * Howard Su [070406 08:00] wrote: > On 4/6/07, Alfred Perlstein wrote: > > > >nit: you have new functions like this "void fun(args)", they should > >be in the form of "void\nfun(args)" (newline after return type) > I will do a style cleanup. > > > >possible issue: is get_string equivelant to the procfs version? > >meaning, if there's a string that ends at a strange place in the > >address space will it work any differently? > I uses a different way. I preallocate a buf to use ptrace to fill it > once. I limit the size to 1024 as a magic number. if the actual string > length is smaller than 1024 and has a NUL teminate character, we will > ignore the left chars. (little performance issue). if the actual > length is larger than 1024, i place a NUL at 1024. so it will be also > safe. I think you'll want to preserve the existing behavior, which is not to hard limit the max to 1024. Otherwise along with the style fixes, it looks good! -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 16:14:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4466E16A401; Fri, 6 Apr 2007 16:14:11 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a6.g.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207]) by mx1.freebsd.org (Postfix) with ESMTP id 29CCB13C45D; Fri, 6 Apr 2007 16:14:11 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.1.2] (68-184-120-224.dhcp.smyr.ga.charter.com [68.184.120.224]) by spunkymail-a6.g.dreamhost.com (Postfix) with ESMTP id 81DB5109F2F; Fri, 6 Apr 2007 09:14:10 -0700 (PDT) Message-ID: <461671CF.6060903@cyberwang.net> Date: Fri, 06 Apr 2007 12:14:07 -0400 From: Sean Bryant User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> <4615BCA4.7030109@cyberwang.net> <20070406104004.GB1251@garage.freebsd.pl> In-Reply-To: <20070406104004.GB1251@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 16:14:11 -0000 Pawel Jakub Dawidek wrote: > On Fri, Apr 06, 2007 at 10:36:52AM +0200, Ivan Voras wrote: > >> Sean Bryant wrote: >> >> >>> Is it fully 128bit? From wikipedia, which is by no means an authoritative source but I have no idea if this was ever an issue. >>> >> It's 64-bit even in Solaris. The "128-bitness" is only in the storage format, not for file system ops visible to applications. >> >> (AFAIK). >> > > That's correct. We are limited by POSIX, but the on-disk format is > 128bit. > > Thanks for the update, I'll probably update that Wikipedia entry to reflect recent changes and more correctly state the limitations. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 17:38:57 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D5416A401 for ; Fri, 6 Apr 2007 17:38:57 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 526B713C465 for ; Fri, 6 Apr 2007 17:38:57 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l36Hctxk050676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Apr 2007 02:38:55 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 7 Apr 2007 02:38:55 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org Message-Id: <20070407023855.ede13b76.nork@FreeBSD.org> X-Mailer: Sylpheed 2.4.0beta7 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sat, 07 Apr 2007 02:38:55 +0900 (JST) Cc: Subject: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 17:38:57 -0000 Hi. I noticed that recently 7-current has a linprocfs kernel module has a problem. - - - - - - - - - - - - - - - - - - - - - - - - - - - $ dmesg -a (snip) Mounting local file systems: link_elf: symbol msginfo undefined mount: linprocfs : Operation not supported by device . (snip) - - - - - - - - - - - - - - - - - - - - - - - - - - - I seperated sysv* subsystems as kernel modules, so I found. # kldstat | fgrep sysv 6 3 0xc07fd000 4914 sysvmsg.ko 7 3 0xc0802000 6384 sysvsem.ko 8 2 0xc0809000 4b84 sysvshm.ko Please validate following patch and fix this issue. Index: linprocfs.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linprocfs/linprocfs.c,v retrieving revision 1.108 diff -u -r1.108 linprocfs.c --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 @@ -1238,3 +1238,5 @@ PSEUDOFS(linprocfs, 1); MODULE_DEPEND(linprocfs, linux, 1, 1, 1); MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 17:43:10 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FDEA16A404 for ; Fri, 6 Apr 2007 17:43:10 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 00D6213C448 for ; Fri, 6 Apr 2007 17:43:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8FC6D8BCF4A; Fri, 6 Apr 2007 19:43:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jih+9fC7WPxA; Fri, 6 Apr 2007 19:43:06 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 15F438BCEEC; Fri, 6 Apr 2007 19:43:06 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l36Hh5YE090275; Fri, 6 Apr 2007 19:43:05 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 6 Apr 2007 19:43:05 +0200 From: Roman Divacky To: Norikatsu Shigemura Message-ID: <20070406174305.GA90217@freebsd.org> References: <20070407023855.ede13b76.nork@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407023855.ede13b76.nork@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@FreeBSD.org Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 17:43:10 -0000 > Index: linprocfs.c > =================================================================== > RCS file: /home/ncvs/src/sys/compat/linprocfs/linprocfs.c,v > retrieving revision 1.108 > diff -u -r1.108 linprocfs.c > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > @@ -1238,3 +1238,5 @@ > PSEUDOFS(linprocfs, 1); > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); I dont like this, I would prefer some dynamic determining whether sysv symbols are present and if not just fill in "safe" values. is there a way to do this nicely? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 17:51:36 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6258516A40E for ; Fri, 6 Apr 2007 17:51:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 27D6813C4CB for ; Fri, 6 Apr 2007 17:51:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l36HpWG7015634; Fri, 6 Apr 2007 13:51:32 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 6 Apr 2007 13:51:20 -0400 User-Agent: KMail/1.6.2 References: <20070407023855.ede13b76.nork@FreeBSD.org> In-Reply-To: <20070407023855.ede13b76.nork@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704061351.30424.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/3029/Fri Apr 6 12:53:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 17:51:36 -0000 On Friday 06 April 2007 01:38 pm, Norikatsu Shigemura wrote: > Hi. > > I noticed that recently 7-current has a linprocfs kernel module > has a problem. --- SKIP!!! --- Mea Culpa. > Index: linprocfs.c > =================================================================== > RCS file: /home/ncvs/src/sys/compat/linprocfs/linprocfs.c,v > retrieving revision 1.108 > diff -u -r1.108 linprocfs.c > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > @@ -1238,3 +1238,5 @@ > PSEUDOFS(linprocfs, 1); > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); Looks good. I will commit it shortly. BTW, 'linux' module depends on these modules. Is loading 'dependency of dependency' broken? Should we have to explicitly tell it to load the dependencies? Am I missing something here? :-( Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:07:38 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D690316A407; Fri, 6 Apr 2007 18:07:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7D34713C455; Fri, 6 Apr 2007 18:07:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l36I7bm5016755; Fri, 6 Apr 2007 14:07:37 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 6 Apr 2007 14:07:27 -0400 User-Agent: KMail/1.6.2 References: <20070407023855.ede13b76.nork@FreeBSD.org> <20070406174305.GA90217@freebsd.org> In-Reply-To: <20070406174305.GA90217@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704061407.35340.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/3029/Fri Apr 6 12:53:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Roman Divacky , Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:07:38 -0000 On Friday 06 April 2007 01:43 pm, Roman Divacky wrote: > > Index: linprocfs.c > > ================================================================= > >== RCS file: /home/ncvs/src/sys/compat/linprocfs/linprocfs.c,v > > retrieving revision 1.108 > > diff -u -r1.108 linprocfs.c > > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > > @@ -1238,3 +1238,5 @@ > > PSEUDOFS(linprocfs, 1); > > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); > > I dont like this, I would prefer some dynamic determining > whether sysv symbols are present and if not just fill > in "safe" values. You know I have used sysctlbyname before but it was shot down by des. :-( > is there a way to do this nicely? Probably we can improve kernel linker to do better job. ;-) I mean, load all dependencies before look up symbols. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:08:56 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78AB116A403; Fri, 6 Apr 2007 18:08:56 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id F282C13C487; Fri, 6 Apr 2007 18:08:55 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l36I8sTj051671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 03:08:54 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 7 Apr 2007 03:08:54 +0900 From: Norikatsu Shigemura To: Roman Divacky Message-Id: <20070407030854.3aa6f9a7.nork@FreeBSD.org> In-Reply-To: <20070406174305.GA90217@freebsd.org> References: <20070407023855.ede13b76.nork@FreeBSD.org> <20070406174305.GA90217@freebsd.org> X-Mailer: Sylpheed 2.4.0beta7 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sat, 07 Apr 2007 03:08:54 +0900 (JST) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:08:56 -0000 On Fri, 6 Apr 2007 19:43:05 +0200 Roman Divacky wrote: > > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > > @@ -1238,3 +1238,5 @@ > > PSEUDOFS(linprocfs, 1); > > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); > I dont like this, I would prefer some dynamic determining > whether sysv symbols are present and if not just fill > in "safe" values. > is there a way to do this nicely? safe values? Ah, that's solution is not good. When linprocfs is loaded, if sysvmsg or sysvsem module is not(or not loaded), these modules should be loaded. And you know well thus modules like snd_*. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:11:41 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F79616A401; Fri, 6 Apr 2007 18:11:41 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id DE72D13C48C; Fri, 6 Apr 2007 18:11:40 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id EFEA58BCF4B; Fri, 6 Apr 2007 20:11:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk-5OOytgqXy; Fri, 6 Apr 2007 20:11:39 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E9FD08BCEEC; Fri, 6 Apr 2007 20:11:38 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l36IBcUj090910; Fri, 6 Apr 2007 20:11:38 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 6 Apr 2007 20:11:38 +0200 From: Roman Divacky To: Jung-uk Kim Message-ID: <20070406181138.GA90738@freebsd.org> References: <20070407023855.ede13b76.nork@FreeBSD.org> <20070406174305.GA90217@freebsd.org> <200704061407.35340.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704061407.35340.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:11:41 -0000 > > is there a way to do this nicely? > > Probably we can improve kernel linker to do better job. ;-) I mean, > load all dependencies before look up symbols. thats not what I mean.. what I want is something like if (function_present(foo)) x = foo(); else x = SAFE_VALUE; use x somehow; so we don't have to have all modules loaded etc. the same could be done for some syscalls, imagine linux_foo(params) { if (function_present(foo)) return foo(params); else return ENOSYS; } I like this better then loading all possible modules. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:26:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAAFE16A405; Fri, 6 Apr 2007 18:26:44 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 6E84913C4BE; Fri, 6 Apr 2007 18:26:44 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l36IQhQT052265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 03:26:43 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 7 Apr 2007 03:26:43 +0900 From: Norikatsu Shigemura To: Jung-uk Kim Message-Id: <20070407032643.72fd55df.nork@FreeBSD.org> In-Reply-To: <200704061351.30424.jkim@FreeBSD.org> References: <20070407023855.ede13b76.nork@FreeBSD.org> <200704061351.30424.jkim@FreeBSD.org> X-Mailer: Sylpheed 2.4.0beta7 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sat, 07 Apr 2007 03:26:43 +0900 (JST) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:26:44 -0000 On Fri, 6 Apr 2007 13:51:20 -0400 Jung-uk Kim wrote: > > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > > @@ -1238,3 +1238,5 @@ > > PSEUDOFS(linprocfs, 1); > > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); > Looks good. I will commit it shortly. > BTW, 'linux' module depends on these modules. Is loading 'dependency > of dependency' broken? Should we have to explicitly tell it to load > the dependencies? Am I missing something here? :-( 'dependency of dependency' you saied is not broken. It's specification:-) of kernel symbol resolver. It can resolve one level export symbols:-(. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:36:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AA7716A402 for ; Fri, 6 Apr 2007 18:36:32 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id A1C2D13C480 for ; Fri, 6 Apr 2007 18:36:31 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1107774ana for ; Fri, 06 Apr 2007 11:36:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KfVgsH5mWg1kd6xugcVcvwUWS/i9AnEC7cyECsqIN1D/o/xyVAnCuS5UFp9/fXSum0iTL+2lCfMVTgHlaZs8axDnHdVk8Q0DuL96m+WOG8A6Qbpbs/0wnRlIYuTXZ0SjuUF2tSTlVrsKXXyL4U6/QNYNad5XZy+sOl2VMvwFQow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gMeYTcEVZS0i1F4WNye2DyT9w8WscYF95EEtT50Jne654ByKV8oa8GdEWBRC1MU6CWpf6cQzz/KrK6hRPk+RdnJ3ns7WcqZwD1RsarZ9imeyjW/Hc+MEnyMc5TctiezO8aX+oy0nAAWV6cvVdkqIUqGB2tWQykYteHFiXXiXeBY= Received: by 10.100.190.8 with SMTP id n8mr2256849anf.1175884591089; Fri, 06 Apr 2007 11:36:31 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 11:36:31 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 13:36:31 -0500 From: "Nikolas Britton" To: "Scott Long" In-Reply-To: <46166A5E.3090009@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:36:32 -0000 On 4/6/07, Scott Long wrote: > Ed Schouten wrote: > > * Nikolas Britton wrote: > >> On 4/6/07, Ed Schouten wrote: > >>> * Nikolas Britton wrote: > >>>> Well based on the stats I've posted maybe it's time to split FreeBSD > >>>> i386 into two platforms, one for embedded/legacy systems and one for > >>>> modern systems? The needs for each type of system are diametrically > >>>> opposed, and the modern ones make up the majority of deployed systems. > >>>> Perhaps FreeBSD i786 or IA32, with the minimum target being a > >>>> Willamette based Pentium 4, aka SSE2? > >>> So what's the practical advantage of that? That would only break stuff. > >>> Compiling a kernel without these options practically does the same > >>> thing. > >>> > >> Break what? > > > > Renaming a platform is the root of all evil. Think about the big amount > > of ports and source code that just check for $arch == "i386". That's the > > reason the i386 port is still named i386, though it doesn't even support > > i386 at all (got removed in 6.x). > > > >> The primary reason for doing this is optimization and simplification > >> of support / development. > > > > Indeed. You'll simplify development, because half of the developers is > > unable to run the bloody thing. Just run FreeBSD/amd64 if the legacy > > bits upset you. > > > > Better yet, there are plenty of hobby OS's like DragonFlyBSD that have > taken deliberate steps to remove "useless bits". I suggest Nikolas > dictate development practices to them instead of us. > Where is this coming from? I'm trying to debate some of the issues with FreeBSD and the only thing you've added to this thread is fuck off? Why? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:38:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92AA016A402 for ; Fri, 6 Apr 2007 18:38:11 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 303AC13C45E for ; Fri, 6 Apr 2007 18:38:10 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id l36Ic9co094894; Fri, 6 Apr 2007 20:38:09 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 Apr 2007 20:37:34 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB011159@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ZFS committed to the FreeBSD base. Thread-Index: Acd4QvFpkS66i6ebTs+qMiYsMZ+tMgAN7NEP References: <20070406025700.GB98545@garage.freebsd.pl><4615F62A.5090001@FreeBSD.org><20070406052701.E30801@fledge.watson.org> <20070406115557.GF1251@garage.freebsd.pl> From: "Johan Hendriks" To: "Pawel Jakub Dawidek" X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: RE: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:38:11 -0000 =20 Great stuff. =20 Does it also needs mentioning in /boot/defaults/loader.conf to load the = zfs module. =20 regards, Johan From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:43:18 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A4DB16A402; Fri, 6 Apr 2007 18:43:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2A44913C4C6; Fri, 6 Apr 2007 18:43:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l36IhHVO018761; Fri, 6 Apr 2007 14:43:17 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 6 Apr 2007 14:43:13 -0400 User-Agent: KMail/1.6.2 References: <20070407023855.ede13b76.nork@FreeBSD.org> <200704061407.35340.jkim@FreeBSD.org> <20070406181138.GA90738@freebsd.org> In-Reply-To: <20070406181138.GA90738@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704061443.15071.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/3029/Fri Apr 6 12:53:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Roman Divacky , Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:43:18 -0000 On Friday 06 April 2007 02:11 pm, Roman Divacky wrote: > > > is there a way to do this nicely? > > > > Probably we can improve kernel linker to do better job. ;-) I > > mean, load all dependencies before look up symbols. > > thats not what I mean.. what I want is something like > > if (function_present(foo)) > x = foo(); > else > x = SAFE_VALUE; > > use x somehow; > > so we don't have to have all modules loaded etc. the same could be > done for some syscalls, imagine > > linux_foo(params) > { > if (function_present(foo)) > return foo(params); > else > return ENOSYS; > } > > I like this better then loading all possible modules. I know what you meant but it is more heavier than what we have now. If you insist, you can do something like linux_ipc.c. Check out linux_msgctl() and linux_semctl(). Module presence check is easy. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 18:56:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15A7716A415 for ; Fri, 6 Apr 2007 18:56:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outP.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id ABF9513C458 for ; Fri, 6 Apr 2007 18:56:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 06 Apr 2007 11:25:56 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id BA7D4125B02; Fri, 6 Apr 2007 11:56:05 -0700 (PDT) Message-ID: <461697C3.8000700@elischer.org> Date: Fri, 06 Apr 2007 11:56:03 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Nikolas Britton References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 18:56:08 -0000 Nikolas Britton wrote: > > Where is this coming from? I'm trying to debate some of the issues > with FreeBSD and the only thing you've added to this thread is fuck > off? Why? ok, (takes deep breath) Almost every time we make a change to teh OS we make a dicision, not only about the new feature, but about compatibility issues and legacy support. Yes there are some (very small) things that we might not be able to take advantage of by supporting old hardware but by and large we attempt to allow the OS to run on old and new hardware, and makign sure that the new features are availaible. That is why all these things are optional and can be selected in or out of a system. I think some of the frustration people have shown with you is because you don't seem to appreciate how much this issue is constantly thought about and how the current state is not just an "accident of history". We have a LOT of old systems running around the world. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 19:02:40 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D37B516A405 for ; Fri, 6 Apr 2007 19:02:40 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 8165313C4C7 for ; Fri, 6 Apr 2007 19:02:38 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 6 Apr 2007 18:35:55 -0000 Date: Fri, 6 Apr 2007 21:35:29 +0300 From: Nikolay Pavlov To: freebsd-current@FreeBSD.org Message-ID: <20070406183529.GA5676@zone3000.net> Mail-Followup-To: Nikolay Pavlov , freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Cc: Subject: ndis panic on current from (March 29) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 19:02:41 -0000 Hi. I have a panic on my notebook with current from March 29. I've got it while shutting down. Here is details: root@orion:/usr/obj/usr/src/sys/GENERIC# kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <118>Writing entropy file: <118>. <118>Terminated <118>. <5>ndis0: link state changed to DOWN <118>Apr 5 23:08:44 orion syslogd: exiting on signal 15 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ntoskrnl dispatch lock (NDIS lock) r = 0 (0xc0d31554) locked @ /usr/src/sys/modules/ndis/../../compat/ndis/subr_ntoskrnl.c:3599 KDB: stack backtrace: db_trace_self_wrapper(c094ddcd) at db_trace_self_wrapper+0x25 kdb_backtrace(1,c3ef2900,c,e288ec14,e288ec08,...) at kdb_backtrace+0x29 witness_warn(5,0,c097456d) at witness_warn+0x192 trap(e288ec14) at trap+0x10b calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc06d0605, esp = 0xe288ec54, ebp = 0xe288ec60 --- _callout_stop_safe(deadc0de,0,c428d508,e288ec98,c0d293bb,...) at _callout_stop_safe+0x19 ntoskrnl_remove_timer(c0d31554,0,c0d2dbc2,e0f,e288eccc,...) at ntoskrnl_remove_timer+0xf ntoskrnl_timercall(c428d508) at ntoskrnl_timercall+0x27 softclock(0) at softclock+0x22f ithread_execute_handlers(c3ef2900,c3f31280) at ithread_execute_handlers+0x121 ithread_loop(c3e9fbe0,e288ed38) at ithread_loop+0x67 fork_exit(c06aea04,c3e9fbe0,e288ed38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe288ed70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20315f47 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d0605 stack pointer = 0x28:0xe288ec54 frame pointer = 0x28:0xe288ec60 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock sio) panic: from debugger cpuid = 0 Uptime: 1h29m53s Physical memory: 1003 MB Dumping 170 MB: 155 139 123 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:172 172 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xc06c2f68 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06c3272 in panic (fmt=0xc090923c "from debugger") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc047780e in db_panic (addr=-1066596859, have_addr=0, count=-1, modif=0xe288ea4c "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc04777a7 in db_command (last_cmdp=0xc0a23a44, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #5 0xc0477862 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #6 0xc04794ad in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc06e2170 in kdb_trap (type=12, code=0, tf=0xe288ec14) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc08c0b39 in trap_fatal (frame=0xe288ec14, eva=540106567) at /usr/src/sys/i386/i386/trap.c:859 #9 0xc08c01bf in trap (frame=0xe288ec14) at /usr/src/sys/i386/i386/trap.c:276 #10 0xc08aa5eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #11 0xc06d0605 in _callout_stop_safe (c=0xdeadc0de, safe=0) at /usr/src/sys/kern/kern_timeout.c:489 #12 0xc0d2908b in ?? () #13 0xdeadc0de in ?? () #14 0x00000000 in ?? () #15 0xc428d508 in ?? () #16 0xe288ec98 in ?? () #17 0xc0d293bb in ?? () #18 0xc0d31554 in ?? () #19 0x00000000 in ?? () #20 0xc0d2dbc2 in ?? () #21 0x00000e0f in ?? () #22 0xe288eccc in ?? () #23 0xc06d018a in softclock (dummy=0xc0d31554) at /usr/src/sys/kern/kern_timeout.c:238 Previous frame inner to this frame (corrupt stack?) Notebook Dell Inspiron 1300 with GENERIC kernel. ndis0@pci2:3:0: class=0x028000 card=0x00051028 chip=0x431914e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Dell Wireless 1470 DualBand WLAN' class = network /etc/wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel # # office network; allow all valid ciphers network={ ssid="xxxxxxx" scan_ssid=1 key_mgmt=WPA-PSK psk="xxxxxxxxxxxxxxxxxxxx" } /etc/rc.conf: ifconfig_ndis0="ssid xxxxxxx" ifconfig_ndis0="wpa inet 10.1.1.232 netmask 0xffffff00" Also i have found that if i don't use it for some time i have to up/down ndis interface to be able to use it again. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 19:05:23 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E4F916A4D0; Fri, 6 Apr 2007 19:05:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2792F13C4C1; Fri, 6 Apr 2007 19:05:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l36J5LeB019933; Fri, 6 Apr 2007 15:05:21 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 6 Apr 2007 15:05:16 -0400 User-Agent: KMail/1.6.2 References: <20070407023855.ede13b76.nork@FreeBSD.org> <200704061351.30424.jkim@FreeBSD.org> <20070407032643.72fd55df.nork@FreeBSD.org> In-Reply-To: <20070407032643.72fd55df.nork@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704061505.18799.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/3029/Fri Apr 6 12:53:11 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 19:05:23 -0000 On Friday 06 April 2007 02:26 pm, Norikatsu Shigemura wrote: > On Fri, 6 Apr 2007 13:51:20 -0400 > > Jung-uk Kim wrote: > > > --- linprocfs.c 30 Mar 2007 17:56:44 -0000 1.108 > > > +++ linprocfs.c 6 Apr 2007 17:33:05 -0000 > > > @@ -1238,3 +1238,5 @@ > > > PSEUDOFS(linprocfs, 1); > > > MODULE_DEPEND(linprocfs, linux, 1, 1, 1); > > > MODULE_DEPEND(linprocfs, procfs, 1, 1, 1); > > > +MODULE_DEPEND(linprocfs, sysvmsg, 1, 1, 1); > > > +MODULE_DEPEND(linprocfs, sysvsem, 1, 1, 1); > > > > Looks good. I will commit it shortly. > > BTW, 'linux' module depends on these modules. Is loading > > 'dependency of dependency' broken? Should we have to explicitly > > tell it to load the dependencies? Am I missing something here? > > :-( > > 'dependency of dependency' you saied is not broken. It's > specification:-) of kernel symbol resolver. It can resolve > one level export symbols:-(. Okay, can we fix the 'specification', then? ;-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 19:32:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6733116A402 for ; Fri, 6 Apr 2007 19:32:23 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D9CAC13C448 for ; Fri, 6 Apr 2007 19:32:22 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36JVZ0q010056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2007 22:31:44 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36JVTjl036452; Fri, 6 Apr 2007 22:31:30 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36JVP3s036451; Fri, 6 Apr 2007 22:31:25 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 6 Apr 2007 22:31:25 +0300 From: Giorgos Keramidas To: Nikolas Britton Message-ID: <20070406193125.GA27879@kobe.laptop> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.685, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 19:32:23 -0000 On 2007-04-06 08:40, Nikolas Britton wrote: > I don't appreciate being called a lier. Maybe you should step up to > the plate if you don't believe my statistics. > > AMD Semptron 1,259 > AMD Athlon_64 2,796 > AMD Athlon_XP 2,885 > AMD Athlon 812 > AMD Duron 741 > AMD Opteron 625 > AMD Turion_64 175 > > Intel Pentium_4 8,768 > Intel Pentium_4M 291 > Intel Pentium_M 1,722 > Intel Pentium_3M 233 > Intel Pentium_3 6,362 > Intel Pentium_D 982 > Intel Pentium_2 1,872 > Intel Celeron_P2 888 > Intel Celeron_P3 529 > Intel Celeron_P4 4,224 > Intel Celeron_M 299 > Intel Xeon_P4 2,380 > Intel Core 1,246 > > Generic i786 1 > Generic i686_SSE 33 > Generic i686_MMX 114 > Generic i686 298 > Generic i586_MMX 520 > Generic i586 261 > Generic i486 30 > Unknown 99 > > Data source: http://www.bsdstats.org/cpus.php A lot of people are running "bsdstats" ports, and we should appreciate the work people have put into making http://www.bsdstats.org/ happen. I'm not sure I agree with the use you are putting these statistics into, whatever. The original goal of the statistics pages was to serve as a basis of version-related and hardware-related information, which can be used to convince hardware vendors to support *MORE* FreeBSD systems. Now you are arguing that because more modern CPUs and hardware are, well, "more modern", we should start dropping support for some of the systems listed there -- effectivelly reducing the number of systems supported by FreeBSD. This is a bit odd :-/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 19:43:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1664016A402 for ; Fri, 6 Apr 2007 19:43:33 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id C7A9F13C44B for ; Fri, 6 Apr 2007 19:43:32 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1122268ana for ; Fri, 06 Apr 2007 12:43:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JxdE2JK3vbjzfuvevK/og0wH+SU2msei/F4HLfnCE3e/qiPWSeKNCBkduloq08+UqdYu66Auvuo7PDeU2FbvtGil6m+4rk2/a/3gcHzWWbQTiQkXyd82GhbaPoo2oftfWsWT2ejpClrLjtJhxpbTZOEzALlOvTFOz4odIYH8VAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hw2Tbdyzkcl8KO4oTbQ4GFD/Ywgm10FHFGJ+iQ0ojnGIjrkmPBVYX2huHz2JIT+tRPglGyPHnqH30R9owJcAbZBRipCprEiVcdhw2+ExojdvMQnGf943etIN87LySDXtUgi5h9rm0kOK96zl5LRNof+K4KfrvDQOzbz2rJW8C5M= Received: by 10.100.57.14 with SMTP id f14mr2352404ana.1175888611846; Fri, 06 Apr 2007 12:43:31 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 12:43:31 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 14:43:31 -0500 From: "Nikolas Britton" To: "Ed Schouten" In-Reply-To: <20070406153500.GE6950@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 19:43:33 -0000 On 4/6/07, Ed Schouten wrote: > * Nikolas Britton wrote: > > On 4/6/07, Ed Schouten wrote: > > >* Nikolas Britton wrote: > > >> Well based on the stats I've posted maybe it's time to split FreeBSD > > >> i386 into two platforms, one for embedded/legacy systems and one for > > >> modern systems? The needs for each type of system are diametrically > > >> opposed, and the modern ones make up the majority of deployed systems. > > >> Perhaps FreeBSD i786 or IA32, with the minimum target being a > > >> Willamette based Pentium 4, aka SSE2? > > > > > >So what's the practical advantage of that? That would only break stuff. > > >Compiling a kernel without these options practically does the same > > >thing. > > > > > > > Break what? > > Renaming a platform is the root of all evil. Think about the big amount > of ports and source code that just check for $arch == "i386". That's the > reason the i386 port is still named i386, though it doesn't even support > i386 at all (got removed in 6.x). > > > The primary reason for doing this is optimization and simplification > > of support / development. > > Indeed. You'll simplify development, because half of the developers is > unable to run the bloody thing. Just run FreeBSD/amd64 if the legacy > bits upset you. > That's not true. If you look at the stats I posted over 58% of the systems have SSE2 support, compared to the 20%* with 64-bit capability. The legacy bits don't upset me, what upsets me is sacrificing performance so we can support a minority of legacy systems. IIRC? we could recode the Kernel for SSE2 math if the processor was guaranteed to have that SSE2. SSE2 adds 214 new instructions to the existing x86 instruction set. The problem with 64-bit FreeBSD is performance, on average its slower than FreeBSD i386 and FreeBSD i386 is already quite slow without custom optimizations. i.e. lots of recompiling... New users frequently get themselves into a big mess because it takes years of knowledge about FreeBSD internals to make it fast without breaking it. This turns new users off and can create support problems. *Edu. Guess, The stats were not setup to measure 64-bit support, I discarded the information that wasn't being measured. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:06:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0880416A404 for ; Fri, 6 Apr 2007 20:06:22 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id B725713C4B0 for ; Fri, 6 Apr 2007 20:06:21 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1126467ana for ; Fri, 06 Apr 2007 13:06:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IUkdGL/b1FfdxClBnZYQRaM23CgtLGiaVMy4VVr41OGT7/EdhF/YquCkZwHfXpPqfXAM3zNUjJLwM7gHGQVY15uDc8FykXIvHDgLhDuXMdBYCJjQX2gLtfsGf+Ve5P54LQR7Ho17MOb0SwkvSMd49wAvC5BfnKCyN9yQ1ArL4R4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rufZ8yshCaPFw1Td6TatMw53heFhus4knF36nUjogO+TIRMUe9jP9C6VN2xbOofSqNiRuNUegE30M5Cd7sJ88uJ5jhUoTrHeNegheC7fgMFWLtlQc4SFEzfoSWwQV51Wrn2x6KNjOnZZGhWu11wKZypgr/ekEI9qjVpe6clFTRw= Received: by 10.100.33.14 with SMTP id g14mr2368149ang.1175889980230; Fri, 06 Apr 2007 13:06:20 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 13:06:20 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:06:20 -0500 From: "Nikolas Britton" To: "Giorgos Keramidas" In-Reply-To: <20070406193125.GA27879@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:06:22 -0000 On 4/6/07, Giorgos Keramidas wrote: > On 2007-04-06 08:40, Nikolas Britton wrote: > > I don't appreciate being called a lier. Maybe you should step up to > > the plate if you don't believe my statistics. > > > > AMD Semptron 1,259 > > AMD Athlon_64 2,796 > > AMD Athlon_XP 2,885 > > AMD Athlon 812 > > AMD Duron 741 > > AMD Opteron 625 > > AMD Turion_64 175 > > > > Intel Pentium_4 8,768 > > Intel Pentium_4M 291 > > Intel Pentium_M 1,722 > > Intel Pentium_3M 233 > > Intel Pentium_3 6,362 > > Intel Pentium_D 982 > > Intel Pentium_2 1,872 > > Intel Celeron_P2 888 > > Intel Celeron_P3 529 > > Intel Celeron_P4 4,224 > > Intel Celeron_M 299 > > Intel Xeon_P4 2,380 > > Intel Core 1,246 > > > > Generic i786 1 > > Generic i686_SSE 33 > > Generic i686_MMX 114 > > Generic i686 298 > > Generic i586_MMX 520 > > Generic i586 261 > > Generic i486 30 > > Unknown 99 > > > > Data source: http://www.bsdstats.org/cpus.php > > A lot of people are running "bsdstats" ports, and we should appreciate > the work people have put into making http://www.bsdstats.org/ happen. > > I'm not sure I agree with the use you are putting these statistics into, > whatever. > > The original goal of the statistics pages was to serve as a basis of > version-related and hardware-related information, which can be used to > convince hardware vendors to support *MORE* FreeBSD systems. > > Now you are arguing that because more modern CPUs and hardware are, > well, "more modern", we should start dropping support for some of the > systems listed there -- effectivelly reducing the number of systems > supported by FreeBSD. > I only suggested dropping PC98. Why? If you look at the PC98 page* it hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero people using it... PC98 is a dead platform like Alpha and Alpha support is being dropped for FreeBSD 7, but if you look at bsdstats.org the Alpha platform has more users than sparc, powerpc and pc98 combined!! From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:17:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F16616A402 for ; Fri, 6 Apr 2007 20:17:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id C750913C480 for ; Fri, 6 Apr 2007 20:17:50 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 698C71CC22; Fri, 6 Apr 2007 22:17:49 +0200 (CEST) Date: Fri, 6 Apr 2007 22:17:49 +0200 From: Ed Schouten To: Nikolas Britton Message-ID: <20070406201749.GF6950@hoeg.nl> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f61P+fpdnY2FZS1u" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:17:51 -0000 --f61P+fpdnY2FZS1u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Nikolas Britton wrote: > The legacy bits don't upset me, what upsets me is sacrificing > performance so we can support a minority of legacy systems. IIRC? we > could recode the Kernel for SSE2 math if the processor was guaranteed > to have that SSE2. SSE2 adds 214 new instructions to the existing x86 > instruction set. But SSE2 isn't even used in kernel space, not even on AMD64. As far as I can see, the only exception I can see is pagezero. Just take a look at src/sys/conf/kern.mk. If it's not even possible to use SSE2 in kernelspace on amd64, why would it be possible to do so on i386? --=20 Ed Schouten WWW: http://g-rave.nl/ --f61P+fpdnY2FZS1u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFqrt52SDGA2eCwURAj7nAJ0Y5Pm+vSYTy9Y+Im2qwsDDv/np5gCfe60G U9GwG9kJXwW1kjIompdGYh4= =vP42 -----END PGP SIGNATURE----- --f61P+fpdnY2FZS1u-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:19:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0E4816A403 for ; Fri, 6 Apr 2007 20:19:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 805DC13C4B7 for ; Fri, 6 Apr 2007 20:19:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id l36KJLuY075578; Fri, 6 Apr 2007 13:19:21 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id l36KJLkh075577; Fri, 6 Apr 2007 13:19:21 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Apr 2007 13:19:21 -0700 From: Steve Kargl To: Nikolas Britton Message-ID: <20070406201921.GA75435@troutmask.apl.washington.edu> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Giorgos Keramidas , Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:19:37 -0000 On Fri, Apr 06, 2007 at 03:06:20PM -0500, Nikolas Britton wrote: > > I only suggested dropping PC98. Why? If you look at the PC98 page* it > hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero > people using it... PC98 is a dead platform like Alpha and Alpha > support is being dropped for FreeBSD 7, but if you look at > bsdstats.org the Alpha platform has more users than sparc, powerpc and > pc98 combined!! pc98 appears to be popular in Japan. See http://people.freebsd.org/~kato/pc98.html Alpha died because the chip maker stopped making chips. PS: Apologies to the others on this list who will receive yet another reply in a useless thread. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:23:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95EE316A403 for ; Fri, 6 Apr 2007 20:23:15 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 4F62B13C469 for ; Fri, 6 Apr 2007 20:23:15 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1129450ana for ; Fri, 06 Apr 2007 13:23:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rnh+guwdZI2SluaTvT7Jg4kQyjRjzi+RyMgAdZWHK52y13O5zYgu3tY2GW+ryCvDwiHEP1RWUTP5FTP22QB08DCr1r0ML/1E9UovlqpOA14a4d4LoULivCu/o/SCfjkWnZt7kGsK1YpPikBvF8dT9OTXQbH6oeYsbcNvOnSryp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HaGvpoGbg4u/Loj36Ghl5JGYAzLe0lj7TwGf4rbPmGqEbE05v4hnmT+rfXVBcbTURv2/cUV3PgB5SDVNlgvLLwGY0LRPTU1bP5KBdxL6ohGfRWjwIsjY0BG167ESY0828uHFDrm1uObCC8KxzHoPIceSusDa4Zl8kVIZUEgpjlY= Received: by 10.100.141.13 with SMTP id o13mr2318777and.1175890994179; Fri, 06 Apr 2007 13:23:14 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 13:23:14 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:23:14 -0500 From: "Nikolas Britton" To: "Julian Elischer" In-Reply-To: <461697C3.8000700@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:23:15 -0000 On 4/6/07, Julian Elischer wrote: > > I think some of the frustration people have shown with you is because > you don't seem to appreciate how much this issue is constantly thought > about and how the current state is not just an "accident of history". > > We have a LOT of old systems running around the world. > But the old systems don't need the latest and greatest copy of FreeBSD! This is why we provide errata / security fixes. The systems are a static non moving target ??? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:25:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2737E16A401 for ; Fri, 6 Apr 2007 20:25:30 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id D5FA413C459 for ; Fri, 6 Apr 2007 20:25:29 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1129868ana for ; Fri, 06 Apr 2007 13:25:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fE+S1MICXA8vCQcrc3qEwH0wUOhRSkVQZrLSvIHnVGVqUoRQqq7kkg93OmBJ28ZiS6cYvRbWN1PKZhl+e7XjajfbUQhMMvcsX/IwyfbKWpJPJl3Qt3QDA7gJhXGiV+C5vppBBqf57YONqpvf3MyAbbWhJIhPQQQ1jUfAkpztlQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eEs0qCcS+8q0euu4lSNur+9/cfU9mCDH0nJ6i1uuLXM5mCdKuXLrj+DwXn7ZLtcwbp4tPCoXeOUr4ZPUbugAvmgPpXwS6EtjAAEFdJyFigLO5cr+2ZTlMjm2YYRC+kj6X4fTtg5w6JY0ZcQI8AvQtQ0cmiiUNE9rRbMlBMBSvdQ= Received: by 10.100.121.12 with SMTP id t12mr2335901anc.1175891129284; Fri, 06 Apr 2007 13:25:29 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 13:25:24 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:25:24 -0500 From: "Nikolas Britton" To: "Steve Kargl" In-Reply-To: <20070406201921.GA75435@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> <20070406201921.GA75435@troutmask.apl.washington.edu> Cc: Giorgos Keramidas , Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:25:30 -0000 On 4/6/07, Steve Kargl wrote: > On Fri, Apr 06, 2007 at 03:06:20PM -0500, Nikolas Britton wrote: > > > > I only suggested dropping PC98. Why? If you look at the PC98 page* it > > hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero > > people using it... PC98 is a dead platform like Alpha and Alpha > > support is being dropped for FreeBSD 7, but if you look at > > bsdstats.org the Alpha platform has more users than sparc, powerpc and > > pc98 combined!! > > pc98 appears to be popular in Japan. See > http://people.freebsd.org/~kato/pc98.html > > Alpha died because the chip maker stopped > making chips. > NEC stopped making PC98 system in 1997!!! From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:36:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C08B616A402 for ; Fri, 6 Apr 2007 20:36:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 9F48C13C44C for ; Fri, 6 Apr 2007 20:36:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id l36KahId075752; Fri, 6 Apr 2007 13:36:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id l36KagdD075751; Fri, 6 Apr 2007 13:36:42 -0700 (PDT) (envelope-from sgk) Date: Fri, 6 Apr 2007 13:36:42 -0700 From: Steve Kargl To: Nikolas Britton Message-ID: <20070406203642.GA75672@troutmask.apl.washington.edu> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> <20070406201921.GA75435@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Giorgos Keramidas , Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:36:57 -0000 On Fri, Apr 06, 2007 at 03:25:24PM -0500, Nikolas Britton wrote: > On 4/6/07, Steve Kargl wrote: > >On Fri, Apr 06, 2007 at 03:06:20PM -0500, Nikolas Britton wrote: > >> > >> I only suggested dropping PC98. Why? If you look at the PC98 page* it > >> hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero > >> people using it... PC98 is a dead platform like Alpha and Alpha > >> support is being dropped for FreeBSD 7, but if you look at > >> bsdstats.org the Alpha platform has more users than sparc, powerpc and > >> pc98 combined!! > > > >pc98 appears to be popular in Japan. See > >http://people.freebsd.org/~kato/pc98.html > > > >Alpha died because the chip maker stopped > >making chips. > > > > NEC stopped making PC98 system in 1997!!! That's odd. See NEC's press release dated 23 OCT 97 concerning a new series of PC98-NX http://www.nec.co.jp/press/en/9710/2301.html -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:48:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44E7216A408 for ; Fri, 6 Apr 2007 20:48:00 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id F3B3F13C45E for ; Fri, 6 Apr 2007 20:47:59 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1133526ana for ; Fri, 06 Apr 2007 13:47:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RTSpQ83QOX/skNiE3aTFIPdXlu/1xVfcm8g/znSirDbmv43Tj+k3qHshAwG9sJV9z7IZ1ON2KK0kCYSL9Lq9crngVmsJpgR8pF5ldXCeB/JUOBkScDzLTn8Jx74YXrRMH1CMdUMAs0zIk5Onpnr3XcIS7pIoZEdKj8a2kZnTw5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LwHOs03hWV6Bk6iqsNTfO+eIU8x27Ia8S04DUcpbrLRJfPxeY4WRFwRi5XzTnhFQKb8+DO0PA+SoEbhCFN900SvZ0sBlzI8EUgE52KR4jXx/qVaW1BROlBxilg9cVfz9UOFcfvoWG0Zbgh2/UbDiKABZESW0ggW0AxQ7hPqYs98= Received: by 10.100.138.2 with SMTP id l2mr2370953and.1175892479304; Fri, 06 Apr 2007 13:47:59 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 13:47:59 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:47:59 -0500 From: "Nikolas Britton" To: "Ed Schouten" In-Reply-To: <20070406201749.GF6950@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <20070406201749.GF6950@hoeg.nl> Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:48:00 -0000 On 4/6/07, Ed Schouten wrote: > * Nikolas Britton wrote: > > The legacy bits don't upset me, what upsets me is sacrificing > > performance so we can support a minority of legacy systems. IIRC? we > > could recode the Kernel for SSE2 math if the processor was guaranteed > > to have that SSE2. SSE2 adds 214 new instructions to the existing x86 > > instruction set. > > But SSE2 isn't even used in kernel space, not even on AMD64. As far as I > can see, the only exception I can see is pagezero. Just take a look at > src/sys/conf/kern.mk. If it's not even possible to use SSE2 in > kernelspace on amd64, why would it be possible to do so on i386? > Doesn't Apple use SSE2/3 in the kernel? IIRC Mac OS X (Darwin) running on a white box PC won't even boot if it's missing. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:54:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3809016A401 for ; Fri, 6 Apr 2007 20:54:51 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id E583413C46C for ; Fri, 6 Apr 2007 20:54:50 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1134692ana for ; Fri, 06 Apr 2007 13:54:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HZGGLVJlgwHuRGI5NbmwL2wct9jKs8yCUrkvm144DkM4OCNEE+xepBcLMSJwUS5nRT53KHJZ3X5cS+5477JavWi2vRzaTIwpXm8nRDcEUGp7lrZML0pGxGwoGR9IxPfscWuK3LD8Y/+4DYDQDtOl1+t4Vqio7uCBSewGlFFNhco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YLY+kFXjUY/B9NjL23apr18NmSTlqTY1iFCiebMsyKiqquVGs0T/yg5XOVODn/gX7x3VFTTozQUqAz2lTDLdRxUWEFAN7PeDSTu6UMqJXE6rnKvxPmnO52swIn3elWJRECMEef0WyjJsWi+wBd/D94YMTQXEb2Tp3cwF8D9a42U= Received: by 10.100.57.14 with SMTP id f14mr2345836ana.1175892890159; Fri, 06 Apr 2007 13:54:50 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 13:54:50 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 15:54:50 -0500 From: "Nikolas Britton" To: "Steve Kargl" In-Reply-To: <20070406203642.GA75672@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> <20070406201921.GA75435@troutmask.apl.washington.edu> <20070406203642.GA75672@troutmask.apl.washington.edu> Cc: Giorgos Keramidas , Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:54:51 -0000 On 4/6/07, Steve Kargl wrote: > On Fri, Apr 06, 2007 at 03:25:24PM -0500, Nikolas Britton wrote: > > On 4/6/07, Steve Kargl wrote: > > >On Fri, Apr 06, 2007 at 03:06:20PM -0500, Nikolas Britton wrote: > > >> > > >> I only suggested dropping PC98. Why? If you look at the PC98 page* it > > >> hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero > > >> people using it... PC98 is a dead platform like Alpha and Alpha > > >> support is being dropped for FreeBSD 7, but if you look at > > >> bsdstats.org the Alpha platform has more users than sparc, powerpc and > > >> pc98 combined!! > > > > > >pc98 appears to be popular in Japan. See > > >http://people.freebsd.org/~kato/pc98.html > > > > > >Alpha died because the chip maker stopped > > >making chips. > > > > > > > NEC stopped making PC98 system in 1997!!! > > That's odd. See NEC's press release dated 23 OCT 97 > concerning a new series of PC98-NX > > http://www.nec.co.jp/press/en/9710/2301.html > "The PC-9801's last successor is the Celeron-based PC-9821Ra43 (with a clockspeed 433MHz), which appeared in 2000" -Wikipedia Ok I was off by 3 years, but it's still been dead longer than Alpha. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:56:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD52A16A405 for ; Fri, 6 Apr 2007 20:56:27 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 39C6F13C45D for ; Fri, 6 Apr 2007 20:56:26 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36KtW2l014646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2007 23:55:40 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36KtQV0036324; Fri, 6 Apr 2007 23:55:26 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36KtPbS036323; Fri, 6 Apr 2007 23:55:25 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 6 Apr 2007 23:55:25 +0300 From: Giorgos Keramidas To: Nikolas Britton Message-ID: <20070406205524.GA34638@kobe.laptop> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.686, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:56:27 -0000 On 2007-04-06 14:43, Nikolas Britton wrote: >On 4/6/07, Ed Schouten wrote: >> Renaming a platform is the root of all evil. Think about the big >> amount of ports and source code that just check for $arch == "i386". >> That's the reason the i386 port is still named i386, though it >> doesn't even support i386 at all (got removed in 6.x). >> >>> The primary reason for doing this is optimization and simplification >>> of support / development. >> >> Indeed. You'll simplify development, because half of the developers >> is unable to run the bloody thing. Just run FreeBSD/amd64 if the >> legacy bits upset you. > > That's not true. If you look at the stats I posted over 58% of the > systems have SSE2 support, compared to the 20%* with 64-bit > capability. > > The legacy bits don't upset me, what upsets me is sacrificing > performance so we can support a minority of legacy systems. IIRC? we > could recode the Kernel for SSE2 math if the processor was guaranteed > to have that SSE2 instruction set. I am sure your intentions are good, and you really do believe that we have a huge performance increase to gain by using "SSE2 recoding", but are you *really* sure we have so much to gain from SSE2 instructions? Even if there _is_ a certain amount of speed which can be gained by building an optimized kernel, there are very good reasons why the default kernels shipped with the release CD-ROM images of FreeBSD are *not* optimized. > The problem with 64-bit FreeBSD is performance, on average its slower > than FreeBSD i386 and FreeBSD i386 is already quite slow without > custom optimizations. i.e. lots of recompiling... New users frequently > get themselves into a big mess because it takes years of knowledge > about FreeBSD internals to make it fast without breaking it. Rebuilding a complete, working, fully functional FreeBSD system is much much, really *very* much, easier than, say, building a custom Gentoo Linux installation and verifying that it still works as expected. The FreeBSD system itself provides all the tools and all the necessary bits to rebuild everything from source, so why is recompiling something such a big problem? There are also other systems out there, which ship with unoptimized binaries, because they value observability, debuggability and the availability of binary tracing, debugging, auditing and fixing. One of them is Solaris, which even runs with 32-bit binaries for utilities like /usr/bin/ls on 64-bit systems. Optimization and tuning is not the be-all, end-all, the ultimate target, and the life purpose of every single one of us. So, why should it be forced on all of us? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:09:58 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4BBC16A402 for ; Fri, 6 Apr 2007 21:09:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9E24A13C469 for ; Fri, 6 Apr 2007 21:09:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id CCB51212643; Fri, 6 Apr 2007 17:10:05 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 06 Apr 2007 17:09:58 -0400 X-Sasl-enc: LxFXyko5XyZaA+I5fPWz0RDjdfy2nBRq41EJW2rtZR7X 1175893798 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2E0801CA37; Fri, 6 Apr 2007 17:09:58 -0400 (EDT) Message-ID: <4616B724.80004@FreeBSD.org> Date: Fri, 06 Apr 2007 22:09:56 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:09:58 -0000 This is most excellent work which is going to help everyone in a very big way. Many thanks for working on this. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:15:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 802E716A402 for ; Fri, 6 Apr 2007 21:15:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6EE13C487 for ; Fri, 6 Apr 2007 21:15:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l36LCEdh005942; Fri, 6 Apr 2007 15:12:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Apr 2007 15:12:22 -0600 (MDT) Message-Id: <20070406.151222.1474621552.imp@bsdimp.com> To: nikolas.britton@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20070405.140109.39240822.imp@bsdimp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 06 Apr 2007 15:12:15 -0600 (MDT) Cc: peterjeremy@optushome.com.au, freebsd-current@freebsd.org Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:15:10 -0000 In message: "Nikolas Britton" writes: : On 4/5/07, Warner Losh wrote: : > From: "Nikolas Britton" : > Subject: Re: Do we need this junk? : > Date: Thu, 5 Apr 2007 10:39:41 -0500 : > : > > On 4/5/07, Peter Jeremy wrote: : > > > [-stable removed since it's not relevant there] : > > > : > > > On 2007-Apr-05 04:58:17 -0500, Nikolas Britton wrote: : > > > >Can anything in the list below be removed from CURRENT? : > > > > : > > > >legacyfree1# cd dev/ : > > > >legacyfree1# grep -irsn isa ./ | grep -i include : > > > ... : > > > >legacyfree1# grep -irsn mca ./ | grep -i include : > > > ... : > > > : > > > Why do you believe anything in the list might need to be removed? : > > > : > > : > > I'd like to also add that 6-STABLE should be the last branch to support: : > > 1. ISA / EISA : > : > Not going to happen. Maybe EISA, but certainly not ISA, as machines : > made today still need it. : > : > > 2. PC98 Platform. : > : > What do you care? I mean really, what do you care here. There are : > Pentium II class machines that are perfectly good in this class of : > machines. I have one and it runs just fine. : > : > > 3. i486 : > : > So you want to kill all the soekris boxes? Sorry, not going to : > happen. : > : > > 4. i586 : > : > These machines still work, and are still popular in the embedded space : > due to their lower power consumption. : > : > Warner : > : : Well based on the stats I've posted maybe it's time to split FreeBSD : i386 into two platforms, one for embedded/legacy systems and one for : modern systems? The needs for each type of system are diametrically : opposed, and the modern ones make up the majority of deployed systems. : Perhaps FreeBSD i786 or IA32, with the minimum target being a : Willamette based Pentium 4, aka SSE2? There's no need. Thank you for your input. It has been noted and given all the weight it deserves. Have a nice day. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:15:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D969716A403 for ; Fri, 6 Apr 2007 21:15:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 940CE13C45B for ; Fri, 6 Apr 2007 21:15:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A598A2091; Fri, 6 Apr 2007 23:15:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 80AA02090; Fri, 6 Apr 2007 23:15:21 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 61EB2A10A5; Fri, 6 Apr 2007 23:15:21 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Nikolas Britton" References: <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> Date: Fri, 06 Apr 2007 23:15:21 +0200 In-Reply-To: (Nikolas Britton's message of "Fri, 6 Apr 2007 15:23:14 -0500") Message-ID: <86ps6h8as6.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Julian Elischer , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:15:28 -0000 "Nikolas Britton" writes: > Julian Elischer writes: > > We have a LOT of old systems running around the world. > But the old systems don't need the latest and greatest copy of > FreeBSD! This is why we provide errata / security fixes. The systems > are a static non moving target ??? Excuse me? Who's "we"? Julian, Warner, Scott, Bernd, Giorgios, Wilko, myself and many others who have contradicted you in this discussion are veteran FreeBSD developers with something like a hundred years of industry experience between us. You, on the other hand are just a pathetic little fuck who has repeatedly demonstrated his complete lack of understanding of anything remotely approaching real computers, real software and real life. You do not get to tell us how to run our project. You do not get to say "we". DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:16:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5362716A402 for ; Fri, 6 Apr 2007 21:16:43 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id C567213C43E for ; Fri, 6 Apr 2007 21:16:40 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36LEpmm016442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Apr 2007 00:15:38 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36LEPiU001513; Sat, 7 Apr 2007 00:14:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36L57FX001097; Sat, 7 Apr 2007 00:05:07 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 7 Apr 2007 00:05:07 +0300 From: Giorgos Keramidas To: Nikolas Britton Message-ID: <20070406210506.GA1078@kobe.laptop> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.686, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:16:43 -0000 On 2007-04-06 15:06, Nikolas Britton wrote: >On 4/6/07, Giorgos Keramidas wrote: >>> Data source: http://www.bsdstats.org/cpus.php >> >> A lot of people are running "bsdstats" ports, and we should appreciate >> the work people have put into making http://www.bsdstats.org/ happen. >> >> I'm not sure I agree with the use you are putting these statistics into, >> whatever. >> >> The original goal of the statistics pages was to serve as a basis of >> version-related and hardware-related information, which can be used to >> convince hardware vendors to support *MORE* FreeBSD systems. >> >> Now you are arguing that because more modern CPUs and hardware are, >> well, "more modern", we should start dropping support for some of the >> systems listed there -- effectivelly reducing the number of systems >> supported by FreeBSD. > > I only suggested dropping PC98. Why? If you look at the PC98 page* it > hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero > people using it... PC98 is a dead platform like Alpha and Alpha > support is being dropped for FreeBSD 7, but if you look at > bsdstats.org the Alpha platform has more users than sparc, powerpc and > pc98 combined!! So, what does this tell us? Are the sparc users less in number because we have excellent sparc64 support, but there's no interest? Because we don't have good sparc64 support? Or because the existing sparc64 users don't use the bsdstats ports? I'm not sure what you're trying to prove by throwing numbers from bsdstats around. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:17:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E098A16A402; Fri, 6 Apr 2007 21:17:03 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD9413C4C5; Fri, 6 Apr 2007 21:17:03 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36LEu53016446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Apr 2007 00:15:38 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36LEPiW001513; Sat, 7 Apr 2007 00:14:49 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36LCUqC001180; Sat, 7 Apr 2007 00:12:30 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 7 Apr 2007 00:12:30 +0300 From: Giorgos Keramidas To: John Baldwin , Ariff Abdullah Message-ID: <20070406211229.GB1078@kobe.laptop> References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> <200703271227.14308.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703271227.14308.jhb@freebsd.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.079, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Alexander Leidinger , freebsd-current@freebsd.org, current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:17:04 -0000 On 2007-03-27 12:27, John Baldwin wrote: > If that is the case it's because code was using > rman_get_bus(handle|tag) on a resource that wasn't activated yet which > wouldn't have worked before the nexus changes either. Well, the bus > tag might have been right, but the handle for SYS_RES_MEMORY would > have been wrong. This is the change which stops snd_hda from working here: % Date: Wed, 21 Mar 2007 15:39:12 +0000 (UTC) % Message-Id: <200703211539.l2LFdCQW036704@repoman.freebsd.org> % From: John Baldwin % Subject: cvs commit: src/sys/dev/acpica acpi.c % To: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org % Cc: % % jhb 2007-03-21 15:39:12 UTC % % FreeBSD src repository % % Modified files: % sys/dev/acpica acpi.c % Log: % Change acpi's handling of suballocating system resources to be a little % simpler. It now can just use rman_is_region_manager() during % acpi_release_resource() to see if the the resource is suballocated from % a system resource. Also, the driver no longer needs MD knowledge about % how to setup bus space tags and handles when doing a suballocation, but % can simply rely on bus_activate_resource() in the parent setting all that % up. % % Revision Changes Path % 1.233 +39 -55 src/sys/dev/acpica/acpi.c If I update my kernel sources to Wed Mar 21 14:39:39 2007 +0000 (including the sys/modules/padlock/Makefile commit of Sam Leffler, to fix the kernel build from Wed Mar 21 17:37:13 2007 +0000), I can see that the snd_hda driver probes my sound card correctly. Updating after the commit shown above, breaks snd_hda. Updating to CVS HEAD and reverting the commit above, seems to work almost fine, but then I get the following: ACPI Exception (utmutex-0376): AE_TIME, Thread 8 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] Any idea how to proceed in fixing acpi or snd_hda itself? - Giorgos From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:17:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E098A16A402; Fri, 6 Apr 2007 21:17:03 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD9413C4C5; Fri, 6 Apr 2007 21:17:03 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36LEu53016446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Apr 2007 00:15:38 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36LEPiW001513; Sat, 7 Apr 2007 00:14:49 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36LCUqC001180; Sat, 7 Apr 2007 00:12:30 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 7 Apr 2007 00:12:30 +0300 From: Giorgos Keramidas To: John Baldwin , Ariff Abdullah Message-ID: <20070406211229.GB1078@kobe.laptop> References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> <200703271227.14308.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703271227.14308.jhb@freebsd.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.079, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Alexander Leidinger , freebsd-current@freebsd.org, current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:17:04 -0000 On 2007-03-27 12:27, John Baldwin wrote: > If that is the case it's because code was using > rman_get_bus(handle|tag) on a resource that wasn't activated yet which > wouldn't have worked before the nexus changes either. Well, the bus > tag might have been right, but the handle for SYS_RES_MEMORY would > have been wrong. This is the change which stops snd_hda from working here: % Date: Wed, 21 Mar 2007 15:39:12 +0000 (UTC) % Message-Id: <200703211539.l2LFdCQW036704@repoman.freebsd.org> % From: John Baldwin % Subject: cvs commit: src/sys/dev/acpica acpi.c % To: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org % Cc: % % jhb 2007-03-21 15:39:12 UTC % % FreeBSD src repository % % Modified files: % sys/dev/acpica acpi.c % Log: % Change acpi's handling of suballocating system resources to be a little % simpler. It now can just use rman_is_region_manager() during % acpi_release_resource() to see if the the resource is suballocated from % a system resource. Also, the driver no longer needs MD knowledge about % how to setup bus space tags and handles when doing a suballocation, but % can simply rely on bus_activate_resource() in the parent setting all that % up. % % Revision Changes Path % 1.233 +39 -55 src/sys/dev/acpica/acpi.c If I update my kernel sources to Wed Mar 21 14:39:39 2007 +0000 (including the sys/modules/padlock/Makefile commit of Sam Leffler, to fix the kernel build from Wed Mar 21 17:37:13 2007 +0000), I can see that the snd_hda driver probes my sound card correctly. Updating after the commit shown above, breaks snd_hda. Updating to CVS HEAD and reverting the commit above, seems to work almost fine, but then I get the following: ACPI Exception (utmutex-0376): AE_TIME, Thread 8 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not release AML Interpreter mutex [20070320] Any idea how to proceed in fixing acpi or snd_hda itself? - Giorgos From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:20:37 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8076216A401; Fri, 6 Apr 2007 21:20:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF6913C483; Fri, 6 Apr 2007 21:20:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2F1142091; Fri, 6 Apr 2007 23:20:33 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 16D852090; Fri, 6 Apr 2007 23:20:33 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 03444A10A5; Fri, 6 Apr 2007 23:20:33 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Jung-uk Kim References: <20070407023855.ede13b76.nork@FreeBSD.org> <20070406174305.GA90217@freebsd.org> <200704061407.35340.jkim@FreeBSD.org> Date: Fri, 06 Apr 2007 23:20:32 +0200 In-Reply-To: <200704061407.35340.jkim@FreeBSD.org> (Jung-uk Kim's message of "Fri, 6 Apr 2007 14:07:27 -0400") Message-ID: <86lkh58ajj.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Roman Divacky , freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:20:37 -0000 Jung-uk Kim writes: > On Friday 06 April 2007 01:43 pm, Roman Divacky wrote: > > I dont like this, I would prefer some dynamic determining > > whether sysv symbols are present and if not just fill > > in "safe" values. > You know I have used sysctlbyname before but it was shot down by > des. :-( I didn't shoot anything down. If you read my email again, you'll see that I pointed out that it was slow, but that we didn't really have a choice precisely because sysv{msg,sem} were not guaranteed to be present. Dropping sysctlbyname() was *your* choice. I agreed with the revised patch because you pointed out that linprocfs depends on linux, which depends on sysv{msg,sem}, so we *could* rely on their presence. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:21:36 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B983416A403 for ; Fri, 6 Apr 2007 21:21:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6A85C13C487 for ; Fri, 6 Apr 2007 21:21:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l36LIrBu005984; Fri, 6 Apr 2007 15:18:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Apr 2007 15:19:01 -0600 (MDT) Message-Id: <20070406.151901.-1844003065.imp@bsdimp.com> To: nikolas.britton@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 06 Apr 2007 15:18:55 -0600 (MDT) Cc: freebsd-current@freebsd.org, ed@fxq.nl Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:21:36 -0000 In message: "Nikolas Britton" writes: : Where is this coming from? I'm trying to debate some of the issues : with FreeBSD and the only thing you've added to this thread is fuck : off? Why? Because you have used language that is somewhat absolute and have not done a market research on who actually uses FreeBSD. You have also shown a fundamental lack of understanding of how modern machines are put together as well, since you think all things ISA are obsolete (they are not). As others have noted, there's a very large and vibrant embedded FreeBSD community. This community makes real and meaningful contributions to FreeBSD. Over the years, I've made thousands of commits to the tree, funded in large part by the embedded companies that I have worked for, including CardBus, PC Card, SD/MMC, infrasturcutre changes, etc. Frankly, we'd rather tell a new, upstart to get bent than to tell actual users and supports of FreeBSD to get bent by removing the offending items from the tree. It really is a no-brainer. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:24:49 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9107216A401 for ; Fri, 6 Apr 2007 21:24:49 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4A88313C4AE for ; Fri, 6 Apr 2007 21:24:49 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1139424ana for ; Fri, 06 Apr 2007 14:24:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OLuZ/hEg5AK+762ZXSYdMUb+YRPRgCSy01UUC7ZoFA9fth/HWNzzNG5J7od6mqMJxjXq6g4O5ufg9k1Ppgsbsua3+TB3gNaluKDSZQZ6XdclM4QfcEhr6kp2qUGmNzT3ofWYiy8UjnMIupSJqPOMNejO8Nq7aN3hXKM91WOAfDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mvsKeIQAhWuXpY3HDuML4dOU/FzYY6Xb5bWcwYwSABvjeD+O8hDli9BK2d2nguUE3wP8q6sH8fBePzSjl6VrBHo21rAYIh0G4X3ZlfSdcdlhQIqIOdBO2BLZAtM59nXJ7JGO3/+dD9EgiC0C8sRPeqgMjCcN//5z2hVSSJbbOLY= Received: by 10.100.142.12 with SMTP id p12mr2369102and.1175894688636; Fri, 06 Apr 2007 14:24:48 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 14:24:48 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 16:24:48 -0500 From: "Nikolas Britton" To: "Erik Osterholm" , "Nikolas Britton" , "FreeBSD Current" In-Reply-To: <20070406202847.GA91533@idoru.cepheid.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <20070406202847.GA91533@idoru.cepheid.org> Cc: Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:24:49 -0000 On 4/6/07, Erik Osterholm wrote: > On Fri, Apr 06, 2007 at 03:23:14PM -0500, Nikolas Britton wrote: > > On 4/6/07, Julian Elischer wrote: > > > > > >I think some of the frustration people have shown with you is because > > >you don't seem to appreciate how much this issue is constantly thought > > >about and how the current state is not just an "accident of history". > > > > > >We have a LOT of old systems running around the world. > > > > > > > But the old systems don't need the latest and greatest copy of > > FreeBSD! This is why we provide errata / security fixes. The systems > > are a static non moving target ??? > > Ah, but old systems are the most likely to see a significant benefit > from performance improvements. > If you want more performance I have a bunch of i386, i486, pentium, pentium pro, and pentium II systems you can have, for free (you pay shipping). For some weird reason people just keep giving them me and my basement is filled up with them. I can't fined any useful use for all of them so most stay in the basement collecting dust and rust. The ones I can use are setup for a particular task and I won't mess with it unless it breaks. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:27:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 790DB16A40A for ; Fri, 6 Apr 2007 21:27:56 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 33CE213C484 for ; Fri, 6 Apr 2007 21:27:55 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1139881ana for ; Fri, 06 Apr 2007 14:27:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J5rjkfY2+1uDvxa0bF0ysj99pX5OSi5bnwkheOQsO22Ii+YJP4qHlOLhFT0LDZwZWTe7I/noIXICq+7/7EnYFh4nG0nfvXGyGhXFlQ9CDQdBw8HKcrO5YnGX57DO2G0wC5siyahG6rK3lvN/4KcIri99Bo2CAnL+8utT38XYO0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bSyaTcXqORzRxc3Z3bYITq+TMwRKOMszm4wWsUtE5C7B4lOL1AwV7dSr7txOPYfwlWLHEunm5CBMv7P31fIkEfl8c5AAECVoD+1wL02koSpW24sNquTedyP9NeJsF0xjZS6wbI7OvmRSHTocliOJMvp+e5Soi+IZKoAR4nDIiKo= Received: by 10.100.111.16 with SMTP id j16mr2355978anc.1175894875493; Fri, 06 Apr 2007 14:27:55 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 14:27:55 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 16:27:55 -0500 From: "Nikolas Britton" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86ps6h8as6.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <86ps6h8as6.fsf@dwp.des.no> Cc: FreeBSD Current , Julian Elischer , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:27:56 -0000 On 4/6/07, Dag-Erling Sm=F8rgrav wrote: > "Nikolas Britton" writes: > > Julian Elischer writes: > > > We have a LOT of old systems running around the world. > > But the old systems don't need the latest and greatest copy of > > FreeBSD! This is why we provide errata / security fixes. The systems > > are a static non moving target ??? > > Excuse me? Who's "we"? > > Julian, Warner, Scott, Bernd, Giorgios, Wilko, myself and many others > who have contradicted you in this discussion are veteran FreeBSD > developers with something like a hundred years of industry experience > between us. > > You, on the other hand are just a pathetic little fuck who has > repeatedly demonstrated his complete lack of understanding of anything > remotely approaching real computers, real software and real life. > > You do not get to tell us how to run our project. > > You do not get to say "we". > Read it again dick head, Julian Elischer wrote "we". From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:30:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AC0816A403 for ; Fri, 6 Apr 2007 21:30:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFFE13C44C for ; Fri, 6 Apr 2007 21:30:15 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 44C2E2124A9; Fri, 6 Apr 2007 17:30:23 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 06 Apr 2007 17:30:16 -0400 X-Sasl-enc: D5XCZhyUO9BRdnpzWvinRMa0q2wH0oDLNy3oJajxGJGA 1175895015 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BAB7A18D36; Fri, 6 Apr 2007 17:30:15 -0400 (EDT) Message-ID: <4616BBE6.8080202@FreeBSD.org> Date: Fri, 06 Apr 2007 22:30:14 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Nikolas Britton References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <73EB6741-1441-4475-A9D8-4D0049BB8D9A@mindspring.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:30:16 -0000 Nikolas Britton wrote: > > What data do you have to back that claim up? Unless you have real > quantitative data to support your claims the bsdstats.org statistics > stand as an accurate representative sample of the population... i.e. > it's *1000% better the your sample size of one. Well, they don't, because the statistics which you cite are not representative -- they certainly do not represent the hardware I use to work on FreeBSD. I do not own any SSE2 systems. I didn't even know a web site called bsdstats.org existed until you informed us of its existence on this mailing list. I am concerned that a somewhat shallow argument is being put forward with incomplete statistics from a single source inappropriately being used to support it; your argument appears to lack real consideration of the software engineering effort required to put it into production. Nikolas, to be fair, if you are willing to do the work, or financially or otherwise support, the work necessary to support the changes you are suggesting should be made (and I responded to you in private explaining that I understand some of the motivation behind your suggested changes), then it would seem to me to be reasonable and fair for the Project to consider them, and I am sure they will be of interest at the appropriate time. Until such time as these systems are more common, however, then I'm afraid your suggestion has to be abandoned, for the time being, because your position appears unjustified in terms of the statistics you provide, and your arguments. The proposition you make is a very long term proposition indeed. As such, I speculate most of the people working on FreeBSD will continue to focus on more important things in the immediate future. Respectfully yours, BMS From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:43:39 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60B0516A405; Fri, 6 Apr 2007 21:43:39 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id AD55013C483; Fri, 6 Apr 2007 21:43:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C8795487FB; Fri, 6 Apr 2007 23:43:36 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E9B3F45681; Fri, 6 Apr 2007 23:43:30 +0200 (CEST) Date: Fri, 6 Apr 2007 23:43:25 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20070406214325.GB61039@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org Subject: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:43:39 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ok, ZFS is now in the tree, what's now? Below you'll find some instructions how to quickly make it up and running. First of all you need some disks. Let's assume you have three spare SCSI disks: da0, da1, da2. Add a line to your /etc/rc.conf to start ZFS automatically on boot: # echo 'zfs_enable=3D"YES"' >> /etc/rc.conf Load ZFS kernel module, for the first time by hand: # kldload zfs.ko Now, setup one pool using RAIDZ: # zpool create tank raidz da0 da1 da2 It should automatically mount /tank/ for you. Ok, now put /usr/ on ZFS and propose some file systems layout. I know you probably have some files already, so we will work on /tank/usr directory and once we ready, we will just change the mountpoint to /usr. # zfs create tank/usr Create ports/ file system and enable gzip compression on it, because most likely we will have only text files there. On the other hand, we don't want to compress ports/distfiles/, because we keep compressed stuff already in-there: # zfs create tank/usr/ports # zfs set compression=3Dgzip tank/usr/ports # zfs create tank/usr/ports/distfiles # zfs set compression=3Doff tank/usr/ports/distfiles (You do see how your life is changing, don't you?:)) Let's create home file system, my own home/pjd/ file system. I know we use RAIDZ, but I want to have directory where I put extremly important stuff, you I'll define that each block has to be stored in tree copies: # zfs create tank/usr/home # zfs create tank/usr/home/pjd # zfs create tank/usr/home/pjd/important # zfs set copies=3D3 tank/usr/home/pjd/important I'd like to have directory with music, etc. that I NFS share. I don't really care about this stuff and my computer is not very fast, so I'll just turn off checksumming (this is only for example purposes! please, benchmark before doing it, because it's most likely not worth it!): # zfs create tank/music # zfs set checksum=3Doff tank/music # zfs set sharenfs=3Don tank/music Oh, I almost forget. Who cares about access time updates? # zfs set atime=3Doff tank Yes, we set it only on tank and it will be automatically inherited by others. Will be also good to be informed if everything is fine with our pool: # echo 'daily_status_zfs_enable=3D"YES"' >> /etc/periodic.conf For some reason you still need UFS file system, for example you use ACLs or extended attributes which are not yet supported by our ZFS. If so, why not just use ZFS to provide storage? This way we gain cheap UFS snapshots, UFS clones, etc. by simply using ZVOLs. # zfs create -V 10g tank/ufs # newfs /dev/zvol/tank/ufs # mount /dev/zvol/tank/ufs /ufs # zfs snapshot tank/ufs@20070406 # mount -r /dev/zvol/tank/ufs@20070406 /ufs20070406 # zfs clone tank/ufs@20070406 tank/ufsok # fsck_ffs -p /dev/zvol/tank/ufsok # mount /dev/zvol/tank/ufsok /ufsok Want to encrypt your swap and still use ZFS? Nothing more trivial: # zfs create -V 4g tank/swap # geli onetime -s 4096 /dev/zvol/tank/swap # swapon /dev/zvol/tank/swap.eli Trying to do something risky with your home? Snapshot it first! # zfs snapshot tank/home/pjd@justincase Turns out it was more stupid than risky? Rollback your snapshot! # zfs rollback tank/home/pjd@justincase # zfs destroy tank/home/pjd@justincase Ok, everything works, we may set tank/usr as our real /usr: # zfs set mountpoint=3D/usr tank/usr Don't forget to read zfs(8) and zpool(8) manual pages and SUN's ZFS administration guide: http://www.opensolaris.org/os/community/zfs/docs/zfsadmin.pdf --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFr79ForvXbEpPzQRAhBXAJ0TF5dJ7v+K2MesPZQim5P+HM9apwCg4Uqt 8pqudyaAa/M1rwcvs6829xI= =QFnZ -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:46:44 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CE3516A410; Fri, 6 Apr 2007 21:46:44 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc3-cdif2-0-0-cust64.cdif.cable.ntl.com [81.106.128.65]) by mx1.freebsd.org (Postfix) with ESMTP id BC1BC13C4AE; Fri, 6 Apr 2007 21:46:43 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HZveE-000Ol1-QD; Fri, 06 Apr 2007 22:07:06 +0100 Date: Fri, 6 Apr 2007 22:07:06 +0100 From: Ceri Davies To: Rich Teer Message-ID: <20070406210706.GA62044@submonkey.net> References: <20070406025700.GB98545@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.14 (2007-02-12) Sender: Ceri Davies Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:46:44 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 05, 2007 at 09:58:47PM -0700, Rich Teer wrote: > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > > operating system. ZFS is available in the HEAD branch and will be > > available in FreeBSD 7.0-RELEASE as an experimental feature. >=20 > This is fantastic news! At the risk of raking over ye olde arguments, > as the old saying goes: "Dual licensing? We don't need no stinkeen > dual licensing!". :-) Actually, you might want to run that statement by a certain John Birrell (jhb@FreeBSD.org) regarding the DTrace port and see what answer you get. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFrZ6ocfcwTS3JF8RAqO5AKC+VFXTOb7qmDbSvROt62w+TB97RwCfeAAC Bmakw8y3A9CEWGCyoNFl3Q8= =cFVB -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:48:15 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F9DA16A404; Fri, 6 Apr 2007 21:48:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 00C6D13C459; Fri, 6 Apr 2007 21:48:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B24054880A; Fri, 6 Apr 2007 23:48:13 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C4A5C45681; Fri, 6 Apr 2007 23:48:09 +0200 (CEST) Date: Fri, 6 Apr 2007 23:48:04 +0200 From: Pawel Jakub Dawidek To: Alex Dupre Message-ID: <20070406214804.GC61039@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <4615F62A.5090001@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=BAYES_00,CONGRATULATIONS autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:48:15 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 09:26:34AM +0200, Alex Dupre wrote: > Pawel Jakub Dawidek wrote: > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > > operating system. >=20 > Congratulations! You're great! >=20 > > - There is no support for booting off of ZFS file system. >=20 > Even booting kernel from a removable ufs media and then mounting a zfs > root via vfs.root.mountfrom? I just verified that this will be possible: # mount tank on / (zfs, local) devfs on /dev (devfs, local) but I need some time to implement it right. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFsAUForvXbEpPzQRAsKhAKCjz/NirKiSRDuMYrCUn3MB7rjEKQCffn60 OM4HqYjaRNHfUtBXrhXrnfE= =9q4L -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:48:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E4916A406 for ; Fri, 6 Apr 2007 21:48:51 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC8813C483 for ; Fri, 6 Apr 2007 21:48:50 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1143207ana for ; Fri, 06 Apr 2007 14:48:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KAh1OSoZP0ObD92MR+lMpxPqcHJu6+VgL2tqYid+1SSnDUB4JVpoaG9jBUVZHpFR1FbaqcNg/s4fcoP6wAG0eXl+Rnk8XH4tX5MY2SOW4PDMIIKYS2AHW+Wd61bPfXr8py9iuGHSavHk/QunabZae4sz7fkecSuDnF7EpmmgrCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eoTN9/eqSE9oC7AI+BfN5U7hE5J2pBOsoGa/YmCKMsvuDQJVIHQi2AaisN3n7ro54vJEECYd/ltdQwj5oQAIHiAKRtL3HD9cjFhL5Oz5AFkPJX+tpoz/Y4Hx1vcU2OvJLusv8T8ChYlNulblnGPtR9vfpjJj3JLagoGoCKd7WdI= Received: by 10.100.10.20 with SMTP id 20mr2385094anj.1175896130593; Fri, 06 Apr 2007 14:48:50 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 14:48:50 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 16:48:50 -0500 From: "Nikolas Britton" To: "M. Warner Losh" In-Reply-To: <20070406.151901.-1844003065.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <20070406.151901.-1844003065.imp@bsdimp.com> Cc: freebsd-current@freebsd.org, ed@fxq.nl Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:48:51 -0000 On 4/6/07, M. Warner Losh wrote: > In message: > "Nikolas Britton" writes: > : Where is this coming from? I'm trying to debate some of the issues > : with FreeBSD and the only thing you've added to this thread is fuck > : off? Why? > > Because you have used language that is somewhat absolute and have not > done a market research on who actually uses FreeBSD. You have also > shown a fundamental lack of understanding of how modern machines are > put together as well, since you think all things ISA are obsolete > (they are not). > > As others have noted, there's a very large and vibrant embedded > FreeBSD community. This community makes real and meaningful > contributions to FreeBSD. Over the years, I've made thousands of > commits to the tree, funded in large part by the embedded companies > that I have worked for, including CardBus, PC Card, SD/MMC, > infrasturcutre changes, etc. > > Frankly, we'd rather tell a new, upstart to get bent than to tell > actual users and supports of FreeBSD to get bent by removing the > offending items from the tree. It really is a no-brainer. > New upstart? I have not been using FreeBSD for as long as you but I'm definitely not new here, I've been using and hacking on FreeBSD for over 5 years now and my professional experience with almost every operating system under the sun goes back much much farther. If the project leadership doesn't give a shit about the users then I guess I don't give a shit about project. Good bye. I'm sure Sun would mind new users. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:51:28 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58FCE16A401; Fri, 6 Apr 2007 21:51:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id C4C4513C448; Fri, 6 Apr 2007 21:51:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l36LpMlK028736; Fri, 6 Apr 2007 17:51:22 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 6 Apr 2007 17:51:15 -0400 User-Agent: KMail/1.6.2 References: <20070407023855.ede13b76.nork@FreeBSD.org> <200704061407.35340.jkim@FreeBSD.org> <86lkh58ajj.fsf@dwp.des.no> In-Reply-To: <86lkh58ajj.fsf@dwp.des.no> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200704061751.20368.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/3030/Fri Apr 6 14:44:59 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Roman Divacky , Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:51:28 -0000 On Friday 06 April 2007 05:20 pm, Dag-Erling Smørgrav wrote: > Jung-uk Kim writes: > > On Friday 06 April 2007 01:43 pm, Roman Divacky wrote: > > > I dont like this, I would prefer some dynamic determining > > > whether sysv symbols are present and if not just fill > > > in "safe" values. > > > > You know I have used sysctlbyname before but it was shot down by > > des. :-( > > I didn't shoot anything down. If you read my email again, you'll > see that I pointed out that it was slow, but that we didn't really > have a choice precisely because sysv{msg,sem} were not guaranteed > to be present. > > Dropping sysctlbyname() was *your* choice. I agreed with the > revised patch because you pointed out that linprocfs depends on > linux, which depends on sysv{msg,sem}, so we *could* rely on their > presence. It was a bad choice of words. Sorry, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:51:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3702A16A407 for ; Fri, 6 Apr 2007 21:51:54 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtai110.cox.net (eastrmmtai110.cox.net [68.230.240.29]) by mx1.freebsd.org (Postfix) with ESMTP id D962213C459 for ; Fri, 6 Apr 2007 21:51:53 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.05.02.00 201-2174-114-20060621) with ESMTP id <20070406212730.UNVL24015.eastrmmtao103.cox.net@eastrmimpo01.cox.net>; Fri, 6 Apr 2007 17:27:30 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo01.cox.net with bizsmtp id jxTU1W00o4iy4EG0000000; Fri, 06 Apr 2007 17:27:29 -0400 Date: Fri, 06 Apr 2007 16:29:27 -0500 To: "Nikolas Britton" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> <20070406193125.GA27879@kobe.laptop> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Linux) Cc: Giorgos Keramidas , Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:51:54 -0000 On Fri, 06 Apr 2007 15:06:20 -0500, Nikolas Britton wrote: > On 4/6/07, Giorgos Keramidas wrote: >> On 2007-04-06 08:40, Nikolas Britton wrote: >> > I don't appreciate being called a lier. Maybe you should step up to >> > the plate if you don't believe my statistics. >> > >> > AMD Semptron 1,259 >> > AMD Athlon_64 2,796 >> > AMD Athlon_XP 2,885 >> > AMD Athlon 812 >> > AMD Duron 741 >> > AMD Opteron 625 >> > AMD Turion_64 175 >> > >> > Intel Pentium_4 8,768 >> > Intel Pentium_4M 291 >> > Intel Pentium_M 1,722 >> > Intel Pentium_3M 233 >> > Intel Pentium_3 6,362 >> > Intel Pentium_D 982 >> > Intel Pentium_2 1,872 >> > Intel Celeron_P2 888 >> > Intel Celeron_P3 529 >> > Intel Celeron_P4 4,224 >> > Intel Celeron_M 299 >> > Intel Xeon_P4 2,380 >> > Intel Core 1,246 >> > >> > Generic i786 1 >> > Generic i686_SSE 33 >> > Generic i686_MMX 114 >> > Generic i686 298 >> > Generic i586_MMX 520 >> > Generic i586 261 >> > Generic i486 30 >> > Unknown 99 >> > >> > Data source: http://www.bsdstats.org/cpus.php >> >> A lot of people are running "bsdstats" ports, and we should appreciate >> the work people have put into making http://www.bsdstats.org/ happen. >> >> I'm not sure I agree with the use you are putting these statistics into, >> whatever. >> >> The original goal of the statistics pages was to serve as a basis of >> version-related and hardware-related information, which can be used to >> convince hardware vendors to support *MORE* FreeBSD systems. >> >> Now you are arguing that because more modern CPUs and hardware are, >> well, "more modern", we should start dropping support for some of the >> systems listed there -- effectivelly reducing the number of systems >> supported by FreeBSD. >> > > I only suggested dropping PC98. Why? If you look at the PC98 page* it > hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero What make you think that bsdstats is a realistic one? All of my machines do not have bsdstats installed, so there are hundreds or thousands of machines out there that do not have it installed either. > people using it... PC98 is a dead platform like Alpha and Alpha > support is being dropped for FreeBSD 7, but if you look at > bsdstats.org the Alpha platform has more users than sparc, powerpc and > pc98 combined!! -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 21:57:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D72FA16A403 for ; Fri, 6 Apr 2007 21:57:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 76BC513C484 for ; Fri, 6 Apr 2007 21:57:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l36LsaNs006282; Fri, 6 Apr 2007 15:54:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Apr 2007 15:54:44 -0600 (MDT) Message-Id: <20070406.155444.255407280.imp@bsdimp.com> To: nikolas.britton@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20070406203642.GA75672@troutmask.apl.washington.edu> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 06 Apr 2007 15:54:38 -0600 (MDT) Cc: keramida@ceid.upatras.gr, peterjeremy@optushome.com.au, freebsd-current@freebsd.org, sgk@troutmask.apl.washington.edu Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 21:57:28 -0000 In message: "Nikolas Britton" writes: : On 4/6/07, Steve Kargl wrote: : > On Fri, Apr 06, 2007 at 03:25:24PM -0500, Nikolas Britton wrote: : > > On 4/6/07, Steve Kargl wrote: : > > >On Fri, Apr 06, 2007 at 03:06:20PM -0500, Nikolas Britton wrote: : > > >> : > > >> I only suggested dropping PC98. Why? If you look at the PC98 page* it : > > >> hasn't been updated since FreeBSD 4.11 and bsdstats.org shows zero : > > >> people using it... PC98 is a dead platform like Alpha and Alpha : > > >> support is being dropped for FreeBSD 7, but if you look at : > > >> bsdstats.org the Alpha platform has more users than sparc, powerpc and : > > >> pc98 combined!! : > > > : > > >pc98 appears to be popular in Japan. See : > > >http://people.freebsd.org/~kato/pc98.html : > > > : > > >Alpha died because the chip maker stopped : > > >making chips. : > > > : > > : > > NEC stopped making PC98 system in 1997!!! : > : > That's odd. See NEC's press release dated 23 OCT 97 : > concerning a new series of PC98-NX : > : > http://www.nec.co.jp/press/en/9710/2301.html : > : : "The PC-9801's last successor is the Celeron-based PC-9821Ra43 (with a : clockspeed 433MHz), which appeared in 2000" -Wikipedia Ok I was off : by 3 years, but it's still been dead longer than Alpha. Actaully, it wasn't until around 2005 that NEC stopped making NEC-PC9821xxx machines and machine parts. They did so to support the installed base of these machines. I have a PC9821Ra in my garage, as a matter of fact (I'm only blessed with 400MHz). It is my LAN media server. The PC98-NX is a wintel compatible machine that has only PC98 brand-name because it is so popular in Japan. Up until recently, pc98 was the second most popular platform that FreeBSD had. I don't have recent data (the info I have is from 2003), but suspect that it has slipped to third behind amd64. Telling all these long-term die-hard users, who helped to build FreeBSD popularity in Japan to take a hike would be very damaging to the project. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:08:59 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF1A816A402; Fri, 6 Apr 2007 22:08:59 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.freebsd.org (Postfix) with ESMTP id A801213C44B; Fri, 6 Apr 2007 22:08:59 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 377249F284A; Fri, 6 Apr 2007 23:52:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YCOkcLGnOru9; Fri, 6 Apr 2007 23:52:17 +0200 (CEST) Received: from [192.168.2.186] (catv-5063f539.catv.broadband.hu [80.99.245.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 0E8649F2823; Fri, 6 Apr 2007 23:52:16 +0200 (CEST) Message-ID: <4616C107.3050803@FreeBSD.org> Date: Fri, 06 Apr 2007 23:52:07 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ceri Davies References: <20070406025700.GB98545@garage.freebsd.pl> <20070406210706.GA62044@submonkey.net> In-Reply-To: <20070406210706.GA62044@submonkey.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , Rich Teer Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:09:00 -0000 Ceri Davies schrieb: > On Thu, Apr 05, 2007 at 09:58:47PM -0700, Rich Teer wrote: > >>> I'm happy to inform that the ZFS file system is now part of the FreeBSD >>> operating system. ZFS is available in the HEAD branch and will be >>> available in FreeBSD 7.0-RELEASE as an experimental feature. >>> >> This is fantastic news! At the risk of raking over ye olde arguments, >> as the old saying goes: "Dual licensing? We don't need no stinkeen >> dual licensing!". :-) >> > > Actually, you might want to run that statement by a certain John Birrell > (jhb@FreeBSD.org) regarding the DTrace port and see what answer you get. > > jhb@ is John Baldwin, John Birrel is jb@! :) Regards, Gabor From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:11:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C0D016A401 for ; Fri, 6 Apr 2007 22:11:06 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1DC13C483 for ; Fri, 6 Apr 2007 22:11:05 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id E8E8A1A000B1A for ; Fri, 6 Apr 2007 14:49:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vJvlVaLTE-Gy for ; Fri, 6 Apr 2007 14:49:02 -0700 (PDT) Received: from webmail.sd73.bc.ca (webmail.sd73.bc.ca [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 8E8A41A000B14 for ; Fri, 6 Apr 2007 14:49:02 -0700 (PDT) Received: from 24.71.119.183 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Fri, 6 Apr 2007 14:49:02 -0700 (PDT) Message-ID: <62768.24.71.119.183.1175896142.squirrel@webmail.sd73.bc.ca> In-Reply-To: References: <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <86ps6h8as6.fsf@dwp.des.no> Date: Fri, 6 Apr 2007 14:49:02 -0700 (PDT) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:11:06 -0000 On Fri, April 6, 2007 2:27 pm, Nikolas Britton wrote: > On 4/6/07, Dag-Erling Smørgrav wrote: >> "Nikolas Britton" writes: >>> Julian Elischer writes: >>>> We have a LOT of old systems running around the world. >>>> >>> But the old systems don't need the latest and greatest copy of >>> FreeBSD! This is why we provide errata / security fixes. The >>> systems are a static non moving target ??? >> >> Excuse me? Who's "we"? >> >> Julian, Warner, Scott, Bernd, Giorgios, Wilko, myself and many >> others who have contradicted you in this discussion are veteran >> FreeBSD >> developers with something like a hundred years of industry >> experience between us. >> >> You, on the other hand are just a pathetic little fuck who has >> repeatedly demonstrated his complete lack of understanding of >> anything remotely approaching real computers, real software and real >> life. >> >> You do not get to tell us how to run our project. >> >> You do not get to say "we". > > Read it again dick head, Julian Elischer wrote "we". Double-check your mail archive (or just re-read the above, it's all right there). The part that DES is rightfully complaining about is this (which you wrote in reply to Julian, and which DES properly quoted): "This is why we provide errata / security fixes. The systems are a static non moving target ???" If you're going to insult someone, at least spend 30 seconds to make sure you are in the right about it. :) ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:16:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56D1416A403 for ; Fri, 6 Apr 2007 22:16:12 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id E7F8913C489 for ; Fri, 6 Apr 2007 22:16:11 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id l36MG82T029853; Sat, 7 Apr 2007 00:16:08 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l36MFQG9001701; Sat, 7 Apr 2007 00:15:26 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l36MFQek001700; Sat, 7 Apr 2007 00:15:26 +0200 (CEST) (envelope-from wb) Date: Sat, 7 Apr 2007 00:15:25 +0200 From: Wilko Bulte To: Nikolas Britton Message-ID: <20070406221525.GB1631@freebie.xs4all.nl> References: <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <20070406.151901.-1844003065.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, ed@fxq.nl, "M. Warner Losh" Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:16:12 -0000 On Fri, Apr 06, 2007 at 04:48:50PM -0500, Nikolas Britton wrote.. > On 4/6/07, M. Warner Losh wrote: > >In message: > > "Nikolas Britton" writes: > >: Where is this coming from? I'm trying to debate some of the issues > >: with FreeBSD and the only thing you've added to this thread is fuck > >: off? Why? > > > >Because you have used language that is somewhat absolute and have not > >done a market research on who actually uses FreeBSD. You have also > >shown a fundamental lack of understanding of how modern machines are > >put together as well, since you think all things ISA are obsolete > >(they are not). > > > >As others have noted, there's a very large and vibrant embedded > >FreeBSD community. This community makes real and meaningful > >contributions to FreeBSD. Over the years, I've made thousands of > >commits to the tree, funded in large part by the embedded companies > >that I have worked for, including CardBus, PC Card, SD/MMC, > >infrasturcutre changes, etc. > > > >Frankly, we'd rather tell a new, upstart to get bent than to tell > >actual users and supports of FreeBSD to get bent by removing the > >offending items from the tree. It really is a no-brainer. > > > > New upstart? I have not been using FreeBSD for as long as you but I'm > definitely not new here, I've been using and hacking on FreeBSD for > over 5 years now and my professional experience with almost every > operating system under the sun goes back much much farther. If the > project leadership doesn't give a shit about the users then I guess I > don't give a shit about project. Good bye. I'm sure Sun would mind new > users. Happy trails. Please do not return. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:21:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0B9716A402 for ; Fri, 6 Apr 2007 22:21:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 721BD13C44C for ; Fri, 6 Apr 2007 22:21:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l36MIOdf006509; Fri, 6 Apr 2007 16:18:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Apr 2007 16:18:32 -0600 (MDT) Message-Id: <20070406.161832.-1253044863.imp@bsdimp.com> To: nikolas.britton@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20070406.151901.-1844003065.imp@bsdimp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 06 Apr 2007 16:18:25 -0600 (MDT) Cc: freebsd-current@freebsd.org, ed@fxq.nl Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:21:28 -0000 In message: "Nikolas Britton" writes: : On 4/6/07, M. Warner Losh wrote: : > In message: : > "Nikolas Britton" writes: : > : Where is this coming from? I'm trying to debate some of the issues : > : with FreeBSD and the only thing you've added to this thread is fuck : > : off? Why? : > : > Because you have used language that is somewhat absolute and have not : > done a market research on who actually uses FreeBSD. You have also : > shown a fundamental lack of understanding of how modern machines are : > put together as well, since you think all things ISA are obsolete : > (they are not). : > : > As others have noted, there's a very large and vibrant embedded : > FreeBSD community. This community makes real and meaningful : > contributions to FreeBSD. Over the years, I've made thousands of : > commits to the tree, funded in large part by the embedded companies : > that I have worked for, including CardBus, PC Card, SD/MMC, : > infrasturcutre changes, etc. : > : > Frankly, we'd rather tell a new, upstart to get bent than to tell : > actual users and supports of FreeBSD to get bent by removing the : > offending items from the tree. It really is a no-brainer. : > : : New upstart? I have not been using FreeBSD for as long as you but I'm : definitely not new here, I've been using and hacking on FreeBSD for : over 5 years now and my professional experience with almost every : operating system under the sun goes back much much farther. If the : project leadership doesn't give a shit about the users then I guess I : don't give a shit about project. Good bye. I'm sure Sun would mind new : users. You are twisting my argument. It is because the project does care about its users that it can't do what you suggest Please do not confuse my disagreeing with your viewpoint with not caring about users. If I have a better understanding of the user community it is because I've been talking to them for the past 10 years to find out what they are doing with FreeBSD, what platforms they are on today, where they are moving to etc. FreeBSD has many competitive advantages over the other guys, and the suggestions you make wouldn't allow our users to leverage them on hardware they desire to do so. If you can show a measurable difference with the changes you suggest, then please do so. I know that removing pc98 from the tree completely will have 0 effect on performance of i386 or amd64. Anyway, please have a nice day. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:23:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E28D916A403; Fri, 6 Apr 2007 22:23:45 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE8613C458; Fri, 6 Apr 2007 22:23:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36MMbGg020539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Apr 2007 01:22:45 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36MMU9k040573; Sat, 7 Apr 2007 01:22:31 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36MMSTY040572; Sat, 7 Apr 2007 01:22:28 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 7 Apr 2007 01:22:27 +0300 From: Giorgos Keramidas To: John Baldwin , Ariff Abdullah Message-ID: <20070406222227.GA1839@kobe.laptop> References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> <200703271227.14308.jhb@freebsd.org> <20070406211229.GB1078@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406211229.GB1078@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.079, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Alexander Leidinger , freebsd-current@freebsd.org, current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:23:46 -0000 On 2007-04-07 00:12, Giorgos Keramidas wrote: > On 2007-03-27 12:27, John Baldwin wrote: > > If that is the case it's because code was using > > rman_get_bus(handle|tag) on a resource that wasn't activated yet which > > wouldn't have worked before the nexus changes either. Well, the bus > > tag might have been right, but the handle for SYS_RES_MEMORY would > > have been wrong. > > This is the change which stops snd_hda from working here: > > % Revision Changes Path > % 1.233 +39 -55 src/sys/dev/acpica/acpi.c There's only one place in the sound/pci/hda/* source tree where rman_get_bus(handle|tag)() calls are used: keramida@kobe:/home/keramida/hg/freebsd/src/sys/dev/sound/pci/hda$ grep -n 'rman_get_bus\(handle\|tag\)' * hdac.c:1301: mem->mem_tag = rman_get_bustag(mem->mem_res); hdac.c:1302: mem->mem_handle = rman_get_bushandle(mem->mem_res); keramida@kobe:/home/keramida/hg/freebsd/src/sys/dev/sound/pci/hda$ [...] 1281 /**************************************************************************** 1282 * int hdac_mem_alloc(struct hdac_softc *) 1283 * 1284 * Allocate all the bus resources necessary to speak with the physical 1285 * controller. 1286 ****************************************************************************/ 1287 static int 1288 hdac_mem_alloc(struct hdac_softc *sc) 1289 { 1290 struct hdac_mem *mem; 1291 1292 mem = &sc->mem; 1293 mem->mem_rid = PCIR_BAR(0); 1294 mem->mem_res = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, 1295 &mem->mem_rid, RF_ACTIVE); 1296 if (mem->mem_res == NULL) { 1297 device_printf(sc->dev, 1298 "%s: Unable to allocate memory resource\n", __func__); 1299 return (ENOMEM); 1300 } 1301 mem->mem_tag = rman_get_bustag(mem->mem_res); 1302 mem->mem_handle = rman_get_bushandle(mem->mem_res); 1303 1304 return (0); 1305 } I'm not very familiar with the rman_get_xxx() functions, but is there a better way to write the hdac_mem_alloc() function so that it works with the recent acpi.c versions? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:23:45 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E28D916A403; Fri, 6 Apr 2007 22:23:45 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE8613C458; Fri, 6 Apr 2007 22:23:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36MMbGg020539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Apr 2007 01:22:45 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36MMU9k040573; Sat, 7 Apr 2007 01:22:31 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36MMSTY040572; Sat, 7 Apr 2007 01:22:28 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 7 Apr 2007 01:22:27 +0300 From: Giorgos Keramidas To: John Baldwin , Ariff Abdullah Message-ID: <20070406222227.GA1839@kobe.laptop> References: <4608A5D9.2010902@root.org> <20070327151058.5qk9etifk880g4cc@webmail.leidinger.net> <20070327140741.GA60454@kobe.laptop> <200703271227.14308.jhb@freebsd.org> <20070406211229.GB1078@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406211229.GB1078@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.079, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.32, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Alexander Leidinger , freebsd-current@freebsd.org, current@freebsd.org, S?ren Schmidt , Nate Lawson Subject: Re: recent commits break via 8235 ata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:23:46 -0000 On 2007-04-07 00:12, Giorgos Keramidas wrote: > On 2007-03-27 12:27, John Baldwin wrote: > > If that is the case it's because code was using > > rman_get_bus(handle|tag) on a resource that wasn't activated yet which > > wouldn't have worked before the nexus changes either. Well, the bus > > tag might have been right, but the handle for SYS_RES_MEMORY would > > have been wrong. > > This is the change which stops snd_hda from working here: > > % Revision Changes Path > % 1.233 +39 -55 src/sys/dev/acpica/acpi.c There's only one place in the sound/pci/hda/* source tree where rman_get_bus(handle|tag)() calls are used: keramida@kobe:/home/keramida/hg/freebsd/src/sys/dev/sound/pci/hda$ grep -n 'rman_get_bus\(handle\|tag\)' * hdac.c:1301: mem->mem_tag = rman_get_bustag(mem->mem_res); hdac.c:1302: mem->mem_handle = rman_get_bushandle(mem->mem_res); keramida@kobe:/home/keramida/hg/freebsd/src/sys/dev/sound/pci/hda$ [...] 1281 /**************************************************************************** 1282 * int hdac_mem_alloc(struct hdac_softc *) 1283 * 1284 * Allocate all the bus resources necessary to speak with the physical 1285 * controller. 1286 ****************************************************************************/ 1287 static int 1288 hdac_mem_alloc(struct hdac_softc *sc) 1289 { 1290 struct hdac_mem *mem; 1291 1292 mem = &sc->mem; 1293 mem->mem_rid = PCIR_BAR(0); 1294 mem->mem_res = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, 1295 &mem->mem_rid, RF_ACTIVE); 1296 if (mem->mem_res == NULL) { 1297 device_printf(sc->dev, 1298 "%s: Unable to allocate memory resource\n", __func__); 1299 return (ENOMEM); 1300 } 1301 mem->mem_tag = rman_get_bustag(mem->mem_res); 1302 mem->mem_handle = rman_get_bushandle(mem->mem_res); 1303 1304 return (0); 1305 } I'm not very familiar with the rman_get_xxx() functions, but is there a better way to write the hdac_mem_alloc() function so that it works with the recent acpi.c versions? From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:31:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1818A16A406 for ; Fri, 6 Apr 2007 22:31:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 8916C13C4B7 for ; Fri, 6 Apr 2007 22:31:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l36MV2Fr080380; Sat, 7 Apr 2007 08:31:02 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l36MV2BU080379; Sat, 7 Apr 2007 08:31:02 +1000 (EST) (envelope-from peter) Date: Sat, 7 Apr 2007 08:31:02 +1000 From: Peter Jeremy To: Nikolas Britton Message-ID: <20070406223102.GB71995@turion.vk2pj.dyndns.org> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:31:05 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-06 14:43:31 -0500, Nikolas Britton = wrote: >That's not true. If you look at the stats I posted over 58% of the >systems have SSE2 support, compared to the 20%* with 64-bit >capability. So, on your statistics[*], the FreeBSD project should drop support for around 40% of the systems currently running FreeBSD. Exactly how does this benefit those people? >The legacy bits don't upset me, Then why did you start this thread by wanting to delete them? > what upsets me is sacrificing >performance so we can support a minority of legacy systems. Whilst 40% is a minority, it's hardly a _small_ minority. And since you're the one who is keen on statistics, how come you haven't quantified the amount of performance FreeBSD is 'sacrificing'. > IIRC? we >could recode the Kernel for SSE2 math if the processor was guaranteed >to have that SSE2. And this would benefit the project how? How about you do this and report back on the performance improvement. > SSE2 adds 214 new instructions to the existing x86 >instruction set. How many of these instructions are actually useful in the kernel? > The problem with 64-bit FreeBSD is performance, on >average its slower than FreeBSD i386 and FreeBSD i386 is already quite >slow without custom optimizations. I presume you can substantiate these claims. > New >users frequently get themselves into a big mess because it takes years >of knowledge about FreeBSD internals to make it fast without breaking >it. This turns new users off and can create support problems. More unsubstantiated claims. If you believe that the FreeBSD project is headed in the wrong direction, you are free to fork FreeBSD and head off in whatever direction you choose. If you can demonstrate that your approach has advantages then more people will join you. [*] bsdstats is acknowledged by everyone except you to represent a very small and highly biased subset of FreeBSD users. --=20 Peter Jeremy --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFsom/opHv/APuIcRAmY4AKCaZUB99YYwbPdbS6k7w09NRQftYQCfXP9J BYp6MkAAd/U9XDbjkYlvdYw= =8Pj/ -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:53:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EC9516A402 for ; Fri, 6 Apr 2007 20:53:44 +0000 (UTC) (envelope-from erik@cepheid.org) Received: from mail.cepheid.org (wintermute.cepheid.org [64.92.165.98]) by mx1.freebsd.org (Postfix) with ESMTP id E3C0F13C45D for ; Fri, 6 Apr 2007 20:53:43 +0000 (UTC) (envelope-from erik@cepheid.org) Received: by mail.cepheid.org (Postfix, from userid 1006) id 1A33F170E6; Fri, 6 Apr 2007 15:28:48 -0500 (CDT) Date: Fri, 6 Apr 2007 15:28:48 -0500 From: Erik Osterholm To: Nikolas Britton Message-ID: <20070406202847.GA91533@idoru.cepheid.org> Mail-Followup-To: Erik Osterholm , Nikolas Britton , FreeBSD Current References: <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Fri, 06 Apr 2007 22:33:39 +0000 Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:53:44 -0000 On Fri, Apr 06, 2007 at 03:23:14PM -0500, Nikolas Britton wrote: > On 4/6/07, Julian Elischer wrote: > > > >I think some of the frustration people have shown with you is because > >you don't seem to appreciate how much this issue is constantly thought > >about and how the current state is not just an "accident of history". > > > >We have a LOT of old systems running around the world. > > > > But the old systems don't need the latest and greatest copy of > FreeBSD! This is why we provide errata / security fixes. The systems > are a static non moving target ??? Ah, but old systems are the most likely to see a significant benefit from performance improvements. Erik From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:43:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AA7316A402 for ; Fri, 6 Apr 2007 22:43:56 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6BB13C469 for ; Fri, 6 Apr 2007 22:43:56 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1151091ana for ; Fri, 06 Apr 2007 15:43:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HpmIGUHkjrOT/Bp53tPlswYc5e0e2bUWOpfddEyWHOSCG3P9/xou7WdL0GMW15ybBcFIaWX/kQ7v+1M6AF9iXP135JW7pfsQ+QCWuPfy04dM3aFg0IVYdWCmOpF2/IJKhhBY8WBXVVrMJa/rbsOff0wjVBjY45c+169zncK2Cic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k/iKukIYc9kCLOs6agRf4M6z8bXGCAugFlts3vEVCav4yoRrzGIRg2xZ7D+Ff2DqMl0Vv8aq9JV7LLegW0GowBG8gnBdDmf2kwYZP0FO0Mqdyl1FHrTQupY17IfBa3Km1usU5RZn3Ir1OnaEb/LxVZY6F58LQD8ABQJwqtISPhU= Received: by 10.100.191.5 with SMTP id o5mr2395600anf.1175899435620; Fri, 06 Apr 2007 15:43:55 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 15:43:55 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 17:43:55 -0500 From: "Nikolas Britton" To: "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: You have been unsubscribed from the freebsd-openoffice mailing list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:43:56 -0000 FreeBSD 5, 6, and 7?: Much work remains to be done before we can announce our total failure to make any progress. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:45:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BD2016A403 for ; Fri, 6 Apr 2007 22:45:11 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5B95213C484 for ; Fri, 6 Apr 2007 22:45:11 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1151258ana for ; Fri, 06 Apr 2007 15:45:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=abUqVSjG4I0zQA6MB1wa0NWtyzo+eKJLoDpdyoAGaILDhRnWmbIBcgditcIGDfASdYcph7P5gdFehT/Y7+/Blew9I+95YXrCqvyANIORal15UmaMj0n/Dty8oX/QEOJqyo6wSjKFFxeT5FG9Evbt4bX/ihVUy1og4V9crM5cbmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mV0yGK5BPG5uokqq4/n93IqyCRGTnyMk1kMfrKWX3P8NKKpIzidIatspJGcuB1v/ytbWcAaIWYUJ1mKJNk6P1cNWE9LKMflThatpnPiUsSAaYYLdovdb/wGz4JLUKq/Ku+cKAqQBgqx6zleWIs0IQJRx15dwBBAM0+gYUktkB6I= Received: by 10.100.190.8 with SMTP id n8mr2413573anf.1175899510810; Fri, 06 Apr 2007 15:45:10 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 15:45:10 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 17:45:10 -0500 From: "Nikolas Britton" To: "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: You have been unsubscribed from the freebsd-questions mailing list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:45:11 -0000 It takes months to find new users, but only seconds to lose one... the good news is that we should run out of them in no time. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:45:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3091016A404 for ; Fri, 6 Apr 2007 22:45:43 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id E505E13C457 for ; Fri, 6 Apr 2007 22:45:42 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1151321ana for ; Fri, 06 Apr 2007 15:45:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZnuBb2t5AySL68xbToS9UYNkDwXO0NnZn9qFFt2OUie1WR3PH2cSfQLi4iLxlVQKuMQ8uqykepv73gNuu8UO3SIKAm/JPAzu5NuTSAHmMPcMvJN0HHVcHcSDgtiZkkxLg2f3ZOZykOj6Z2pSsXX9NBSJico9Fz99Qy0la7Wlr/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LMo1peiSzt21UqetN31BIQOqznIh1JRgdDOENkNL0i0R2cyRu/4LrabqIHmKk7R4ifz4zqxX7iO7mHQ4ErG6cOd0nS5X6SA9TDV90uKZekh9kC3UFm62pPpHNLKzWGXCWo7gk2Z1p/JdV7KOTWmxxq5MJtGpkPk6XzQAD0Rc4mQ= Received: by 10.100.196.3 with SMTP id t3mr2395019anf.1175899542372; Fri, 06 Apr 2007 15:45:42 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 15:45:42 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 17:45:42 -0500 From: "Nikolas Britton" To: "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: You have been unsubscribed from the freebsd-stable mailing list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:45:43 -0000 It takes months to find new users, but only seconds to lose one... the good news is that we should run out of them in no time. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 22:47:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99F0416A402 for ; Fri, 6 Apr 2007 22:47:58 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5A31A13C458 for ; Fri, 6 Apr 2007 22:47:58 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1151611ana for ; Fri, 06 Apr 2007 15:47:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fy+AizWJH8ANIexxD78fRzq9g6ptqYzB5nsGDdYbpJkEdCVVlLYGFjeVmVsV5d5UGkMkC+ZGmkOUnxebD0McWjjgdTd1U8/c7V6P8PQOCmsv7jX2qU90Xq0hJfR/mvNIawo6wiD9V1HMaO8iVCc24G/dS9kEkMcqzQoMWQG/iAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mk2DaOD8A9Zh05x2V86d9BdkMe1cycGaMrwPa8sShk1DOoEyFUYfMBqaiIpqNucRab9csg3WY6mdvFn+e0gurIGN4kwRqNMUSaLb8zzjUYwGXOWJPbEaTOM1mkbvM5bESjlxbBfTCN+t2dvgXGCa77+DolqaMFwgPDWPypKg7eI= Received: by 10.100.9.19 with SMTP id 19mr2446899ani.1175899677839; Fri, 06 Apr 2007 15:47:57 -0700 (PDT) Received: by 10.100.109.12 with HTTP; Fri, 6 Apr 2007 15:47:57 -0700 (PDT) Message-ID: Date: Fri, 6 Apr 2007 17:47:57 -0500 From: "Nikolas Britton" To: "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: You have been unsubscribed from the freebsd-net mailing list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 22:47:58 -0000 Leaders are like eagles. We don't have either of them here. From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 23:15:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66ABE16A401 for ; Fri, 6 Apr 2007 23:15:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2D99C13C4C6 for ; Fri, 6 Apr 2007 23:15:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 338DF1CC22; Sat, 7 Apr 2007 01:15:20 +0200 (CEST) Date: Sat, 7 Apr 2007 01:15:20 +0200 From: Ed Schouten To: Nikolas Britton Message-ID: <20070406231520.GG6950@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/i8j2F0k9BYX4qLc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Cc: FreeBSD Current Subject: Re: You have been unsubscribed from the freebsd-net mailing list X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 23:15:27 -0000 --/i8j2F0k9BYX4qLc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable You forgot freebsd-current@ --=20 Ed Schouten WWW: http://g-rave.nl/ --/i8j2F0k9BYX4qLc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGFtSI52SDGA2eCwURAuYWAJ46X0ls+vXHYUAMrDH0RLaF/HBipACeL9NW tHA5rIpHzgZNb0ugxhNoPVo= =AsIM -----END PGP SIGNATURE----- --/i8j2F0k9BYX4qLc-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 23:26:37 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FE9616A404; Fri, 6 Apr 2007 23:26:37 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 520C113C45E; Fri, 6 Apr 2007 23:26:37 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix2-g20.free.fr (Postfix) with ESMTP id 5C500DD314F; Sat, 7 Apr 2007 00:06:48 +0200 (CEST) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp2-g19.free.fr (Postfix) with ESMTP id 2CAC495F7A; Sat, 7 Apr 2007 01:06:27 +0200 (CEST) Message-ID: <4616D272.30902@free.fr> Date: Sat, 07 Apr 2007 01:06:26 +0200 From: Bruno Damour User-Agent: Thunderbird 1.5.0.10 (X11/20070309) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 23:26:37 -0000 Thanks, fantasticly interesting ! > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. > I'm waiting eagerly to amd64 version.... > Missing functionality. > > - There is no support for ACLs and extended attributes. > Is this planned ? Does that means I cannot use it as a basis for a full-featured samba share ? Thanks for your great work !! Bruno DAMOUR From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 00:36:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA82616A407 for ; Sat, 7 Apr 2007 00:36:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 57E6113C48A for ; Sat, 7 Apr 2007 00:36:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l370aoaB094115; Fri, 6 Apr 2007 18:36:51 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4616E795.5000702@samsco.org> Date: Fri, 06 Apr 2007 18:36:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Nikolas Britton References: <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <20070406.151901.-1844003065.imp@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 06 Apr 2007 18:36:51 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, ed@fxq.nl, "M. Warner Losh" Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 00:36:58 -0000 Nikolas Britton wrote: > On 4/6/07, M. Warner Losh wrote: >> In message: >> "Nikolas Britton" writes: >> : Where is this coming from? I'm trying to debate some of the issues >> : with FreeBSD and the only thing you've added to this thread is fuck >> : off? Why? >> >> Because you have used language that is somewhat absolute and have not >> done a market research on who actually uses FreeBSD. You have also >> shown a fundamental lack of understanding of how modern machines are >> put together as well, since you think all things ISA are obsolete >> (they are not). >> >> As others have noted, there's a very large and vibrant embedded >> FreeBSD community. This community makes real and meaningful >> contributions to FreeBSD. Over the years, I've made thousands of >> commits to the tree, funded in large part by the embedded companies >> that I have worked for, including CardBus, PC Card, SD/MMC, >> infrasturcutre changes, etc. >> >> Frankly, we'd rather tell a new, upstart to get bent than to tell >> actual users and supports of FreeBSD to get bent by removing the >> offending items from the tree. It really is a no-brainer. >> > > New upstart? I have not been using FreeBSD for as long as you but I'm > definitely not new here, I've been using and hacking on FreeBSD for > over 5 years now and my professional experience with almost every > operating system under the sun goes back much much farther. If the > project leadership doesn't give a shit about the users then I guess I > don't give a shit about project. Good bye. I'm sure Sun would mind new > users. Oh, you wanted a discussion? I thought you wanted baseless opinions. Oh well, I'm sure that the OpenSolaris developers are eager to hear your ideas on what they should and should not work on and support. Scott From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 00:57:23 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6DDC16A40E; Sat, 7 Apr 2007 00:57:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 478E813C489; Sat, 7 Apr 2007 00:57:22 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AFE7948804; Sat, 7 Apr 2007 02:57:20 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6F94B487F3; Sat, 7 Apr 2007 02:57:10 +0200 (CEST) Date: Sat, 7 Apr 2007 02:57:05 +0200 From: Pawel Jakub Dawidek To: Bruno Damour Message-ID: <20070407005705.GA63050@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4616CC12.8040107@ruomad.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <4616CC12.8040107@ruomad.net> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 00:57:23 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2007 at 12:39:14AM +0200, Bruno Damour wrote: > Thanks, fantasticly interesting ! > > Currently ZFS is only compiled as kernel module and is only available > > for i386 architecture. Amd64 should be available very soon, the other > > archs will come later, as we implement needed atomic operations. > > =20 > I'm waiting eagerly to amd64 version.... >=20 > >Missing functionality. > > > > - There is no support for ACLs and extended attributes. > > =20 > Is this planned ? Does that means I cannot use it as a basis for a full-f= eatured samba share ? It is planned, but it's not trivial. Does samba support NFSv4-style ACLs? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGFuxhForvXbEpPzQRAjJ8AKCDd1niLSCrOSwQx5LZ+lMoqY5sJwCfde+y tDF1oZaEpNgj2AAyQHLzeE0= =+Mot -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 02:56:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08FA616A402; Sat, 7 Apr 2007 02:56:58 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8E20B13C468; Sat, 7 Apr 2007 02:56:55 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l372urS1098664; Sat, 7 Apr 2007 04:56:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l372ujMZ086765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 04:56:46 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l372ujG3015401; Sat, 7 Apr 2007 04:56:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l372ujBZ015400; Sat, 7 Apr 2007 04:56:45 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 04:56:45 +0200 From: Bernd Walter To: Pawel Jakub Dawidek Message-ID: <20070407025644.GC8831@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 02:56:58 -0000 On Fri, Apr 06, 2007 at 04:57:00AM +0200, Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. I got a kmem panic just by copying a recent ports.tgz (36M) onto a ZFS. My sandbox just has 128MB RAM so kmem was set to ~40M. After raising kmem to 80M it survived copying the file, but paniced again while tar -xvzf the file into the same pool. vfs.zfs.vdev.cache.size is unchanged at 10M. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 03:25:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC65F16A401; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id B738313C468; Sat, 7 Apr 2007 03:25:03 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id DC5898C9B50; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id C41808C9B4E; Sat, 7 Apr 2007 11:05:00 +0800 (CST) Date: Sat, 7 Apr 2007 11:05:00 +0800 (CST) From: Tai-hwa Liang To: Jack Vogel In-Reply-To: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> Message-ID: <0704071047341.19686@www.mmlab.cse.yzu.edu.tw> References: <2a41acea0704051434p2b8c5902x868d0a5d6510aa01@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , freebsd-current , freebsd-stable@freebsd.org Subject: Re: Stack panic with em driver unload X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 03:25:04 -0000 On Thu, 5 Apr 2007, Jack Vogel wrote: > Our test group uses a script that does 100 iterations of > a module load, then bring up all interfaces, and then > unload driver. > > Depending on the system in anything from just a few > iterations to 20 or more, the system will panic. Just a "me too" here. :p > Its doing an em_detach() which calls ether_ifdetach() > which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, > and finally if_delmulti(). > > The panic is always happening on a cmpxchgq instruction > so I assume its the LOCK macro, whats odd is that its > not always the same reason, sometimes one register is > 0 so its a page fault trap, but on other iterations its a > general protection fault because the register is some > big invalid number :) I run into this panic regularly. Apparently the result and condition to trigger the panic are the same as yours: running "while true; do ifconfig xxx up; kldunload if_xxx; done" and ending up with panicking at the cmpxchgq instruction. > I am hardpressed to see this as a driver problem, but > I'm willing to be proven wrong, does someone who > knows the stack code better than me have any insights > or ideas? > > It also appears system dependent, I have a couple > machines I've tried to reproduce in on and have been > unable. I also am told it happens on both amd64 and > i386, but it seems easier to reproduce on the former. Dunno about amd64 since I only have i386 around; however, I'm sure the panic I observed is reproducible on my -CURRENT driver development box. > Lastly, from evidence so far I think this doesnt happen > on CURRENT, but the test group hasnt checked that > only I have and I dont have as much hardware :) FWIW, I usually run into this panic after upgrading to a newer HEAD. Sometimes I can make the aforementioned ifconfig/kldunload script to survive longer by doing a clean rebuild on my driver. -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 06:44:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC8DF16A402 for ; Sat, 7 Apr 2007 06:44:44 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id AAA9A13C455 for ; Sat, 7 Apr 2007 06:44:44 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l376iia5014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Apr 2007 23:44:44 -0700 X-Auth-Received: from [192.168.10.45] (c-24-7-142-221.hsd1.ca.comcast.net [24.7.142.221]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l376ihEt000351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Apr 2007 23:44:43 -0700 Message-ID: <46173DCF.1040200@u.washington.edu> Date: Fri, 06 Apr 2007 23:44:31 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070405.135306.78791677.imp@bsdimp.com> In-Reply-To: <20070405.135306.78791677.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.6.232935 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 06:44:44 -0000 Warner Losh wrote: >> legacyfree1# grep -irsn isa ./ | grep -i include > >>From the system: no. From your kernel, absolutely. > > Warner Sorry if I go out of order, but I'm viewing this in the threaded format in Thunderbird (it's easier to keep track of crazy long threads like this). Personally, I don't think that we (as a community) should give up support in any particular architecture or device. Instead, we should in fact maybe prioritize our energies in useful things, like what has been largely done in the CURRENT branch for some time. Regardless of any operating system getting rid of support for devices or architectures, there will always be some level of backwards compatibility built into modern day architectures that support older architectures. Take Pentium 4's for example. (correct me if I'm getting this wrong, but) Pentium 4's largely support all functionality way back to the original 386 microprocessor, and even further (I think PC98) with certain features like Real mode, architectural operators, and the like. Why? Maximum compatibility. Because it stinks at the end of the day when you try and run a binary and it doesn't work on machine A) because they ruled the hardware / instruction set to be obsolete. Same goes for other things, like Perl. Intel (I work for them as an intern) still uses ancient versions of perl for internal tools. Why? Because we have tools that require ancient versions of Perl. Same goes for many IT groups supporting software and OSes. It's a big thing when you say, "sorry, we don't support you anymore", because there may be a large group of people out there that still use the hardware that we'd isolate. Granted, I agree in EoL and the like, and I think that some things could stand to maybe be removed to some extent, but I think that justifying such actions based on such a limited set of statistics isn't correct because you're robbing many people of a "freedom of computing". That's basically what I feel like with OSes like Vista, where you are required to purchase new hardware, just to run the OS. We don't need to keep up with the Joneses over in Redmond, WA :). Furthermore keep in mind, while we run excellent machines in this section of the world I've heard of other people running much older, lower class machines (Romania / Czechoslovakia for instance) in internet cafes, and they think that their PCs are the best things since sliced bread, even though they just run Win 3.11. Although I think that the ultimate goal of this thread can be good, it needs to be brought back down to a safe level so we can discuss about this topic more rationally and less with our emotions. Cheers and good luck to all, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 06:50:08 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0077716A406; Sat, 7 Apr 2007 06:50:08 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 9350F13C4B9; Sat, 7 Apr 2007 06:50:07 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id l376o44Q097531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 15:50:05 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 7 Apr 2007 04:12:36 +0900 From: Norikatsu Shigemura To: Jung-uk Kim Message-Id: <20070407041236.d4cb0d39.nork@FreeBSD.org> In-Reply-To: <200704061505.18799.jkim@FreeBSD.org> References: <20070407023855.ede13b76.nork@FreeBSD.org> <200704061351.30424.jkim@FreeBSD.org> <20070407032643.72fd55df.nork@FreeBSD.org> <200704061505.18799.jkim@FreeBSD.org> X-Mailer: Sylpheed 2.4.0beta7 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sat, 07 Apr 2007 15:50:05 +0900 (JST) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Cannot mount linprocfs by unresolving sysvs?m symbols X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 06:50:08 -0000 On Fri, 6 Apr 2007 15:05:16 -0400 Jung-uk Kim wrote: > > 'dependency of dependency' you saied is not broken. It's > > specification:-) of kernel symbol resolver. It can resolve > > one level export symbols:-(. > Okay, can we fix the 'specification', then? ;-) Of course, I have no idea!! :D From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 06:56:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F32F16A404 for ; Sat, 7 Apr 2007 06:56:45 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 2C54613C45A for ; Sat, 7 Apr 2007 06:56:45 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l376uiNf023364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Apr 2007 23:56:44 -0700 X-Auth-Received: from [192.168.10.45] (c-24-7-142-221.hsd1.ca.comcast.net [24.7.142.221]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l376uifr000852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Apr 2007 23:56:44 -0700 Message-ID: <461740A0.2090707@u.washington.edu> Date: Fri, 06 Apr 2007 23:56:32 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070405.135306.78791677.imp@bsdimp.com> <46173DCF.1040200@u.washington.edu> <20070407065408.GA15430@dmr.ath.cx> In-Reply-To: <20070407065408.GA15430@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.6.234833 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 06:56:45 -0000 Emil Mikulic wrote: > On Fri, Apr 06, 2007 at 11:44:31PM -0700, Garrett Cooper wrote: >> Furthermore keep in mind, while we run excellent machines in this >> section of the world I've heard of other people running much older, >> lower class machines (Romania / Czechoslovakia for instance) in internet >> cafes, and they think that their PCs are the best things since sliced >> bread, even though they just run Win 3.11. > > Dude, Czechoslovakia hasn't been a country since 1993. ;) > > And from talking with a buddy of mine who lives in the Czech Republic, > they have a lot more internets over there than we have here in > Australia. =( > > --Emil Sorry -- meant Bosnia / Romania. You're right :P. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 07:39:47 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3256916A406 for ; Sat, 7 Apr 2007 07:39:47 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4CF13C469 for ; Sat, 7 Apr 2007 07:39:46 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 84543 invoked from network); 7 Apr 2007 07:39:44 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 7 Apr 2007 07:39:44 -0000 Message-ID: <46174AC0.2040603@FreeBSD.org> Date: Sat, 07 Apr 2007 09:39:44 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> <20070406214804.GC61039@garage.freebsd.pl> In-Reply-To: <20070406214804.GC61039@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 07:39:47 -0000 Pawel Jakub Dawidek wrote: > I just verified that this will be possible: > > # mount > tank on / (zfs, local) > devfs on /dev (devfs, local) > > but I need some time to implement it right. I waited months for current ZFS implementation, I can wait more for root support, now that I know it'll be possible :-) Thanks again. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 08:21:01 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DB9916A47B; Sat, 7 Apr 2007 08:21:00 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from mx1.unixguru.nl (mx1.unixguru.nl [84.16.238.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCA213C457; Sat, 7 Apr 2007 08:21:00 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from localhost (localhost [127.0.0.1]) by mx1.unixguru.nl (Postfix) with ESMTP id 491BF3F8B; Sat, 7 Apr 2007 09:54:41 +0200 (CEST) Received: from mx1.unixguru.nl ([84.16.238.226]) by localhost (vs8616 [84.16.238.226]) (amavisd-new, port 10024) with ESMTP id 31248-08; Sat, 7 Apr 2007 09:54:40 +0200 (CEST) Received: from mail.unixguru.nl (cc1029189-b.emmen1.dr.home.nl [212.120.92.81]) by mx1.unixguru.nl (Postfix) with ESMTP id 014E93F8A; Sat, 7 Apr 2007 09:54:39 +0200 (CEST) Received: from localhost (sun.unixguru.nl [192.168.10.7]) by mail.unixguru.nl (Postfix) with ESMTP id 6637356470; Sat, 7 Apr 2007 09:54:35 +0200 (CEST) Date: Sat, 7 Apr 2007 09:54:35 +0200 From: Richard Arends To: Pawel Jakub Dawidek Message-ID: <20070407075435.GP20680@sun.unixguru.nl> References: <20070406214325.GB61039@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406214325.GB61039@garage.freebsd.pl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at unixguru.nl Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 08:21:01 -0000 On Fri, Apr 06, 2007 at 11:43:25PM +0200, Pawel Jakub Dawidek wrote: > Ok, ZFS is now in the tree, what's now? Below you'll find some > instructions how to quickly make it up and running. I got a few LOR's trying out your instructions. Apr 7 09:46:36 base kernel: lock order reversal: Apr 7 09:46:36 base kernel: 1st 0xc6f4cb20 zfs:&dr->dt.di.dr_mtx (zfs:&dr->dt.di.dr_mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1865 Apr 7 09:46:36 base kernel: 2nd 0xc5db1988 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1836 Apr 7 09:46:36 base kernel: KDB: stack backtrace: Apr 7 09:46:36 base kernel: db_trace_self_wrapper(c094b931) at db_trace_self_wrapper+0x25 Apr 7 09:46:36 base kernel: kdb_backtrace(0,ffffffff,c0a5aca8,c0a5afa0,c09f64ec,...) at kdb_backtrace+0x29 Apr 7 09:46:36 base kernel: witness_checkorder(c5db1988,9,c5672404,72c) at witness_checkorder+0x586 Apr 7 09:46:36 base kernel: _sx_xlock(c5db1988,c5672404,72c,c1474788,728,...) at _sx_xlock+0x3e Apr 7 09:46:36 base kernel: dbuf_sync_list(c6f4cb38,c72a1a00,c094ab6c,91,c5673ab1,...) at dbuf_sync_list+0x5e Apr 7 09:46:36 base kernel: dbuf_sync_list(c5df10b0,c72a1a00,e8120b84,c562a5c5,c5af4c00,...) at dbuf_sync_list+0xde Apr 7 09:46:36 base kernel: dnode_sync(c5df1000,c72a1a00,135,0,c591d800,...) at dnode_sync+0x3a8 Apr 7 09:46:36 base kernel: dmu_objset_sync(c54b1e00,c5af4c00,c72a1a00,c52db54c,c54b1200,...) at dmu_objset_sync+0xf6 Apr 7 09:46:36 base kernel: dsl_pool_sync(c52db400,135,0,c54bb000,135,...) at dsl_pool_sync+0x6d Apr 7 09:46:36 base kernel: spa_sync(c54bb000,135,0,c52db4ac,c5675b03,...) at spa_sync+0x33f Apr 7 09:46:36 base kernel: txg_sync_thread(c52db400,e8120d38) at txg_sync_thread+0x183 Apr 7 09:46:36 base kernel: fork_exit(c5645fcc,c52db400,e8120d38) at fork_exit+0xac Apr 7 09:46:36 base kernel: fork_trampoline() at fork_trampoline+0x8 Apr 7 09:46:36 base kernel: --- trap 0, eip = 0, esp = 0xe8120d70, ebp = 0 --- Apr 7 09:46:36 base kernel: lock order reversal: Apr 7 09:46:36 base kernel: 1st 0xc72897e4 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:417 Apr 7 09:46:36 base kernel: 2nd 0xc728e770 zfs:&zp->z_lock (zfs:&zp->z_lock) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:73 Apr 7 09:46:36 base kernel: KDB: stack backtrace: Apr 7 09:46:36 base kernel: db_trace_self_wrapper(c094b931) at db_trace_self_wrapper+0x25 Apr 7 09:46:36 base kernel: kdb_backtrace(0,ffffffff,c0a5afa0,c0a5ae10,c09f64ec,...) at kdb_backtrace+0x29 Apr 7 09:46:36 base kernel: witness_checkorder(c728e770,9,c5676a28,49) at witness_checkorder+0x586 Apr 7 09:46:36 base kernel: _sx_xlock(c728e770,c5676a28,49,c5672d26,e81209d8,...) at _sx_xlock+0x3e Apr 7 09:46:36 base kernel: znode_pageout_func(c72897a8,c728e760,c72897a8,e8120a04,c5621a59,...) at znode_pageout_func+0x1f Apr 7 09:46:36 base kernel: dbuf_evict_user(c5db1690,c72897a8,0,c7283c60,e8120a14,...) at dbuf_evict_user+0x31 Apr 7 09:46:36 base kernel: dbuf_clear(c72897a8,0,e8120ad4,c5630f11,c72897a8,...) at dbuf_clear+0x1d Apr 7 09:46:36 base kernel: dbuf_evict(c72897a8,c72897e4,c5672d26,1a1,c7283c48,...) at dbuf_evict+0xd Apr 7 09:46:36 base kernel: dnode_evict_dbufs(c7283ae0,0,255,14,0,...) at dnode_evict_dbufs+0x1fd Apr 7 09:46:36 base kernel: dnode_sync(c7283ae0,c72a1a00,c54b1eb8,c7283ae0,10,...) at dnode_sync+0x257 Apr 7 09:46:36 base kernel: dmu_objset_sync_dnodes(c5df1000,c72a1a00,135,0,c591d800,...) at dmu_objset_sync_dnodes+0x29 Apr 7 09:46:36 base kernel: dmu_objset_sync(c54b1e00,c5af4c00,c72a1a00,c52db54c,c54b1200,...) at dmu_objset_sync+0x112 Apr 7 09:46:36 base kernel: dsl_pool_sync(c52db400,135,0,c54bb000,135,...) at dsl_pool_sync+0x6d Apr 7 09:46:36 base kernel: spa_sync(c54bb000,135,0,c52db4ac,c5675b03,...) at spa_sync+0x33f Apr 7 09:46:36 base kernel: txg_sync_thread(c52db400,e8120d38) at txg_sync_thread+0x183 Apr 7 09:46:36 base kernel: fork_exit(c5645fcc,c52db400,e8120d38) at fork_exit+0xac Apr 7 09:46:36 base kernel: fork_trampoline() at fork_trampoline+0x8 Apr 7 09:46:36 base kernel: --- trap 0, eip = 0, esp = 0xe8120d70, ebp = 0 --- Btw... ZFS is very very cool! :) If i could run vmware-server and ZFS on freebsd, i would be a very happy customer :) -- Regards, Richard. From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 08:44:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8883B16A403 for ; Sat, 7 Apr 2007 08:44:10 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 40A9A13C484 for ; Sat, 7 Apr 2007 08:44:10 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:59401 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.63) (envelope-from ) id 1Ha6Wn-0000i8-6e for freebsd-current@freebsd.org; Sat, 07 Apr 2007 10:44:09 +0200 Received: (qmail 11885 invoked from network); 7 Apr 2007 10:44:06 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 7 Apr 2007 10:44:06 +0200 Received: (qmail 87699 invoked by uid 1001); 7 Apr 2007 10:44:06 +0200 Date: Sat, 7 Apr 2007 10:44:06 +0200 From: Erik Trulsson To: Nikolas Britton Message-ID: <20070407084406.GA87662@owl.midgard.homeip.net> Mail-Followup-To: Nikolas Britton , Peter Jeremy , FreeBSD Current References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405180711.GA60539@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1Ha6Wn-0000i8-6e. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Ha6Wn-0000i8-6e 6e0b104363a5c4703ebe14a58e63321e Cc: Peter Jeremy , FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 08:44:10 -0000 On Fri, Apr 06, 2007 at 08:40:11AM -0500, Nikolas Britton wrote: > On 4/5/07, Erik Trulsson wrote: > >> > >> 98.83% of us have at least a i686 and 62.6% of us have at least a i786 > >> (SSE2) processor. > > > >And 73.45% of all statistics are mainly made up of hot air. > > > ... > > > >What makes you think those stats are even half-way accurate or > >useful. It is probably a highly biased sample. > > > > I don't appreciate being called a lier. Maybe you should step up to > the plate if you don't believe my statistics. [snip lots of unintersting numbers] > Data source: http://www.bsdstats.org/cpus.php I have no doubt that bsdstats.org reports those numbers. I do doubt that they accurately reflect reality. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 08:49:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A3516A403 for ; Sat, 7 Apr 2007 08:49:56 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id AFB0713C455 for ; Sat, 7 Apr 2007 08:49:51 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:55723 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.63) (envelope-from ) id 1Ha6cI-0003Px-8A for freebsd-current@freebsd.org; Sat, 07 Apr 2007 10:49:50 +0200 Received: (qmail 11904 invoked from network); 7 Apr 2007 10:49:48 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 7 Apr 2007 10:49:48 +0200 Received: (qmail 87717 invoked by uid 1001); 7 Apr 2007 10:49:48 +0200 Date: Sat, 7 Apr 2007 10:49:48 +0200 From: Erik Trulsson To: Nikolas Britton Message-ID: <20070407084948.GB87662@owl.midgard.homeip.net> Mail-Followup-To: Nikolas Britton , Julian Elischer , FreeBSD Current , Ed Schouten References: <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1Ha6cI-0003Px-8A. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Ha6cI-0003Px-8A 50a547b83bc3249864e12b8771c18522 Cc: FreeBSD Current , Julian Elischer , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 08:49:56 -0000 On Fri, Apr 06, 2007 at 03:23:14PM -0500, Nikolas Britton wrote: > On 4/6/07, Julian Elischer wrote: > > > >I think some of the frustration people have shown with you is because > >you don't seem to appreciate how much this issue is constantly thought > >about and how the current state is not just an "accident of history". > > > >We have a LOT of old systems running around the world. > > > > But the old systems don't need the latest and greatest copy of > FreeBSD! This is why we provide errata / security fixes. The systems > are a static non moving target ??? But we want the new features and bug fixes for the old systems too! The ability to take the latest FreeBSD release and install it on an older system is a feature, not a bug. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 09:35:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62E7D16A402 for ; Sat, 7 Apr 2007 09:35:28 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.freebsd.org (Postfix) with ESMTP id 4491213C459 for ; Sat, 7 Apr 2007 09:35:28 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id C6A2C4D353; Sat, 7 Apr 2007 09:11:36 +0000 (GMT) Received: from [192.168.0.7] (ppp157-158.static.internode.on.net [150.101.157.158]) by p4.roq.com (Postfix) with ESMTP id 7A133505E8; Sat, 7 Apr 2007 08:49:33 +0000 (GMT) Message-ID: <461759D6.3000407@thebeastie.org> Date: Sat, 07 Apr 2007 18:44:06 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.7) Gecko/20061027 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Nikolas Britton References: <86zm5nrllc.fsf@dwp.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: FreeBSD Current Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 09:35:28 -0000 Nikolas Britton wrote: > On 4/5/07, Dag-Erling Smørgrav wrote: >> "Nikolas Britton" writes: >> > Can anything in the list below be removed from CURRENT? >> >> No. Modern i386 and amd64 still have an ISA bus, and devices >> connected to that bus, even if they don't have ISA slots. >> > > What you speak of is the LPC bus. LPC is intended to be a > motherboard-only bus. No connector is defined, and no LPC peripheral > daughterboards are available. > > So I come back to the question of why we have external devices from > 1987 still floating around in the kernel and more importantly why > these devices are enabled by default in the GENERIC kern conf? > > http://www.intel.com/design/chipsets/industry/25128901.pdf I tend to agree with you Nikolas, This kind of discussion has come up in the past and what makes it a bit more interesting is we again see posts from people proudly saying they are running up to 40 486's and Pentium 1's, last time this type of discussion came up some one told me they were running over 50 pentium 1 servers of services (not mini routers etc). This is at the time when global warming/energy reduction is in a media frenzy spotlight on a almost now permanent basis, this also includes technology like virtualization. Why these machines can't be placed onto a single modern core 2 server under virtualization like jails is beyond me. This also reminds me of when a gentlemen from Nvidia posted ideas for the FreeBSD kernel so that they could better support their chipsets on FreeBSD, some mailing list users blasted him. That said everyones entitled to their opinion but you can't argue with majority of the posts that are against your ideas, as they tend to control FreeBSD's direction and for the most part I tend to believe they know whats best then I do. I choose to view FreeBSD as a OS that is out to try please everyone, even if it does provide a larger amount of convenience to those with a 486 then a Core 2 CPU thats what its about. Weather it could work better the other way around is something I don't know, forcing people to recompile bits back into the kernel for their PC-98/486 might work or it might force a new fork of FreeBSD. I think it's reasonable to think that there can be a mix up in users belief on what FreeBSD is about and where it's focus is on, for example the "about" part of FreeBSD's web site tends to be worded on a more modern advanced focused OS ( http://www.freebsd.org/about.html ) but at the same time it does list PC-98. Mike From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 10:40:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2241316A405 for ; Sat, 7 Apr 2007 10:40:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE61613C469 for ; Sat, 7 Apr 2007 10:40:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7074C46DA0; Sat, 7 Apr 2007 06:40:21 -0400 (EDT) Date: Sat, 7 Apr 2007 06:40:21 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86ps6h8as6.fsf@dwp.des.no> Message-ID: <20070407063804.H30801@fledge.watson.org> References: <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <86ps6h8as6.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1987776983-1175942421=:30801" Cc: Ed Schouten , FreeBSD Current , Nikolas Britton , Julian Elischer Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 10:40:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1987776983-1175942421=:30801 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 6 Apr 2007, Dag-Erling Sm=F8rgrav wrote: > "Nikolas Britton" writes: >> Julian Elischer writes: >>> We have a LOT of old systems running around the world. >> But the old systems don't need the latest and greatest copy of >> FreeBSD! This is why we provide errata / security fixes. The systems >> are a static non moving target ??? > > Excuse me? Who's "we"? > > Julian, Warner, Scott, Bernd, Giorgios, Wilko, myself and many others who= =20 > have contradicted you in this discussion are veteran FreeBSD developers w= ith=20 > something like a hundred years of industry experience between us. > > You, on the other hand are just a pathetic little fuck who has repeatedly= =20 > demonstrated his complete lack of understanding of anything remotely=20 > approaching real computers, real software and real life. > > You do not get to tell us how to run our project. > > You do not get to say "we". Guys, This is getting out of hand. It's clear that people can and will be runnin= g=20 FreeBSD on older hardware for a long time to come, and that we can accept o= r=20 disregard this advice -- or even find a middle ground, like determining=20 whether shipping additional kernel configurations would help -- without=20 turning this into a flame war. Robert N M Watson Computer Laboratory University of Cambridge --0-1987776983-1175942421=:30801-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 11:05:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F133416A404; Sat, 7 Apr 2007 11:05:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id C7D9513C44B; Sat, 7 Apr 2007 11:05:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2007 03:36:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l37AaX3j006475; Sat, 7 Apr 2007 03:36:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l37AaXMF029645; Sat, 7 Apr 2007 10:36:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 03:36:32 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 03:36:32 -0700 Message-ID: <461774DA.2080200@cisco.com> Date: Sat, 07 Apr 2007 06:39:22 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2007 10:36:32.0397 (UTC) FILETIME=[9BC94BD0:01C77900] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1645; t=1175942193; x=1176806193; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20ZFS=20committed=20to=20the=20FreeBSD=20base. |Sender:=20; bh=19aOC538v0T9mqP/lKDRAFjUdIHBnIxhK4cHgyEaLFQ=; b=b7FrIrp3vI6SK8LmXnblprv+A7Z8DEEGrpWqlQK1uRfEYQ3JM4fxvl7lWIrA9+hazaeJ4D/g Xv2BW6L8ngYlRyCawiDiGOs1aAyZUZOXdk/KoToTOqDhtidATX7TbdKw; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 11:05:04 -0000 Great work Pawel... I see you posted a quick start ... I will have to move my laptop to use this as its non-root fs's :-D R Pawel Jakub Dawidek wrote: > Hi. > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. > > Commit log: > > Please welcome ZFS - The last word in file systems. > > ZFS file system was ported from OpenSolaris operating system. The code > in under CDDL license. > > I'd like to thank all SUN developers that created this great piece of > software. > > Supported by: Wheel LTD (http://www.wheel.pl/) > Supported by: The FreeBSD Foundation (http://www.freebsdfoundation.org/) > Supported by: Sentex (http://www.sentex.net/) > > Limitations. > > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. > > Missing functionality. > > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > iSCSI is also not supported at this point. This should be fixed in > the future, we may also add support for sharing ZVOLs over ggate. > - There is no support for ACLs and extended attributes. > - There is no support for booting off of ZFS file system. > > Other than that, ZFS should be fully-functional. > > Enjoy! > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 11:18:50 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6886C16A401 for ; Sat, 7 Apr 2007 11:18:50 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 11CE513C448 for ; Sat, 7 Apr 2007 11:18:49 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l37BIm8p009501; Sat, 7 Apr 2007 13:18:48 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l37BId9f089464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 13:18:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l37BIcTf016477; Sat, 7 Apr 2007 13:18:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l37BIbsP016476; Sat, 7 Apr 2007 13:18:37 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 13:18:37 +0200 From: Bernd Walter To: Michael Vince Message-ID: <20070407111836.GF8831@cicely12.cicely.de> References: <86zm5nrllc.fsf@dwp.des.no> <461759D6.3000407@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461759D6.3000407@thebeastie.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: FreeBSD Current , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 11:18:50 -0000 On Sat, Apr 07, 2007 at 06:44:06PM +1000, Michael Vince wrote: > > This kind of discussion has come up in the past and what makes it a bit > more interesting is we again see posts from people proudly saying they > are running up to 40 486's and Pentium 1's, last time this type of > discussion came up some one told me they were running over 50 pentium 1 > servers of services (not mini routers etc). > > This is at the time when global warming/energy reduction is in a media > frenzy spotlight on a almost now permanent basis, this also includes > technology like virtualization. Why these machines can't be placed onto > a single modern core 2 server under virtualization like jails is beyond me. > This also reminds me of when a gentlemen from Nvidia posted ideas for > the FreeBSD kernel so that they could better support their chipsets on > FreeBSD, some mailing list users blasted him. Jail doesn't bring enough isolation you need in many cases. While it is true that a modern big host has more cycles per Watt it is also often true that an old P1 server grade hardware use less power than a modern server grade hardware and unless you need that power of a modern system the P1 is quite sufficient. Also a modern 486 like a soekris 4501 only consumes 3-5W and if it is fast enough it is choosen for exactly the reason of power consumption. The price for the hardware is not lower - it is the bill running the hardware over a few years in service, which makes such a 486 system attractive. And yes - I'm proud to run low power hosts where they fit for the service. And note that we are already talking about a power consumption capable for solar powered systems running FreeBSD. Things will likely change over to even less power consuming ARM systems, but there are still purposes I still buy 486 boards and the 486 will stay as long as they are fast enough for the service they should do. They are physically distributed, so virtual hosts are not an option. It is not that I couldn't run FreeBSD for that service when 486 would be dropped, but the total cost is much higher because of additional power costs. Also the write of cycles of IT hardware vs. industrial are different. You may talk about hardware in the industrial class filling rooms that includes a host with special cards. You can't swap the system for decades, but still want to have it's software rising with newer requirements. You still need ISA for modern systems, but you also need ISA for special hardware which requires keeping old systems online. It doesn't even have to be bad for power consumption, since e.g. many of the old systems changed from HDD to flash storage over the years. > Weather it could work better the other way around is something I don't > know, forcing people to recompile bits back into the kernel for their > PC-98/486 might work or it might force a new fork of FreeBSD. We have to recompile the kernel anyway to remove SMP, reduce memory footprint, etc..., but there is a chance to run a GENERIC kernel for the first start. And more importent in the embedded world it is often quite handy to have packages, because of long compile times - we can't quickly recompile everything as on fast systems, but we also need security updates and new features. I never use packages on beafy systems, but I use them on slow ones. > I think it's reasonable to think that there can be a mix up in users > belief on what FreeBSD is about and where it's focus is on, for example > the "about" part of FreeBSD's web site tends to be worded on a more > modern advanced focused OS ( http://www.freebsd.org/about.html ) but at > the same time it does list PC-98. Things don't dissagree. It is still that there is not so much win for beafy systems when dropping support for legacy and there is quite a large number of users with that hardware. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 11:26:17 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4356416A401; Sat, 7 Apr 2007 11:26:17 +0000 (UTC) (envelope-from jorn@wcborstel.com) Received: from mail.wcborstel.com (www.wcborstel.com [82.93.93.17]) by mx1.freebsd.org (Postfix) with ESMTP id BACB313C43E; Sat, 7 Apr 2007 11:26:16 +0000 (UTC) (envelope-from jorn@wcborstel.com) Received: from mail.wcborstel.com (localhost [10.0.0.2]) by mail.wcborstel.com (Postfix) with ESMTP id 84119434379; Sat, 7 Apr 2007 12:55:09 +0200 (CEST) Received: by mail.wcborstel.com (Postfix, from userid 58) id E7CC0434374; Sat, 7 Apr 2007 12:55:08 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail.wcborstel.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, DK_POLICY_SIGNSOME,HTML_MESSAGE,SARE_SUB_OBFU_OTHER autolearn=ham version=3.1.8 X-Spam-Report: * 0.1 SARE_SUB_OBFU_OTHER FVGT - subject contains odd letter combinations * 0.0 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails * -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [192.168.1.6] (unknown [192.168.1.6]) by mail.wcborstel.com (Postfix) with ESMTP id 0843B434327; Sat, 7 Apr 2007 12:55:02 +0200 (CEST) Message-ID: <46177881.3090509@wcborstel.com> Date: Sat, 07 Apr 2007 12:54:57 +0200 From: Jorn Argelo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 11:26:17 -0000 Rich Teer wrote: >> I'm happy to inform that the ZFS file system is now part of the FreeBSD >> operating system. ZFS is available in the HEAD branch and will be >> available in FreeBSD 7.0-RELEASE as an experimental feature. >> > > This is fantastic news! At the risk of raking over ye olde arguments, > as the old saying goes: "Dual licensing? We don't need no stinkeen > dual licensing!". :-) > > First of all, thanks a lot for all the hard work of both the FreeBSD developers as the ZFS developers. I can't wait to give it a go. That leads me to one question though: Why is *BSD able to bring it into the OS as where Linux has licensing problems with the CDDL? AFAIK Linux users can only run it in userland mode and not in kernel mode because of the licenses. I don't really know the differences between all the licenses, so feel free to correct me if I'm saying something stupid. Thanks, Jorn From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 11:27:04 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 269C616A403 for ; Sat, 7 Apr 2007 11:27:04 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id D27F013C459 for ; Sat, 7 Apr 2007 11:27:03 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so710183nza for ; Sat, 07 Apr 2007 04:27:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FJMnsd/2hB2pQo5mtAIf1SUxWPfFSoqBTG+lMS+Y4pliNIswGRAFI7k7BDbDxKPpBPCNSDYnorbpY2HGF5a+UW4rcxZmc9dfjUbdR61F5rRc0ny61J/odrYqifcdSiIfQSzNMuJoNm4M/+puU/fDt2XIlWfGn4c75VwkFVl1zXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GTW8PZqlYJAm5Dupi8/B1NyWlPVXLC1e0tKLMSI+6rL17Z9w6QOB1kpL9EZKYKyL/ACdNojbpdeJp6Mih4lJS/2Nb9iFipIw9wSgM6gFpKloK7OGEf9Zb9iaeq2CgYpTLKPY2jQnE+oacO7r47sFTqltz+WAuA2N0nLctApUBdw= Received: by 10.114.131.2 with SMTP id e2mr1579769wad.1175945222831; Sat, 07 Apr 2007 04:27:02 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Sat, 7 Apr 2007 04:27:02 -0700 (PDT) Message-ID: Date: Sat, 7 Apr 2007 15:27:02 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Robert Watson" In-Reply-To: <20070407063804.H30801@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <86ps6h8as6.fsf@dwp.des.no> <20070407063804.H30801@fledge.watson.org> X-Google-Sender-Auth: fe664b304c310216 Cc: Julian Elischer , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , FreeBSD Current , Ed Schouten , Nikolas Britton Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 11:27:04 -0000 T24gNC83LzA3LCBSb2JlcnQgV2F0c29uIDxyd2F0c29uQGZyZWVic2Qub3JnPiB3cm90ZToKPgo+ IE9uIEZyaSwgNiBBcHIgMjAwNywgRGFnLUVybGluZyBTbcO4cmdyYXYgd3JvdGU6Cj4KPiA+ICJO aWtvbGFzIEJyaXR0b24iIDxuaWtvbGFzLmJyaXR0b25AZ21haWwuY29tPiB3cml0ZXM6Cj4gPj4g SnVsaWFuIEVsaXNjaGVyIDxqdWxpYW5AZWxpc2NoZXIub3JnPiB3cml0ZXM6Cj4gPj4+IFdlIGhh dmUgYSBMT1QgIG9mIG9sZCBzeXN0ZW1zIHJ1bm5pbmcgYXJvdW5kIHRoZSB3b3JsZC4KPiA+PiBC dXQgdGhlIG9sZCBzeXN0ZW1zIGRvbid0IG5lZWQgdGhlIGxhdGVzdCBhbmQgZ3JlYXRlc3QgY29w eSBvZgo+ID4+IEZyZWVCU0QhIFRoaXMgaXMgd2h5IHdlIHByb3ZpZGUgZXJyYXRhIC8gc2VjdXJp dHkgZml4ZXMuIFRoZSBzeXN0ZW1zCj4gPj4gYXJlIGEgc3RhdGljIG5vbiBtb3ZpbmcgdGFyZ2V0 ID8/Pwo+ID4KPiA+IEV4Y3VzZSBtZT8gIFdobydzICJ3ZSI/Cj4gPgo+ID4gSnVsaWFuLCBXYXJu ZXIsIFNjb3R0LCBCZXJuZCwgR2lvcmdpb3MsIFdpbGtvLCBteXNlbGYgYW5kIG1hbnkgb3RoZXJz IHdobwo+ID4gaGF2ZSBjb250cmFkaWN0ZWQgeW91IGluIHRoaXMgZGlzY3Vzc2lvbiBhcmUgdmV0 ZXJhbiBGcmVlQlNEIGRldmVsb3BlcnMgd2l0aAo+ID4gc29tZXRoaW5nIGxpa2UgYSBodW5kcmVk IHllYXJzIG9mIGluZHVzdHJ5IGV4cGVyaWVuY2UgYmV0d2VlbiB1cy4KPiA+Cj4gPiBZb3UsIG9u IHRoZSBvdGhlciBoYW5kIGFyZSBqdXN0IGEgcGF0aGV0aWMgbGl0dGxlIGZ1Y2sgd2hvIGhhcyBy ZXBlYXRlZGx5Cj4gPiBkZW1vbnN0cmF0ZWQgaGlzIGNvbXBsZXRlIGxhY2sgb2YgdW5kZXJzdGFu ZGluZyBvZiBhbnl0aGluZyByZW1vdGVseQo+ID4gYXBwcm9hY2hpbmcgcmVhbCBjb21wdXRlcnMs IHJlYWwgc29mdHdhcmUgYW5kIHJlYWwgbGlmZS4KPiA+Cj4gPiBZb3UgZG8gbm90IGdldCB0byB0 ZWxsIHVzIGhvdyB0byBydW4gb3VyIHByb2plY3QuCj4gPgo+ID4gWW91IGRvIG5vdCBnZXQgdG8g c2F5ICJ3ZSIuCj4KPiBHdXlzLAo+Cj4gVGhpcyBpcyBnZXR0aW5nIG91dCBvZiBoYW5kLiAgSXQn cyBjbGVhciB0aGF0IHBlb3BsZSBjYW4gYW5kIHdpbGwgYmUgcnVubmluZwo+IEZyZWVCU0Qgb24g b2xkZXIgaGFyZHdhcmUgZm9yIGEgbG9uZyB0aW1lIHRvIGNvbWUsIGFuZCB0aGF0IHdlIGNhbiBh Y2NlcHQgb3IKPiBkaXNyZWdhcmQgdGhpcyBhZHZpY2UgLS0gb3IgZXZlbiBmaW5kIGEgbWlkZGxl IGdyb3VuZCwgbGlrZSBkZXRlcm1pbmluZwo+IHdoZXRoZXIgc2hpcHBpbmcgYWRkaXRpb25hbCBr ZXJuZWwgY29uZmlndXJhdGlvbnMgd291bGQgaGVscCAtLSB3aXRob3V0Cj4gdHVybmluZyB0aGlz IGludG8gYSBmbGFtZSB3YXIuCgpXaXRob3V0IHNlZWluZyBkZXMgZmx5IG9mZiB0aGUgaGFuZGxl LCByZWFkaW5nIHRoaXMKdGhyZWFkIHdvdWxkIGJlIGEgdG90YWwgd2FzdGUgb2YgdGltZSA6LSkK CkxvdmUgeSdhbGwgOikK From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 11:57:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64CFE16A402; Sat, 7 Apr 2007 11:57:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 13D3113C45D; Sat, 7 Apr 2007 11:57:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id l37Bv6j7067378; Sat, 7 Apr 2007 07:57:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l37Bv6bO007035; Sat, 7 Apr 2007 07:57:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9F11C73039; Sat, 7 Apr 2007 07:57:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070407115705.9F11C73039@freebsd-current.sentex.ca> Date: Sat, 7 Apr 2007 07:57:04 -0400 (EDT) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 11:57:07 -0000 TB --- 2007-04-07 10:55:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-04-07 10:55:59 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-04-07 10:55:59 - cleaning the object tree TB --- 2007-04-07 10:56:34 - checking out the source tree TB --- 2007-04-07 10:56:34 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-04-07 10:56:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-04-07 11:06:43 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-07 11:06:43 - cd /src TB --- 2007-04-07 11:06:43 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 7 11:06:44 UTC 2007 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] as -o boot0.5.o /src/sys/boot/pc98/boot0.5/boot0.5.s as -o disk.o /src/sys/boot/pc98/boot0.5/disk.s as -o selector.o /src/sys/boot/pc98/boot0.5/selector.s as -o support.o /src/sys/boot/pc98/boot0.5/support.s as -o syscons.o /src/sys/boot/pc98/boot0.5/syscons.s as -o putssjis.o /src/sys/boot/pc98/boot0.5/putssjis.s cc -O2 -pipe -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -N -e start -Ttext 0x0000 -Wl,-T,ldscript -nostdlib -o boot0.5.out start.o boot.o boot0.5.o disk.o selector.o support.o syscons.o putssjis.o /obj/pc98/src/tmp/usr/bin/ld: cannot open linker script file ldscript: No such file or directory *** Error code 1 Stop in /src/sys/boot/pc98/boot0.5. *** Error code 1 Stop in /src/sys/boot/pc98. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-07 11:57:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-07 11:57:04 - ERROR: failed to build world TB --- 2007-04-07 11:57:04 - tinderbox aborted TB --- 0.82 user 2.73 system 3664.69 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 12:07:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8EE616A404; Sat, 7 Apr 2007 12:07:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8542813C46E; Sat, 7 Apr 2007 12:07:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B52492091; Sat, 7 Apr 2007 14:07:47 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 9E68E2090; Sat, 7 Apr 2007 14:07:47 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 88C2FA10A5; Sat, 7 Apr 2007 14:07:47 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Andrew Pantyukhin" References: <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> <46166A5E.3090009@samsco.org> <461697C3.8000700@elischer.org> <86ps6h8as6.fsf@dwp.des.no> <20070407063804.H30801@fledge.watson.org> Date: Sat, 07 Apr 2007 14:07:47 +0200 In-Reply-To: (Andrew Pantyukhin's message of "Sat, 7 Apr 2007 15:27:02 +0400") Message-ID: <86abxk75gs.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nikolas Britton , FreeBSD Current , Robert Watson , Julian Elischer , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 12:07:51 -0000 "Andrew Pantyukhin" writes: > Without seeing des fly off the handle, reading this > thread would be a total waste of time :-) We aim to please :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 12:14:36 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF45A16A402 for ; Sat, 7 Apr 2007 12:14:36 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.freebsd.org (Postfix) with ESMTP id ACD2313C46C for ; Sat, 7 Apr 2007 12:14:36 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp6-g19.free.fr (Postfix) with ESMTP id BC4236D49B; Sat, 7 Apr 2007 14:14:35 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 2B05E1185B; Sat, 7 Apr 2007 14:14:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at xbsd.org Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAyZxSOuA5iM; Sat, 7 Apr 2007 14:14:30 +0200 (CEST) Received: from [193.120.13.130] (cream.xbsd.org [193.120.13.130]) by smtp.xbsd.org (Postfix) with ESMTP id 269A611843; Sat, 7 Apr 2007 14:14:28 +0200 (CEST) Message-ID: <46178B44.6060503@FreeBSD.org> Date: Sat, 07 Apr 2007 13:15:00 +0100 From: Florent Thoumie User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig50247EC9171212A3925FBDCB" Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 12:14:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig50247EC9171212A3925FBDCB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Hi. >=20 > I'm happy to inform that the ZFS file system is now part of the FreeBSD= > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. Thanks for working on it Pawel! We're now all waiting for 7.0-RELEASE :-) --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --------------enig50247EC9171212A3925FBDCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGF4tJMxEkbVFH3PQRCldJAJ0dkQAmZZ9fBB9SrgUmFGi+gmrH2wCffWOu UBRVKtdARyb4b74adC5VlE0= =0DSc -----END PGP SIGNATURE----- --------------enig50247EC9171212A3925FBDCB-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 13:14:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E190E16A403; Sat, 7 Apr 2007 13:14:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA7413C45D; Sat, 7 Apr 2007 13:14:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A34AB487F5; Sat, 7 Apr 2007 15:14:16 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9608A487F3; Sat, 7 Apr 2007 15:14:03 +0200 (CEST) Date: Sat, 7 Apr 2007 15:13:53 +0200 From: Pawel Jakub Dawidek To: ticso@cicely.de Message-ID: <20070407131353.GE63916@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wTWi5aaYRw9ix9vO" Content-Disposition: inline In-Reply-To: <20070407025644.GC8831@cicely12.cicely.de> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 13:14:20 -0000 --wTWi5aaYRw9ix9vO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote: > On Fri, Apr 06, 2007 at 04:57:00AM +0200, Pawel Jakub Dawidek wrote: > > Hi. > >=20 > > I'm happy to inform that the ZFS file system is now part of the FreeBSD > > operating system. ZFS is available in the HEAD branch and will be > > available in FreeBSD 7.0-RELEASE as an experimental feature. >=20 > I got a kmem panic just by copying a recent ports.tgz (36M) onto a ZFS. > My sandbox just has 128MB RAM so kmem was set to ~40M. > After raising kmem to 80M it survived copying the file, but paniced > again while tar -xvzf the file into the same pool. > vfs.zfs.vdev.cache.size is unchanged at 10M. 128MB RAM of suggested minimum in ZFS requirements, but it may be not enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever is more). Could you locate these lines in sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file: /* set min cache to 1/32 of all memory, or 64MB, whichever is more */ arc_c_min =3D MAX(arc_c / 4, 64<<20); Change 64 to eg. 32, recompile and retest? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --wTWi5aaYRw9ix9vO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGF5kRForvXbEpPzQRApydAKDjoHlw/Of6g2l+Gk3ZW20E2kZ/8QCfWLTY +RnkqsCj8HSqGt356JEAHxA= =7zTq -----END PGP SIGNATURE----- --wTWi5aaYRw9ix9vO-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 14:18:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C17F16A402 for ; Sat, 7 Apr 2007 14:18:25 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr17.xs4all.nl (smtp-vbr17.xs4all.nl [194.109.24.37]) by mx1.freebsd.org (Postfix) with ESMTP id B979F13C43E for ; Sat, 7 Apr 2007 14:18:22 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr17.xs4all.nl (8.13.8/8.13.8) with ESMTP id l37EIJ89092558; Sat, 7 Apr 2007 16:18:20 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l37EHbZH004153; Sat, 7 Apr 2007 16:17:37 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l37EHboX004152; Sat, 7 Apr 2007 16:17:37 +0200 (CEST) (envelope-from wb) Date: Sat, 7 Apr 2007 16:17:37 +0200 From: Wilko Bulte To: Jorn Argelo Message-ID: <20070407141736.GC4058@freebie.xs4all.nl> References: <20070406025700.GB98545@garage.freebsd.pl> <46177881.3090509@wcborstel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46177881.3090509@wcborstel.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 14:18:25 -0000 On Sat, Apr 07, 2007 at 12:54:57PM +0200, Jorn Argelo wrote.. > Rich Teer wrote: > >>I'm happy to inform that the ZFS file system is now part of the FreeBSD > >>operating system. ZFS is available in the HEAD branch and will be > >>available in FreeBSD 7.0-RELEASE as an experimental feature. > >> > > > >This is fantastic news! At the risk of raking over ye olde arguments, > >as the old saying goes: "Dual licensing? We don't need no stinkeen > >dual licensing!". :-) > > > > > First of all, thanks a lot for all the hard work of both the FreeBSD > developers as the ZFS developers. I can't wait to give it a go. > > That leads me to one question though: Why is *BSD able to bring it into > the OS as where Linux has licensing problems with the CDDL? AFAIK Linux > users can only run it in userland mode and not in kernel mode because of > the licenses. My guess(!) is that they do not want non-GPL-ed code in the standard kernel. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 14:26:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C635516A408 for ; Sat, 7 Apr 2007 14:26:16 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from config.solomo.org (kasimir.com [85.214.51.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1A97813C468 for ; Sat, 7 Apr 2007 14:26:15 +0000 (UTC) (envelope-from flo@kasimir.com) Received: (qmail 14308 invoked from network); 7 Apr 2007 15:59:35 +0200 Received: from i53879c69.versanet.de (HELO nibbler-osx.local) (83.135.156.105) by pflegeteam-froendenberg.de with SMTP; 7 Apr 2007 15:59:34 +0200 Message-ID: <4617A3A6.60804@kasimir.com> Date: Sat, 07 Apr 2007 15:59:02 +0200 From: "Florian C. Smeets" User-Agent: Thunderbird 2.0.0.0pre (Macintosh/20070407) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> In-Reply-To: <20070407131353.GE63916@garage.freebsd.pl> X-Enigmail-Version: 0.94.2.0 X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 14:26:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pawel Jakub Dawidek wrote: > On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote: >> My sandbox just has 128MB RAM so kmem was set to ~40M. >> After raising kmem to 80M it survived copying the file, but paniced >> again while tar -xvzf the file into the same pool. >> vfs.zfs.vdev.cache.size is unchanged at 10M. > > 128MB RAM of suggested minimum in ZFS requirements, but it may be not > enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever > is more). Could you locate these lines in > sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file: > > /* set min cache to 1/32 of all memory, or 64MB, whichever is more */ > arc_c_min = MAX(arc_c / 4, 64<<20); > > Change 64 to eg. 32, recompile and retest? > Hi Pawel, i had the same problems like Bernd while trying to copy the src tree to a ZFS volume. I have 384MB RAM but i got the same "kmem_map: too small" panic. I compiled my kernel like you proposed and now i am able to copy anything to the volume without panic :-) Regards, Florian P.S. Thanks for all the work on ZFS! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGF6OmA+1tjUZ1YScRAnSMAJ4y27u0nGu9L4RgDBclxKh5q6Z/RgCgjbi7 1Ri2CZfH8YKqj8Bdmx7bedM= =PUsh -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 16:58:16 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6802F16A401; Sat, 7 Apr 2007 16:58:16 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id CEE0113C4B0; Sat, 7 Apr 2007 16:58:15 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l37GwETj022109; Sat, 7 Apr 2007 18:58:14 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l37Gw0OR091231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 18:58:01 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l37Gw0Dd017206; Sat, 7 Apr 2007 18:58:00 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l37Gw08N017205; Sat, 7 Apr 2007 18:58:00 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 18:58:00 +0200 From: Bernd Walter To: "Florian C. Smeets" Message-ID: <20070407165759.GG8831@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4617A3A6.60804@kasimir.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 16:58:16 -0000 On Sat, Apr 07, 2007 at 03:59:02PM +0200, Florian C. Smeets wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Pawel Jakub Dawidek wrote: > > On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote: > >> My sandbox just has 128MB RAM so kmem was set to ~40M. > >> After raising kmem to 80M it survived copying the file, but paniced > >> again while tar -xvzf the file into the same pool. > >> vfs.zfs.vdev.cache.size is unchanged at 10M. > > > > 128MB RAM of suggested minimum in ZFS requirements, but it may be not > > enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever > > is more). Could you locate these lines in > > sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file: > > > > /* set min cache to 1/32 of all memory, or 64MB, whichever is more */ > > arc_c_min = MAX(arc_c / 4, 64<<20); > > > > Change 64 to eg. 32, recompile and retest? > > > > Hi Pawel, > > i had the same problems like Bernd while trying to copy the src tree to > a ZFS volume. I have 384MB RAM but i got the same "kmem_map: too small" > panic. I compiled my kernel like you proposed and now i am able to copy > anything to the volume without panic :-) I had increased RAM to 384 and still had a panic with default kmem (IIRC around 100M) and even increasing kmem to 160M did help a long time, but still produced the panic after a while. I don't think 64M applies here as the real limit. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 16:43:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8636916A404; Sat, 7 Apr 2007 16:43:45 +0000 (UTC) (envelope-from rees@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.freebsd.org (Postfix) with ESMTP id 647DA13C4BA; Sat, 7 Apr 2007 16:43:45 +0000 (UTC) (envelope-from rees@citi.umich.edu) Received: from citi.umich.edu (dsl093-001-248.det1.dsl.speakeasy.net [66.93.1.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by citi.umich.edu (Postfix) with ESMTP id 4466138DB9; Sat, 7 Apr 2007 12:10:46 -0400 (EDT) Date: Sat, 7 Apr 2007 11:10:45 -0500 From: Jim Rees To: Wilko Bulte Message-ID: <20070407161044.GA24875@citi.umich.edu> References: <20070406025700.GB98545@garage.freebsd.pl> <46177881.3090509@wcborstel.com> <20070407141736.GC4058@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407141736.GC4058@freebie.xs4all.nl> X-Mailman-Approved-At: Sat, 07 Apr 2007 17:09:21 +0000 Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, Jorn Argelo , Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 16:43:45 -0000 Wilko Bulte wrote: My guess(!) is that they do not want non-GPL-ed code in the standard kernel. Actually there is non-GPL code in linux, NFSv4 for example. Some licenses are considered "incompatible." OpenAFS falls into this category, apparently because of some problem with patents. I don't know what the situation is with CDDL. From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 17:20:20 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF96616A401 for ; Sat, 7 Apr 2007 17:20:20 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id AE66613C455 for ; Sat, 7 Apr 2007 17:20:20 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 4164 invoked from network); 7 Apr 2007 17:20:21 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 7 Apr 2007 17:20:21 -0000 Message-ID: <4617D2CE.1050502@root.org> Date: Sat, 07 Apr 2007 10:20:14 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> In-Reply-To: <86fy7nq4q1.fsf@dwp.des.no> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 17:20:21 -0000 Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Pieter de Goeje writes: >>> Dag-Erling Smørgrav writes: >>>> No. This is a violation of the FTP protocol. >>> I'm reading rfc 959 right now, and it include examples of CWD with >>> full pathname (multiple directories). Actually the rfc is kinda >>> vague about this. >> RFC959 does not require or guarantee that the path separator is /, nor >> that "CD ../foo" does what you expect. There are also issues when the >> initial CWD is not / (the document part in an FTP URL is relative to >> the initial CWD, not absolute) > > I guess I should amend "this is a violation of the FTP protocol" to > "this relies on assumptions which the FTP RFC does not allow us to > make, and is a violation of RFC1738" Obviously, it's easier to do nothing than something. So here are some options: 1. Add my patch -- if a server returns an error, I see no way it would have changed the PWD. If you say "CD GARBAGE", what reasonable system would return an error and change to some random dir? 2. Add an env variable (similar to FTP_PASSIVE_MODE, say "FTP_SINGLE_CWD") which forces the current behavior. If not set, fetch tries the multi-method first, falls back to the single-method on error. -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 17:23:57 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4961316A400 for ; Sat, 7 Apr 2007 17:23:57 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5E313C459 for ; Sat, 7 Apr 2007 17:23:56 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 5080 invoked from network); 7 Apr 2007 17:23:57 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 7 Apr 2007 17:23:57 -0000 Message-ID: <4617D3A6.8000201@root.org> Date: Sat, 07 Apr 2007 10:23:50 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: call for testers: altq in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 17:23:57 -0000 A few weeks ago, I committed a change to ALTQ that I was only able to compile-test. What I need is someone with a laptop or other cpufreq-capable system that is also using ALTQ to verify that with powerd running, the queuing timing is now reliable. Previously, altq would just cache the first value of the CPU freq it saw (based on tsc_freq) and use that forever. Now it gets updated each time the freq changes. I want to make sure the edge cases (i.e., freq changes while a packet is being timed) work ok. Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 17:45:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DBF816A403; Sat, 7 Apr 2007 17:45:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 022EE13C468; Sat, 7 Apr 2007 17:45:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.15.55] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HaEz216wn-00041r; Sat, 07 Apr 2007 19:45:53 +0200 From: Max Laier Organization: FreeBSD To: Nate Lawson Date: Sat, 7 Apr 2007 18:45:44 +0100 User-Agent: KMail/1.9.5 References: <4617D3A6.8000201@root.org> In-Reply-To: <4617D3A6.8000201@root.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1565023.8ZCeSOeJC0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704071945.51273.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/1YiwzCRzP+ZrVGiJsPrszH9lpFNABSPhr8kV 0O+RyL5r32AMydwgk4FDSVikuIS8x3KPreJr91Mxx5QXm44oui 0ldj46Y7HJSC/isqGPE2A== Cc: freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: call for testers: altq in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 17:45:55 -0000 --nextPart1565023.8ZCeSOeJC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 07 April 2007 19:23, Nate Lawson wrote: > A few weeks ago, I committed a change to ALTQ that I was only able to > compile-test. What I need is someone with a laptop or other > cpufreq-capable system that is also using ALTQ to verify that with > powerd running, the queuing timing is now reliable. > > Previously, altq would just cache the first value of the CPU freq it > saw (based on tsc_freq) and use that forever. Now it gets updated each > time the freq changes. I want to make sure the edge cases (i.e., freq > changes while a packet is being timed) work ok. I will try to give it a spin over the long weekend. Other testers please=20 note that you should test this without ALTQ_NOPCC. Looking at the patch=20 now, it seems that the eventhandler should take this into account, too. =20 i.e. when ALTQ_NOPCC is defined we emulate a 256Mhz clock with=20 microtime - this shouldn't be dependent on the real cpu frequency=20 (eventhough things will get strange when the clockspeed drops below=20 256Mhz). Sorry for not paying attention when you posted the patch. CC'ing freebsd-pf@ ... laptop anyone? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1565023.8ZCeSOeJC0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGF9jPXyyEoT62BG0RAnBVAJ9KQwEuN07YBg5Y7SrNE4vNRXInawCdGRvw 5vPp/cN26WMz2BSlk9qJx7g= =amR7 -----END PGP SIGNATURE----- --nextPart1565023.8ZCeSOeJC0-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 18:03:30 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E210416A400; Sat, 7 Apr 2007 18:03:30 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 711D113C483; Sat, 7 Apr 2007 18:03:30 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l37I3T2x025775; Sat, 7 Apr 2007 20:03:29 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l37I3K96091603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 20:03:20 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l37I3JlT017380; Sat, 7 Apr 2007 20:03:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l37I3J7r017379; Sat, 7 Apr 2007 20:03:19 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 20:03:19 +0200 From: Bernd Walter To: "Florian C. Smeets" Message-ID: <20070407180319.GH8831@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407165759.GG8831@cicely12.cicely.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 18:03:31 -0000 On Sat, Apr 07, 2007 at 06:58:00PM +0200, Bernd Walter wrote: > On Sat, Apr 07, 2007 at 03:59:02PM +0200, Florian C. Smeets wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Pawel Jakub Dawidek wrote: > > > On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote: > > >> My sandbox just has 128MB RAM so kmem was set to ~40M. > > >> After raising kmem to 80M it survived copying the file, but paniced > > >> again while tar -xvzf the file into the same pool. > > >> vfs.zfs.vdev.cache.size is unchanged at 10M. > > > > > > 128MB RAM of suggested minimum in ZFS requirements, but it may be not > > > enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever > > > is more). Could you locate these lines in > > > sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file: > > > > > > /* set min cache to 1/32 of all memory, or 64MB, whichever is more */ > > > arc_c_min = MAX(arc_c / 4, 64<<20); > > > > > > Change 64 to eg. 32, recompile and retest? > > > > > > > Hi Pawel, > > > > i had the same problems like Bernd while trying to copy the src tree to > > a ZFS volume. I have 384MB RAM but i got the same "kmem_map: too small" > > panic. I compiled my kernel like you proposed and now i am able to copy > > anything to the volume without panic :-) > > I had increased RAM to 384 and still had a panic with default kmem > (IIRC around 100M) and even increasing kmem to 160M did help a long > time, but still produced the panic after a while. > I don't think 64M applies here as the real limit. Now with 240M kmem it looks good, but I'm still unshure: kstat.zfs.misc.arcstats.c_min: 67108864 kstat.zfs.misc.arcstats.c_max: 188743680 kstat.zfs.misc.arcstats.size: 87653376 c_max seemed to be increasing with kmem, but I did compare it with a remebered value. Should be good with: vm.kmem_size: 251658240 But top shows wired memory which is roughly twice the size of arcstats.size, so I'm still worried about kmem exhaustion if ARC runs up to c_max. Since the c_min/c_max values also influence the available RAM for other purposes as well, can we have it at least a loader.conf tuneable? Otherwise - the reboot after the panics where impressive. No long fsck times or noticed data corruption - even with NFS clients. All in all it is a great job. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 18:33:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00E7116A404 for ; Sat, 7 Apr 2007 18:33:26 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BD9FF13C48C for ; Sat, 7 Apr 2007 18:33:23 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 17578 invoked from network); 7 Apr 2007 18:33:24 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 7 Apr 2007 18:33:24 -0000 Message-ID: <4617E3ED.9090400@root.org> Date: Sat, 07 Apr 2007 11:33:17 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Max Laier References: <4617D3A6.8000201@root.org> <200704071945.51273.max@love2party.net> In-Reply-To: <200704071945.51273.max@love2party.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: call for testers: altq in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 18:33:26 -0000 Max Laier wrote: > On Saturday 07 April 2007 19:23, Nate Lawson wrote: >> A few weeks ago, I committed a change to ALTQ that I was only able to >> compile-test. What I need is someone with a laptop or other >> cpufreq-capable system that is also using ALTQ to verify that with >> powerd running, the queuing timing is now reliable. >> >> Previously, altq would just cache the first value of the CPU freq it >> saw (based on tsc_freq) and use that forever. Now it gets updated each >> time the freq changes. I want to make sure the edge cases (i.e., freq >> changes while a packet is being timed) work ok. > > I will try to give it a spin over the long weekend. Other testers please > note that you should test this without ALTQ_NOPCC. Looking at the patch > now, it seems that the eventhandler should take this into account, too. > i.e. when ALTQ_NOPCC is defined we emulate a 256Mhz clock with > microtime - this shouldn't be dependent on the real cpu frequency > (eventhough things will get strange when the clockspeed drops below > 256Mhz). Sorry for not paying attention when you posted the patch. > > CC'ing freebsd-pf@ ... laptop anyone? Thanks Max. Yes, the microtime clock will be mostly unaffected by the CPU frequency. However, we may need to look into that case. -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 19:14:30 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B4E616A404 for ; Sat, 7 Apr 2007 19:14:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6E413C484 for ; Sat, 7 Apr 2007 19:14:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 999C020B4; Sat, 7 Apr 2007 21:14:26 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8B33B2090; Sat, 7 Apr 2007 21:14:26 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 5DA13A10A5; Sat, 7 Apr 2007 21:14:26 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Nate Lawson References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> Date: Sat, 07 Apr 2007 21:14:26 +0200 In-Reply-To: <4617D2CE.1050502@root.org> (Nate Lawson's message of "Sat, 07 Apr 2007 10:20:14 -0700") Message-ID: <86ps6g5759.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 19:14:30 -0000 Nate Lawson writes: > Obviously, it's easier to do nothing than something. So here are some > options: > > 1. Add my patch -- if a server returns an error, I see no way it would > have changed the PWD. If you say "CD GARBAGE", what reasonable system > would return an error and change to some random dir? > > 2. Add an env variable (similar to FTP_PASSIVE_MODE, say > "FTP_SINGLE_CWD") which forces the current behavior. If not set, fetch > tries the multi-method first, falls back to the single-method on error. No. Thanks, DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 19:15:41 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7B2816A403; Sat, 7 Apr 2007 19:15:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 55D9A13C465; Sat, 7 Apr 2007 19:15:39 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3CE32487FB; Sat, 7 Apr 2007 21:15:38 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4009C487FA; Sat, 7 Apr 2007 21:15:27 +0200 (CEST) Date: Sat, 7 Apr 2007 21:15:17 +0200 From: Pawel Jakub Dawidek To: ticso@cicely.de Message-ID: <20070407191517.GN63916@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mr2ctTDD1GjnQwB" Content-Disposition: inline In-Reply-To: <20070407180319.GH8831@cicely12.cicely.de> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 19:15:41 -0000 --+mr2ctTDD1GjnQwB Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2007 at 08:03:19PM +0200, Bernd Walter wrote: > Now with 240M kmem it looks good, but I'm still unshure: > kstat.zfs.misc.arcstats.c_min: 67108864 > kstat.zfs.misc.arcstats.c_max: 188743680 > kstat.zfs.misc.arcstats.size: 87653376 > c_max seemed to be increasing with kmem, but I did compare it with a > remebered value. > Should be good with: > vm.kmem_size: 251658240 > But top shows wired memory which is roughly twice the size of > arcstats.size, so I'm still worried about kmem exhaustion if ARC runs > up to c_max. > Since the c_min/c_max values also influence the available RAM for other > purposes as well, can we have it at least a loader.conf tuneable? Just committed a change. You can tune max and min ARC size via vfs.zfs.arc_max and vfs.zfs.arc_min tunnables. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+mr2ctTDD1GjnQwB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGF+3FForvXbEpPzQRAo+mAKDGkO29Uzx3IFYyw4WJm1qYt0k/ngCfRXGd XGFVMfBNn2yp0nCxRtTbGV4= =XtYK -----END PGP SIGNATURE----- --+mr2ctTDD1GjnQwB-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 19:20:35 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43B7E16A400; Sat, 7 Apr 2007 19:20:35 +0000 (UTC) (envelope-from jorn@wcborstel.com) Received: from mail.wcborstel.com (www.wcborstel.com [82.93.93.17]) by mx1.freebsd.org (Postfix) with ESMTP id EE7E813C43E; Sat, 7 Apr 2007 19:20:34 +0000 (UTC) (envelope-from jorn@wcborstel.com) Received: from mail.wcborstel.com (localhost [10.0.0.2]) by mail.wcborstel.com (Postfix) with ESMTP id 86053434379; Sat, 7 Apr 2007 21:20:40 +0200 (CEST) Received: by mail.wcborstel.com (Postfix, from userid 58) id 3B041434374; Sat, 7 Apr 2007 21:20:40 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail.wcborstel.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, DK_POLICY_SIGNSOME,SARE_SUB_OBFU_OTHER autolearn=ham version=3.1.8 X-Spam-Report: * 0.1 SARE_SUB_OBFU_OTHER FVGT - subject contains odd letter combinations * 0.0 DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails * -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP Received: from [192.168.1.6] (unknown [192.168.1.6]) by mail.wcborstel.com (Postfix) with ESMTP id 96791434327; Sat, 7 Apr 2007 21:20:36 +0200 (CEST) Message-ID: <4617EF00.7010403@wcborstel.com> Date: Sat, 07 Apr 2007 21:20:32 +0200 From: Jorn Argelo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406214325.GB61039@garage.freebsd.pl> In-Reply-To: <20070406214325.GB61039@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 19:20:35 -0000 Pawel Jakub Dawidek wrote: > Ok, ZFS is now in the tree, what's now? Below you'll find some > instructions how to quickly make it up and running. > > Thanks for this Pawel. I have a machine with an external storage array running gvinum on 6.1-RELEASE. Do you think I can use ZFS to replace gvinum once 7.0 has been released? The box is fairly important, but ZFS has been out in the wild for a while so I have confidence in that. Or do you think I should not use it for production purposes yet? Thanks, Jorn From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 19:44:03 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC98016A404; Sat, 7 Apr 2007 19:44:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6824613C4BF; Sat, 7 Apr 2007 19:44:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C13F42091; Sat, 7 Apr 2007 21:43:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 46E7A2090; Sat, 7 Apr 2007 21:43:59 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 37651A10A5; Sat, 7 Apr 2007 21:43:59 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> Date: Sat, 07 Apr 2007 21:43:59 +0200 In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri, 6 Apr 2007 04:57:00 +0200") Message-ID: <86k5wo55s0.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 19:44:03 -0000 Pawel Jakub Dawidek writes: > Limitations. > > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. ZFS is now also available on pc98 and amd64. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 19:47:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D01216A400 for ; Sat, 7 Apr 2007 19:47:54 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BB5EB13C45B for ; Sat, 7 Apr 2007 19:47:53 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27656 invoked from network); 7 Apr 2007 19:47:54 -0000 Received: from ppp-71-139-28-99.dsl.snfc21.pacbell.net (HELO ?10.0.0.235?) (nate-mail@71.139.28.99) by root.org with ESMTPA; 7 Apr 2007 19:47:54 -0000 Message-ID: <4617F563.40502@root.org> Date: Sat, 07 Apr 2007 12:47:47 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> <86ps6g5759.fsf@dwp.des.no> In-Reply-To: <86ps6g5759.fsf@dwp.des.no> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 19:47:54 -0000 Dag-Erling Smørgrav wrote: > Nate Lawson writes: >> Obviously, it's easier to do nothing than something. So here are some >> options: >> >> 1. Add my patch -- if a server returns an error, I see no way it would >> have changed the PWD. If you say "CD GARBAGE", what reasonable system >> would return an error and change to some random dir? >> >> 2. Add an env variable (similar to FTP_PASSIVE_MODE, say >> "FTP_SINGLE_CWD") which forces the current behavior. If not set, fetch >> tries the multi-method first, falls back to the single-method on error. > > No. > > Thanks, > > DES I forgot: 3. #ifdef (on or off by default) Also, can I hear from anyone else besides Mr. No? Thanks, -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:00:23 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD72416A407; Sat, 7 Apr 2007 20:00:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5F32C13C48A; Sat, 7 Apr 2007 20:00:22 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id ADFA4487F4; Sat, 7 Apr 2007 22:00:21 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F197345685; Sat, 7 Apr 2007 22:00:11 +0200 (CEST) Date: Sat, 7 Apr 2007 22:00:00 +0200 From: Pawel Jakub Dawidek To: Jorn Argelo Message-ID: <20070407200000.GO63916@garage.freebsd.pl> References: <20070406214325.GB61039@garage.freebsd.pl> <4617EF00.7010403@wcborstel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m46qSNjkc66Ye11q" Content-Disposition: inline In-Reply-To: <4617EF00.7010403@wcborstel.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:00:23 -0000 --m46qSNjkc66Ye11q Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2007 at 09:20:32PM +0200, Jorn Argelo wrote: > Pawel Jakub Dawidek wrote: > >Ok, ZFS is now in the tree, what's now? Below you'll find some > >instructions how to quickly make it up and running. > > > > =20 > Thanks for this Pawel. >=20 > I have a machine with an external storage array running gvinum on 6.1-REL= EASE. Do you think I can use ZFS to replace gvinum once 7.0 has been releas= ed? The box is fairly=20 > important, but ZFS has been out in the wild for a while so I have confide= nce in that. Or do you think I should not use it for production purposes ye= t? It is stable for me, which doesn't mean it is stable. As I said it will be marked as experimental feature for 7.0-RELEASE, so if something break all bets are off. The best you can do it to test it now for your workload and decide based on results. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --m46qSNjkc66Ye11q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGF/hAForvXbEpPzQRAlpKAJsHY0QXU0d1n1yGj4uwcEPG1WDUEACeNOdZ 9IA1iV/2g2AWwWXFjaUUwrw= =6a6Q -----END PGP SIGNATURE----- --m46qSNjkc66Ye11q-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:04:24 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3DA416A400 for ; Sat, 7 Apr 2007 20:04:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 24E0B13C4BD for ; Sat, 7 Apr 2007 20:04:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3682F487F4; Sat, 7 Apr 2007 22:04:22 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A442D45685; Sat, 7 Apr 2007 22:04:07 +0200 (CEST) Date: Sat, 7 Apr 2007 22:03:56 +0200 From: Pawel Jakub Dawidek To: Richard Arends Message-ID: <20070407200356.GP63916@garage.freebsd.pl> References: <20070406214325.GB61039@garage.freebsd.pl> <20070407075435.GP20680@sun.unixguru.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EkxpYdHiqGHPYbUt" Content-Disposition: inline In-Reply-To: <20070407075435.GP20680@sun.unixguru.nl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:04:24 -0000 --EkxpYdHiqGHPYbUt Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2007 at 09:54:35AM +0200, Richard Arends wrote: > On Fri, Apr 06, 2007 at 11:43:25PM +0200, Pawel Jakub Dawidek wrote: >=20 > > Ok, ZFS is now in the tree, what's now? Below you'll find some > > instructions how to quickly make it up and running. >=20 > I got a few LOR's trying out your instructions. >=20 > Apr 7 09:46:36 base kernel: lock order reversal: > Apr 7 09:46:36 base kernel: 1st 0xc6f4cb20 zfs:&dr->dt.di.dr_mtx (zfs:&d= r->dt.di.dr_mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/c= ommon/fs/zfs/dbuf.c:1865 > Apr 7 09:46:36 base kernel: 2nd 0xc5db1988 zfs:&db->db_mtx (zfs:&db->db_= mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs= /dbuf.c:1836 > Apr 7 09:46:36 base kernel: KDB: stack backtrace: > Apr 7 09:46:36 base kernel: db_trace_self_wrapper(c094b931) at db_trace_= self_wrapper+0x25 > Apr 7 09:46:36 base kernel: kdb_backtrace(0,ffffffff,c0a5aca8,c0a5afa0,c= 09f64ec,...) at kdb_backtrace+0x29 > Apr 7 09:46:36 base kernel: witness_checkorder(c5db1988,9,c5672404,72c) = at witness_checkorder+0x586 > Apr 7 09:46:36 base kernel: _sx_xlock(c5db1988,c5672404,72c,c1474788,728= ,...) at _sx_xlock+0x3e > Apr 7 09:46:36 base kernel: dbuf_sync_list(c6f4cb38,c72a1a00,c094ab6c,91= ,c5673ab1,...) at dbuf_sync_list+0x5e > Apr 7 09:46:36 base kernel: dbuf_sync_list(c5df10b0,c72a1a00,e8120b84,c5= 62a5c5,c5af4c00,...) at dbuf_sync_list+0xde > Apr 7 09:46:36 base kernel: dnode_sync(c5df1000,c72a1a00,135,0,c591d800,= =2E..) at dnode_sync+0x3a8 > Apr 7 09:46:36 base kernel: dmu_objset_sync(c54b1e00,c5af4c00,c72a1a00,c= 52db54c,c54b1200,...) at dmu_objset_sync+0xf6 > Apr 7 09:46:36 base kernel: dsl_pool_sync(c52db400,135,0,c54bb000,135,..= =2E) at dsl_pool_sync+0x6d > Apr 7 09:46:36 base kernel: spa_sync(c54bb000,135,0,c52db4ac,c5675b03,..= =2E) at spa_sync+0x33f > Apr 7 09:46:36 base kernel: txg_sync_thread(c52db400,e8120d38) at txg_sy= nc_thread+0x183 > Apr 7 09:46:36 base kernel: fork_exit(c5645fcc,c52db400,e8120d38) at for= k_exit+0xac > Apr 7 09:46:36 base kernel: fork_trampoline() at fork_trampoline+0x8 > Apr 7 09:46:36 base kernel: --- trap 0, eip =3D 0, esp =3D 0xe8120d70, e= bp =3D 0 --- > Apr 7 09:46:36 base kernel: lock order reversal: > Apr 7 09:46:36 base kernel: 1st 0xc72897e4 zfs:&db->db_mtx (zfs:&db->db_= mtx) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs= /dnode_sync.c:417 > Apr 7 09:46:36 base kernel: 2nd 0xc728e770 zfs:&zp->z_lock (zfs:&zp->z_l= ock) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs= /zfs_znode.c:73 > Apr 7 09:46:36 base kernel: KDB: stack backtrace: > Apr 7 09:46:36 base kernel: db_trace_self_wrapper(c094b931) at db_trace_= self_wrapper+0x25 > Apr 7 09:46:36 base kernel: kdb_backtrace(0,ffffffff,c0a5afa0,c0a5ae10,c= 09f64ec,...) at kdb_backtrace+0x29 > Apr 7 09:46:36 base kernel: witness_checkorder(c728e770,9,c5676a28,49) a= t witness_checkorder+0x586 > Apr 7 09:46:36 base kernel: _sx_xlock(c728e770,c5676a28,49,c5672d26,e812= 09d8,...) at _sx_xlock+0x3e > Apr 7 09:46:36 base kernel: znode_pageout_func(c72897a8,c728e760,c72897a= 8,e8120a04,c5621a59,...) at znode_pageout_func+0x1f > Apr 7 09:46:36 base kernel: dbuf_evict_user(c5db1690,c72897a8,0,c7283c60= ,e8120a14,...) at dbuf_evict_user+0x31 > Apr 7 09:46:36 base kernel: dbuf_clear(c72897a8,0,e8120ad4,c5630f11,c728= 97a8,...) at dbuf_clear+0x1d > Apr 7 09:46:36 base kernel: dbuf_evict(c72897a8,c72897e4,c5672d26,1a1,c7= 283c48,...) at dbuf_evict+0xd > Apr 7 09:46:36 base kernel: dnode_evict_dbufs(c7283ae0,0,255,14,0,...) a= t dnode_evict_dbufs+0x1fd > Apr 7 09:46:36 base kernel: dnode_sync(c7283ae0,c72a1a00,c54b1eb8,c7283a= e0,10,...) at dnode_sync+0x257 > Apr 7 09:46:36 base kernel: dmu_objset_sync_dnodes(c5df1000,c72a1a00,135= ,0,c591d800,...) at dmu_objset_sync_dnodes+0x29 > Apr 7 09:46:36 base kernel: dmu_objset_sync(c54b1e00,c5af4c00,c72a1a00,c= 52db54c,c54b1200,...) at dmu_objset_sync+0x112 > Apr 7 09:46:36 base kernel: dsl_pool_sync(c52db400,135,0,c54bb000,135,..= =2E) at dsl_pool_sync+0x6d > Apr 7 09:46:36 base kernel: spa_sync(c54bb000,135,0,c52db4ac,c5675b03,..= =2E) at spa_sync+0x33f > Apr 7 09:46:36 base kernel: txg_sync_thread(c52db400,e8120d38) at txg_sy= nc_thread+0x183 > Apr 7 09:46:36 base kernel: fork_exit(c5645fcc,c52db400,e8120d38) at for= k_exit+0xac > Apr 7 09:46:36 base kernel: fork_trampoline() at fork_trampoline+0x8 > Apr 7 09:46:36 base kernel: --- trap 0, eip =3D 0, esp =3D 0xe8120d70, e= bp =3D 0 --- I think I saw them both. One is already documented at: http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=3D//depot/user/pjd/zfs/L= OR&REV=3D1 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EkxpYdHiqGHPYbUt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGF/ksForvXbEpPzQRAoqDAKCUGVhaJggSu90oufC/DSTihDAs/wCg1sWh 1gXZF9x/Gvomdi+4tPoWwSU= =12t8 -----END PGP SIGNATURE----- --EkxpYdHiqGHPYbUt-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:21:09 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4917316A401; Sat, 7 Apr 2007 20:21:09 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from mx1.unixguru.nl (mx1.unixguru.nl [84.16.238.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0911013C448; Sat, 7 Apr 2007 20:21:08 +0000 (UTC) (envelope-from richard@unixguru.nl) Received: from localhost (localhost [127.0.0.1]) by mx1.unixguru.nl (Postfix) with ESMTP id 9EBD13F8C; Sat, 7 Apr 2007 22:21:01 +0200 (CEST) Received: from mx1.unixguru.nl ([84.16.238.226]) by localhost (vs8616 [84.16.238.226]) (amavisd-new, port 10024) with ESMTP id 17103-09; Sat, 7 Apr 2007 22:21:00 +0200 (CEST) Received: from mail.unixguru.nl (cc1029189-b.emmen1.dr.home.nl [212.120.92.81]) by mx1.unixguru.nl (Postfix) with ESMTP id CAAE23F8A; Sat, 7 Apr 2007 22:21:00 +0200 (CEST) Received: from localhost (sun.unixguru.nl [192.168.10.7]) by mail.unixguru.nl (Postfix) with ESMTP id 8F9D156470; Sat, 7 Apr 2007 22:21:00 +0200 (CEST) Date: Sat, 7 Apr 2007 22:21:00 +0200 From: Richard Arends To: Pawel Jakub Dawidek Message-ID: <20070407202100.GQ20680@sun.unixguru.nl> References: <20070406214325.GB61039@garage.freebsd.pl> <20070407075435.GP20680@sun.unixguru.nl> <20070407200356.GP63916@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407200356.GP63916@garage.freebsd.pl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at unixguru.nl Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:21:09 -0000 On Sat, Apr 07, 2007 at 10:03:56PM +0200, Pawel Jakub Dawidek wrote: > I think I saw them both. One is already documented at: > > http://perforce.freebsd.org/fileDownLoad.cgi?FSPC=//depot/user/pjd/zfs/LOR&REV=1 Okay, thanks! -- Regards, Richard. From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:24:59 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 252E916A400 for ; Sat, 7 Apr 2007 20:24:59 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id D797D13C45A for ; Sat, 7 Apr 2007 20:24:58 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so771947nza for ; Sat, 07 Apr 2007 13:24:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mD0VMPoEAbZxiNMFUxdjSB50fa1EMQwwjIpS3plDGRB4IwgxsoewdwTm4Dade+LkVLhVfnDZyQiw7b3+bgEKCogFcz/7W07iQAb9xr9TF5PiGCllFT5kF4UTrY++3++PCJ26kWqHwiKpZfOd0oXHRncAT4Tb9ksxjvHv5JjGA2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LowHTxUgrusZQYswuG+HOrFdP5XsZ4JeA+enYEAn2M6kDi63nlv5GJjGskvV1bVX83yHBa84IaS/J2B0k98S+HNZUtbMLdIqryQ6xUUysQ3QjFgbQM78QJ09Si4Z4Pj79UhTgV4ZSmbN+OzCNRelYMEBSxDbR9S6VglVMtEOJQg= Received: by 10.114.159.1 with SMTP id h1mr1692844wae.1175975843421; Sat, 07 Apr 2007 12:57:23 -0700 (PDT) Received: by 10.114.157.6 with HTTP; Sat, 7 Apr 2007 12:57:23 -0700 (PDT) Message-ID: Date: Sat, 7 Apr 2007 21:57:23 +0200 From: "Juraj Lutter" To: "Nate Lawson" In-Reply-To: <4617F563.40502@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> <86ps6g5759.fsf@dwp.des.no> <4617F563.40502@root.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:24:59 -0000 On 4/7/07, Nate Lawson wrote: > Also, can I hear from anyone else besides Mr. No? Yes, go for it. otis, sk.FreeBSD.org -- Sincerely yours, Juraj Lutter From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:34:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 109B316A401; Sat, 7 Apr 2007 20:34:24 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 928D213C44C; Sat, 7 Apr 2007 20:34:23 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l37KYK7n032871; Sat, 7 Apr 2007 22:34:20 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l37KYD1E092494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 22:34:13 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l37KYCJp017712; Sat, 7 Apr 2007 22:34:12 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l37KYCDA017711; Sat, 7 Apr 2007 22:34:12 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 22:34:12 +0200 From: Bernd Walter To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070407203411.GJ8831@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86k5wo55s0.fsf@dwp.des.no> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:34:24 -0000 On Sat, Apr 07, 2007 at 09:43:59PM +0200, Dag-Erling Smørgrav wrote: > Pawel Jakub Dawidek writes: > > Limitations. > > > > Currently ZFS is only compiled as kernel module and is only available > > for i386 architecture. Amd64 should be available very soon, the other > > archs will come later, as we implement needed atomic operations. > > ZFS is now also available on pc98 and amd64. Great to read - is it just atomic.S missing for the remaining architectures? -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 20:42:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAE3916A400 for ; Sat, 7 Apr 2007 20:42:22 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id A70A613C457 for ; Sat, 7 Apr 2007 20:42:22 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l37KgM1s002830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 7 Apr 2007 13:42:22 -0700 X-Auth-Received: from [192.168.10.45] (c-24-7-142-221.hsd1.ca.comcast.net [24.7.142.221]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l37KgLKe025802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 7 Apr 2007 13:42:21 -0700 Message-ID: <46180221.2040408@u.washington.edu> Date: Sat, 07 Apr 2007 13:42:09 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070405.135306.78791677.imp@bsdimp.com> <46173DCF.1040200@u.washington.edu> <20070407065408.GA15430@dmr.ath.cx> <461740A0.2090707@u.washington.edu> <9a5639cae2aebcfd1d6ecc8ab8f81883.e9b02141@Nemertea> In-Reply-To: <9a5639cae2aebcfd1d6ecc8ab8f81883.e9b02141@Nemertea> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.7.133252 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 20:42:22 -0000 moanga@gmail.com wrote: > On Fri, Apr 06, 2007 at 11:56:32PM -0700, Garrett Cooper wrote: > >> Emil Mikulic wrote: >> >>> On Fri, Apr 06, 2007 at 11:44:31PM -0700, Garrett Cooper wrote: >>> >>>> Furthermore keep in mind, while we run excellent machines in this >>>> section of the world I've heard of other people running much older, >>>> lower class machines (Romania / Czechoslovakia for instance) in internet >>>> cafes, and they think that their PCs are the best things since sliced >>>> bread, even though they just run Win 3.11. >>>> >>> Dude, Czechoslovakia hasn't been a country since 1993. ;) >>> >>> And from talking with a buddy of mine who lives in the Czech Republic, >>> they have a lot more internets over there than we have here in >>> Australia. =( >>> >>> --Emil >>> >> Sorry -- meant Bosnia / Romania. You're right :P. >> > > Your geek's imagine of a poor & backward country > - people using Win 3.11 on old PCs - is obscenely hilarious. > That's what I heard from a coworker who has a friend over in Romania, that runs an internet cafe. So, my sources could be totally off. The thing is though, is that regardless of the place there _are_ some sections of the world where people are using ancient machines, so we shouldn't strip their capability to run something on their hardware if it's the only thing they have to work with. > Actually, from the tiny minority that cares about computers here, 99% won't > give a rat's about for hardware not able to run XP. And I haven't > seen a Win 3.11 system since I was in high-school (12 years ago). > I realize that. The company that I worked for in IT drops machines that are less than their 2.8 GHz P4 Northwood boxes. However, people will run XP on crappy machines and complain about how slow everything is because their machines are 7-8 years old. That's another topic though for another thread (maybe).. > And even for XP-able hardware, if it's not the newest and greatest, they > would rather buy another newer computer, since it's cheaper than paying > someone to reinstall the system or de-virus it ;-) > > Just days ago, I've saved from the scrapyard a Dell with 256 MB RIMM memory, > 800 GHz Pentium III and 15GB disk - all with very a quiet fans & builtin > audio, vga and ethernet, and it works like a charm not only with FreeBSD > and Linux, but also with the latest Solaris Nevada. > > It's actually the other way around - a German or Japanese engineer > will have to deal with a lot more of legacy hardware than a Romanian one - > since they've deployed a lot of real-life systems > (not just PCs for Excel secretaries :) during the '80 and '90 - > which are still working just fine, and people are conceivably hostile > to the idea of spending money to replace them with the latest crap. > And who's making generalizations now? I know a lot of Japanese companies that run up to date Lenovos and Apples, at least. However, many of my Japanese friends don't have up to date laptops (8-9 years old). Why? Culture uses cell phones and other mediums for communication than PCs. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 21:16:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEFAD16A403; Sat, 7 Apr 2007 21:16:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6C06013C457; Sat, 7 Apr 2007 21:16:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8EEAD20C6; Sat, 7 Apr 2007 23:16:13 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7AED320BE; Sat, 7 Apr 2007 23:16:13 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 004F4A10A5; Sat, 7 Apr 2007 23:16:12 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: ticso@cicely.de References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> Date: Sat, 07 Apr 2007 23:16:12 +0200 In-Reply-To: <20070407203411.GJ8831@cicely12.cicely.de> (Bernd Walter's message of "Sat, 7 Apr 2007 22:34:12 +0200") Message-ID: <86wt0n3mxv.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 21:16:17 -0000 Bernd Walter writes: > On Sat, Apr 07, 2007 at 09:43:59PM +0200, Dag-Erling Sm=F8rgrav wrote: > > ZFS is now also available on pc98 and amd64. > Great to read - is it just atomic.S missing for the remaining > architectures? Yes. Ideally, ZFS would use FreeBSD's atomic operations instead of its own. I believe that the reason it doesn't is (at least in part) that we don't have 64-bit atomic operations for i386. I have unfinished patches for cleaning up the atomic operations on all platforms; I'll dust them off and see what I can do. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 21:20:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01B5E16A402 for ; Sat, 7 Apr 2007 21:20:08 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id A8E3F13C455 for ; Sat, 7 Apr 2007 21:20:05 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so655535pyh for ; Sat, 07 Apr 2007 14:20:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hlk31uvEKpkusYU1BUDw9BEvydhNbn84SrZx5fqCjdP8MO6AEcYsBdwCbSwO3q+aD9NN0c8PVm0ieqyAVw2pmKqnw4qUqcPtcUxjxzeBjSld2xZfghK/nTAsVCBkdl07xKEaT8GgH7jooTfiH6UiM+J+7R+94Ob3xNgxL4nZDVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JlJZ6mtDn6ZaIXfUv5vj6RUxGLkN75Xbe3fNsOFfuXAKRSkRk6AbrF+/YQzG38+vyjW5c36XYklw6LLAmi0MAAtfHbB9MxePVtywaBL4jgQc58L2rOBH/MdLPG52GdI08rnpfcVPW+ROdzsIqeK45K3tlieBg9+LwpChQUTozYE= Received: by 10.65.151.6 with SMTP id d6mr8670574qbo.1175979336216; Sat, 07 Apr 2007 13:55:36 -0700 (PDT) Received: from ?192.168.1.72? ( [70.234.111.73]) by mx.google.com with ESMTP id c12sm21229107nzc.2007.04.07.13.55.34; Sat, 07 Apr 2007 13:55:35 -0700 (PDT) Message-ID: <46180569.4060402@gmail.com> Date: Sat, 07 Apr 2007 15:56:09 -0500 From: Harrison Grundy User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Nate Lawson References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> <86ps6g5759.fsf@dwp.des.no> <4617F563.40502@root.org> In-Reply-To: <4617F563.40502@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 21:20:08 -0000 Nate Lawson wrote: > Dag-Erling Smørgrav wrote: > >> Nate Lawson writes: >> >>> Obviously, it's easier to do nothing than something. So here are some >>> options: >>> >>> 1. Add my patch -- if a server returns an error, I see no way it would >>> have changed the PWD. If you say "CD GARBAGE", what reasonable system >>> would return an error and change to some random dir? >>> >>> 2. Add an env variable (similar to FTP_PASSIVE_MODE, say >>> "FTP_SINGLE_CWD") which forces the current behavior. If not set, fetch >>> tries the multi-method first, falls back to the single-method on error. >>> >> No. >> >> Thanks, >> >> DES >> > > I forgot: > > 3. #ifdef (on or off by default) > > Also, can I hear from anyone else besides Mr. No? > > Thanks, > I'd be fine with this... it should be fairly easy to make sure this won't break the oddball servers. Worst case, you could start from scratch on a failure. (Re-initialize the connection and all...) This certainly makes a difference on high latency links, or slow servers. Thanks! --- Harrison From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 21:24:29 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C621116A402; Sat, 7 Apr 2007 21:24:29 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 396EA13C4BB; Sat, 7 Apr 2007 21:24:28 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l37LORZX034625; Sat, 7 Apr 2007 23:24:27 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l37LOEgY092776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 23:24:15 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l37LOE1P017826; Sat, 7 Apr 2007 23:24:14 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l37LOE4U017825; Sat, 7 Apr 2007 23:24:14 +0200 (CEST) (envelope-from ticso) Date: Sat, 7 Apr 2007 23:24:14 +0200 From: Bernd Walter To: Pawel Jakub Dawidek Message-ID: <20070407212413.GK8831@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407191517.GN63916@garage.freebsd.pl> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 21:24:29 -0000 On Sat, Apr 07, 2007 at 09:15:17PM +0200, Pawel Jakub Dawidek wrote: > On Sat, Apr 07, 2007 at 08:03:19PM +0200, Bernd Walter wrote: > > Now with 240M kmem it looks good, but I'm still unshure: > > kstat.zfs.misc.arcstats.c_min: 67108864 > > kstat.zfs.misc.arcstats.c_max: 188743680 > > kstat.zfs.misc.arcstats.size: 87653376 > > c_max seemed to be increasing with kmem, but I did compare it with a > > remebered value. > > Should be good with: > > vm.kmem_size: 251658240 > > But top shows wired memory which is roughly twice the size of > > arcstats.size, so I'm still worried about kmem exhaustion if ARC runs > > up to c_max. > > Since the c_min/c_max values also influence the available RAM for other > > purposes as well, can we have it at least a loader.conf tuneable? > > Just committed a change. You can tune max and min ARC size via > vfs.zfs.arc_max and vfs.zfs.arc_min tunnables. Thanks - I'd set c_max to 80M now and will see what happens, since I had such a panic again with 240M kmem. I'm a bit confused about the calculation as such. Lets asume a 4G i386 system. arg_c = 512M c_min = 512M c_max = 3G But isn't this KVA space, of which we usually can't have 3G on i386 without limiting userland to 1G? Even 512M KVA sounds very much on a i386, since 4G systems usually have more use for limited KVA. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 22:08:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 760F416A405 for ; Sat, 7 Apr 2007 22:08:47 +0000 (UTC) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.freebsd.org (Postfix) with ESMTP id DC9C513C44B for ; Sat, 7 Apr 2007 22:08:46 +0000 (UTC) (envelope-from vkushnir@i.kiev.ua) Received: from h9.244.159.dialup.iptcom.net ([213.159.244.9]:29438 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1221994AbXDGVzv (INRCPT ); Sun, 8 Apr 2007 00:55:51 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [192.168.0.10]) by kushnir1.kiev.ua (8.13.8/8.13.8) with ESMTP id l37LtnES063086 for ; Sun, 8 Apr 2007 00:55:49 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Sun, 8 Apr 2007 00:55:49 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: freebsd-current@freebsd.org Message-ID: <20070407223046.T7086@kushnir1.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Something's wrong with ld-elf.so.1 when SYMVER_ENABLED=true X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 22:08:47 -0000 Hi, Here's description. It's amd64-CURRENT. World was rebuilt last night (with SYMVER_ENABLED=true set in /etc/make.conf long ago). After re-installation, sudenly everything's falling on its face with segfaults, with "pam_rootok.so not found", with "Can't allocate initial thread" and so on. After ld-elf.so.1 and ld-elf32.so.1 were replaced with old ones (from Jan 27 :-() everything went and still goes on with no problems. Indeed, as simple listing (and strings) show, in new (installed => stripped) ld-elf.so.1 (180 kB) vs old ld-elf.so.1.old (224 kB) lots of symbols (like _DYNAMIC or .rtld_start, for one) are just absent. Regards, Vladimir From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 22:14:21 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28F0A16A401 for ; Sat, 7 Apr 2007 22:14:21 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id DD5DE13C469 for ; Sat, 7 Apr 2007 22:14:18 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 11F182091; Sun, 8 Apr 2007 00:14:15 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 88A202090; Sun, 8 Apr 2007 00:14:14 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 6A349A1089; Sun, 8 Apr 2007 00:14:14 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Nate Lawson References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> <86ps6g5759.fsf@dwp.des.no> <4617F563.40502@root.org> Date: Sun, 08 Apr 2007 00:14:13 +0200 In-Reply-To: <4617F563.40502@root.org> (Nate Lawson's message of "Sat, 07 Apr 2007 12:47:47 -0700") Message-ID: <86slbb6de2.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 22:14:21 -0000 Nate Lawson writes: > Also, can I hear from anyone else besides Mr. No? Mr No happens to be the author and maintainer of libfetch, and happens to think that what you propose adds unnecessary complexity to fairly critical code, for no perceivable benefit. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Apr 7 22:55:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58B5E16A400 for ; Sat, 7 Apr 2007 22:55:57 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1529D13C43E for ; Sat, 7 Apr 2007 22:55:56 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1091675wxc for ; Sat, 07 Apr 2007 15:55:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=YwAaM4wvlep/32BHinf6PrUfQ6F3lctmO0ZkszbpN4RnzKsYQmwUCFA0X3n3ClgUnPwxJ86TZ00G8g4PDFFiQBT0IAcSDMf3bgXaH7XpKXefiwSa1a69xIX0J7h8bhzXzBUj6YbqI/GzKxJ/fvJt3VWCNjm8Fr7D6q03JvvVZJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=bO24U0W1jALVL0PJycYle7BmUAvl++amgVGtMsxwy97UXBEMl4omDl1iQEGud52rj/V0egL4TXtOXn/kwSCER9OBcfnmM5o66KlczAok5sMZA5m7E5MiEN0ouis/vLZ5YF3vmHyrA3g2z4W8mxkscAUUJW2weuYX2cfpkFNMNS0= Received: by 10.70.87.9 with SMTP id k9mr7816217wxb.1175984927608; Sat, 07 Apr 2007 15:28:47 -0700 (PDT) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id i34sm7804498wxd.2007.04.07.15.28.46; Sat, 07 Apr 2007 15:28:46 -0700 (PDT) Date: Sat, 7 Apr 2007 18:28:42 -0400 From: Alexander Kabaev To: Vladimir Kushnir Message-ID: <20070407182842.28f7d9e9@kan.dnsalias.net> In-Reply-To: <20070407223046.T7086@kushnir1.kiev.ua> References: <20070407223046.T7086@kushnir1.kiev.ua> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_NKuDo2Eh9BS_H5gvbdxIHw.; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: Something's wrong with ld-elf.so.1 when SYMVER_ENABLED=true X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2007 22:55:57 -0000 --Sig_NKuDo2Eh9BS_H5gvbdxIHw. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 8 Apr 2007 00:55:49 +0300 (EEST) Vladimir Kushnir wrote: > Hi, > Here's description. It's amd64-CURRENT. World was rebuilt last night > (with SYMVER_ENABLED=3Dtrue set in /etc/make.conf long ago). After=20 > re-installation, sudenly everything's falling on its face with > segfaults, with "pam_rootok.so not found", with "Can't allocate > initial thread" and so on. After ld-elf.so.1 and ld-elf32.so.1 were > replaced with old ones (from Jan 27 :-() everything went and still > goes on with no problems. >=20 > Indeed, as simple listing (and strings) show, in new (installed =3D>=20 > stripped) ld-elf.so.1 (180 kB) vs old ld-elf.so.1.old (224 kB) lots > of symbols (like _DYNAMIC or .rtld_start, for one) are just absent. >=20 > Regards, > Vladimir >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" SYMVER_ENABLED is an experimental feature. I suspect the new code in rtld somehow prevents it from overriding dummy symbols in libc. SYMVER_ENABLED changes in rtld are work in progress and until they are finalized, you are on your own. --=20 Alexander Kabaev P.S. "Missing" symbols in rtld are intentional as all not important symbols are not being suppressed by the symbol map file. --Sig_NKuDo2Eh9BS_H5gvbdxIHw. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGBsaQ6z1jMm+XZYRAvsdAJ0QZk23UBnQ+BByta7/muYoJ7tbIwCdGHDi zs1TLPcwBT3h33P08x0ZJ3s= =KVDl -----END PGP SIGNATURE----- --Sig_NKuDo2Eh9BS_H5gvbdxIHw.--