From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 01:51:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8561616A469; Sun, 9 Sep 2007 01:51:29 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 680D913C467; Sun, 9 Sep 2007 01:51:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46E3519E.3040001@FreeBSD.org> Date: Sun, 09 Sep 2007 03:51:26 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Peter Schuller References: <855622.76488.qm@web36601.mail.mud.yahoo.com> <20070908215102.GA8291@hyperion.scode.org> In-Reply-To: <20070908215102.GA8291@hyperion.scode.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simun Mikecin , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 01:51:29 -0000 Peter Schuller wrote: >> Try one of this (depends wheter you need encrypted swap or not): >> >> 1. create zvol with 4k blocksize instead of default 8k: >> zfs create -b 4k -V 4g tank/swap >> swapon /dev/zvol/tank/swap > > Using a 4k blocksize did not seem to have an effect on the problem. > > The test I am doing is with top in one virtual console and the test > program on another. I keep refreshing top seeing memory use climb, > until it starts hitting swap. After a few seconds, top hangs and the > only indications of life are ping and the console. > Please follow the directions in the developers handbook chapter on kernel debugging to obtain the relevant debugging information. Kris From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 03:11:43 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203CC16A41A; Sun, 9 Sep 2007 03:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id CF38313C45D; Sun, 9 Sep 2007 03:11:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l893BgRb004528; Sat, 8 Sep 2007 23:11:42 -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.14.1/8.14.1) with ESMTP id l893BgvH077741; Sat, 8 Sep 2007 23:11:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1321A73039; Sat, 8 Sep 2007 23:10:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070909031017.1321A73039@freebsd-current.sentex.ca> Date: Sat, 8 Sep 2007 23:10:16 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 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: Sun, 09 Sep 2007 03:11:43 -0000 TB --- 2007-09-09 01:39:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-09-09 01:39:43 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-09-09 01:39:43 - cleaning the object tree TB --- 2007-09-09 01:40:09 - checking out the source tree TB --- 2007-09-09 01:40:09 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-09-09 01:40:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-09-09 01:50:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-09-09 01:50:09 - cd /src TB --- 2007-09-09 01:50:09 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 9 01:50:10 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 Sep 9 03:05:20 UTC 2007 TB --- 2007-09-09 03:05:20 - generating LINT kernel config TB --- 2007-09-09 03:05:20 - cd /src/sys/pc98/conf TB --- 2007-09-09 03:05:20 - /usr/bin/make -B LINT TB --- 2007-09-09 03:05:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-09-09 03:05:20 - cd /src TB --- 2007-09-09 03:05:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 9 03:05:20 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -pg -mprofiler-epilogue /src/sys/dev/cxgb/common/cxgb_ael1002.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -pg -mprofiler-epilogue /src/sys/dev/cxgb/common/cxgb_mv88e1xxx.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -pg -mprofiler-epilogue /src/sys/dev/cxgb/common/cxgb_xgmac.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -pg -mprofiler-epilogue /src/sys/dev/cxgb/common/cxgb_t3_hw.c /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: error: expected declaration specifiers or '...' before string constant /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: data definition has no type or storage class /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: type defaults to 'int' in declaration of '_FBSDID' /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-09-09 03:10:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-09-09 03:10:16 - ERROR: failed to build lint kernel TB --- 2007-09-09 03:10:16 - tinderbox aborted TB --- 0.87 user 2.87 system 5433.65 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 04:40:41 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A41B16A417; Sun, 9 Sep 2007 04:40:41 +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 BEEB313C457; Sun, 9 Sep 2007 04:40:40 +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 l894edmu051014; Sun, 9 Sep 2007 00:40:39 -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.14.1/8.14.1) with ESMTP id l894ed51047157; Sun, 9 Sep 2007 00:40:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5222D73039; Sun, 9 Sep 2007 00:39:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070909043914.5222D73039@freebsd-current.sentex.ca> Date: Sun, 9 Sep 2007 00:39:14 -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 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, 09 Sep 2007 04:40:41 -0000 TB --- 2007-09-09 03:10:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-09-09 03:10:17 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-09-09 03:10:17 - cleaning the object tree TB --- 2007-09-09 03:10:40 - checking out the source tree TB --- 2007-09-09 03:10:40 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-09-09 03:10:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-09-09 03:18:22 - building world (CFLAGS=-O2 -pipe) TB --- 2007-09-09 03:18:22 - cd /src TB --- 2007-09-09 03:18:22 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 9 03:18:23 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 Sep 9 04:34:34 UTC 2007 TB --- 2007-09-09 04:34:34 - generating LINT kernel config TB --- 2007-09-09 04:34:34 - cd /src/sys/powerpc/conf TB --- 2007-09-09 04:34:34 - /usr/bin/make -B LINT TB --- 2007-09-09 04:34:34 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-09-09 04:34:34 - cd /src TB --- 2007-09-09 04:34:34 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 9 04:34:35 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/dev/cxgb/common/cxgb_mv88e1xxx.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/dev/cxgb/common/cxgb_xgmac.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/dev/cxgb/common/cxgb_t3_hw.c /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: error: expected declaration specifiers or '...' before string constant cc1: warnings being treated as errors /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: data definition has no type or storage class /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: type defaults to 'int' in declaration of '_FBSDID' /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-09-09 04:39:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-09-09 04:39:13 - ERROR: failed to build lint kernel TB --- 2007-09-09 04:39:13 - tinderbox aborted TB --- 0.76 user 2.43 system 5336.89 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 04:42:44 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36D9B16A417; Sun, 9 Sep 2007 04:42:43 +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 CB14A13C4A3; Sun, 9 Sep 2007 04:42:42 +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 l894ggmt051063; Sun, 9 Sep 2007 00:42:42 -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.14.1/8.14.1) with ESMTP id l894ggX7048889; Sun, 9 Sep 2007 00:42:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9FFB973039; Sun, 9 Sep 2007 00:41:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070909044117.9FFB973039@freebsd-current.sentex.ca> Date: Sun, 9 Sep 2007 00:41:17 -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 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, 09 Sep 2007 04:42:44 -0000 TB --- 2007-09-09 02:45:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-09-09 02:45:03 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-09-09 02:45:03 - cleaning the object tree TB --- 2007-09-09 02:45:37 - checking out the source tree TB --- 2007-09-09 02:45:37 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-09-09 02:45:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-09-09 02:54:08 - building world (CFLAGS=-O2 -pipe) TB --- 2007-09-09 02:54:08 - cd /src TB --- 2007-09-09 02:54:08 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 9 02:54:10 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 Sep 9 04:34:37 UTC 2007 TB --- 2007-09-09 04:34:37 - generating LINT kernel config TB --- 2007-09-09 04:34:37 - cd /src/sys/ia64/conf TB --- 2007-09-09 04:34:37 - /usr/bin/make -B LINT TB --- 2007-09-09 04:34:37 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-09-09 04:34:37 - cd /src TB --- 2007-09-09 04:34:37 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Sep 9 04:34:37 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/common/cxgb_mv88e1xxx.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/common/cxgb_xgmac.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/common/cxgb_t3_hw.c /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: error: expected declaration specifiers or '...' before string constant cc1: warnings being treated as errors /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: data definition has no type or storage class /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: type defaults to 'int' in declaration of '_FBSDID' /src/sys/dev/cxgb/common/cxgb_t3_hw.c:31: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-09-09 04:41:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-09-09 04:41:17 - ERROR: failed to build lint kernel TB --- 2007-09-09 04:41:17 - tinderbox aborted TB --- 0.84 user 2.68 system 6974.49 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 07:56:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D21F916A46C for ; Sun, 9 Sep 2007 07:56:30 +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 7C7E313C45B for ; Sun, 9 Sep 2007 07:56:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DF19245E97; Sun, 9 Sep 2007 09:56:27 +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 028A945685; Sun, 9 Sep 2007 09:56:16 +0200 (CEST) Date: Sun, 9 Sep 2007 09:54:42 +0200 From: Pawel Jakub Dawidek To: Peter Schuller Message-ID: <20070909075442.GB2341@garage.freebsd.pl> References: <200709081717.05006.peter.schuller@infidyne.com> <20070908170810.GA90578@hyperion.scode.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <20070908170810.GA90578@hyperion.scode.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 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, RCVD_IN_SORBS_WEB autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 07:56:30 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 08, 2007 at 07:08:10PM +0200, Peter Schuller wrote: > > I'll see if I can confirm behavior on a more recent CURRENT. The above = was on=20 > > CURRENT:s from 1-2 months ago in both cases. >=20 > Confirmed on CURRENT cvsup:ed today (2007-09-08). However, the speed > at which swap was filling was much faster - on par with swap on > non-ZFS. But the machine still effectively froze, save the > console/ping, after a few seconds. >=20 > Also, I forgot to say this is all on amd64 machines. This is a known issue also in OpenSolaris. ZFS needs to allocate memory to send I/O request, and when there is no memory, it can't allocate it thus can't swap a process out and free it. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG46bCForvXbEpPzQRArw3AJwNW4IDZasvMoFpime3i/twa0yH7wCg7sHO 1xR8gnDVZluYTSxMDPy1JuI= =UAGK -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 09:58:04 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 165AA16A418 for ; Sun, 9 Sep 2007 09:58:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9994013C45D for ; Sun, 9 Sep 2007 09:58:03 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l899w1Lj088422 for ; Sun, 9 Sep 2007 13:58:01 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sun, 9 Sep 2007 13:58:01 +0400 (MSD) From: Dmitry Morozovsky To: current@freebsd.org In-Reply-To: <20070907192152.V98273@woozle.rinet.ru> Message-ID: <20070909135036.X86138@woozle.rinet.ru> References: <20070907192152.V98273@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sun, 09 Sep 2007 13:58:01 +0400 (MSD) Cc: Subject: Re: Possible 7.0 showstopper: SATA/eSATA are unable to init hot-plugs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 09:58:04 -0000 On Fri, 7 Sep 2007, Dmitry Morozovsky wrote: DM> on most (possibly all, but I'm not fully sure and a bit limited in testing) DM> motherboard/controller configuration I've tested so far -current is unable to DM> properly attach hot-plugged disks. Sometimes even atacontrol detach/atacontrol DM> attach sequence can't bring disk into working state (only reboot does). DM> Another one (i386 on ASUS M2N-LR/SATA): atapci2: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xefbbc000-0xefbbcfff irq 20 at device 5.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata5: on atapci2 ata5: [ITHREAD] # # ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached ad10: 381554MB at ata5-master SATA150 ad10: detached Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x5d891cf0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc049e2b1 stack pointer = 0x28:0xe507dc90 frame pointer = 0x28:0xe507dcac 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 = 2 (g_event) [thread pid 2 tid 100011 ] Stopped at g_wither_washer+0x61: movl 0x4(%eax),%ebx db> bt Tracing pid 2 tid 100011 td 0xc64c0cc0 g_wither_washer(c06ce06c,c066c481,c680f658,0,ffffffff,...) at g_wither_washer+0x61 g_run_events(c06ce180,0,4c,c0669d05,64,...) at g_run_events+0x428 g_event_procbody(0,e507dd38,0,0,0,...) at g_event_procbody+0x69 fork_exit(c049a750,0,e507dd38) at fork_exit+0x97 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe507dd70, ebp = 0 --- db> Effect is not 100% reproducible; I think there are some races in SATA init code... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 10:00:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4583116A47C; Sun, 9 Sep 2007 10:00:45 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0015213C483; Sun, 9 Sep 2007 10:00:43 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 8F4DB23C474; Sun, 9 Sep 2007 12:00:42 +0200 (CEST) Date: Sun, 9 Sep 2007 12:00:42 +0200 From: Peter Schuller To: Kris Kennaway Message-ID: <20070909100041.GA60318@hyperion.scode.org> References: <855622.76488.qm@web36601.mail.mud.yahoo.com> <20070908215102.GA8291@hyperion.scode.org> <46E3519E.3040001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <46E3519E.3040001@FreeBSD.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Simun Mikecin , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 10:00:45 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [kris] > Please follow the directions in the developers handbook chapter on kernel= =20 > debugging to obtain the relevant debugging information. Apologies. Aside from the first instance, where the machine had sat there for 12+ hours, I never got any panic message or anything like that which gives an opportunity for a stacktrace, etc. [pjd] > This is a known issue also in OpenSolaris. ZFS needs to allocate memory > to send I/O request, and when there is no memory, it can't allocate it > thus can't swap a process out and free it. Ok, so a known issue. Unless someone tells me otherwise I'll update the ZFS-on-FreeBSD Wiki pages to warn about this issue (assuming it's editable by me). Thank you, --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG48RJDNor2+l1i30RAu0YAKC7zHGvcHL5iwVpma0xhrraqwl8mACfTuTB oeB8gVcSyZEUlqAXxe8poYI= =jI+K -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 11:10:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E72A916A469 for ; Sun, 9 Sep 2007 11:10:31 +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 7FAA113C468 for ; Sun, 9 Sep 2007 11:10:30 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id A466FEB496C for ; Sun, 9 Sep 2007 14:10:08 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 43CD9158828 for ; Sun, 9 Sep 2007 14:10:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q315Rpk0phLN for ; Sun, 9 Sep 2007 14:10:08 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 1AA1715880B for ; Sun, 9 Sep 2007 14:10:08 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 5E1438FF18; Sun, 9 Sep 2007 14:10:06 +0300 (EEST) Date: Sun, 9 Sep 2007 14:10:06 +0300 From: Marinos Ilias To: freebsd-current@freebsd.org Message-ID: <20070909111006.GA5499@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: Re: SATA DMA errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 11:10:32 -0000 Hello Andrew, When I had the problem , about 3 days ago , I've boot an older current , fscked the (very) corrupted file systems and then I 've built the latest current , which I have about 3 or 4 days now.It seemed to work well without any problems with my SATA disks , but there wasn't any heavy I/O to the disks to let me know. Today , I 've tried to concatenate 2 dvd images , about 2 G each and I saw again those READ_DMA errors for my SATA disk, hearing it spinning, and my whole system stuck .Now again , the same scenario , I've boot my old working current (and I won't try any heavy I/O at all :-P ) . Is something new commited and breaks SATA? For my system ( dmesg | grep -i sata ) : atapci0: port 0xdf00-0xdf3f,0xdfa0-0xdfaf,0xd880-0xd8ff mem 0xfeafe000-0xfeafefff,0xfeac0000-0xfeadffff irq 23 at device 4.0 on pci3 atapci2: port 0xefe0-0xefe7,0xefac-0xefaf,0xefa0-0xefa7,0xefa8-0xefab,0xef60-0xef6f irq 18 at device 31.2 on pci0 ad10: 76293MB at ata5-master SATA150 ad12: 76319MB at ata6-master SATA150 atapci0: port 0xdf00-0xdf3f,0xdfa0-0xdfaf,0xd880-0xd8ff mem 0xfeafe000-0xfeafefff,0xfeac0000-0xfeadffff irq 23 at device 4.0 on pci3 atapci2: port 0xefe0-0xefe7,0xefac-0xefaf,0xefa0-0xefa7,0xefa8-0xefab,0xef60-0xef6f irq 18 at device 31.2 on pci0 ad10: 76293MB at ata5-master SATA150 ad12: 76319MB at ata6-master SATA150 atapci0: port 0xdf00-0xdf3f,0xdfa0-0xdfaf,0xd880-0xd8ff mem 0xfeafe000-0xfeafefff,0xfeac0000-0xfeadffff irq 23 at device 4.0 on pci3 atapci2: port 0xefe0-0xefe7,0xefac-0xefaf,0xefa0-0xefa7,0xefa8-0xefab,0xef60-0xef6f irq 18 at device 31.2 on pci0 ad10: 76293MB at ata5-master SATA150 ad12: 76319MB at ata6-master SATA150 Thank you From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 11:12:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE42316A418; Sun, 9 Sep 2007 11:12:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id BC1F613C45E; Sun, 9 Sep 2007 11:12:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46E3D51E.3020504@FreeBSD.org> Date: Sun, 09 Sep 2007 13:12:30 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Peter Schuller References: <855622.76488.qm@web36601.mail.mud.yahoo.com> <20070908215102.GA8291@hyperion.scode.org> <46E3519E.3040001@FreeBSD.org> <20070909100041.GA60318@hyperion.scode.org> In-Reply-To: <20070909100041.GA60318@hyperion.scode.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simun Mikecin , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 11:12:32 -0000 Peter Schuller wrote: > [kris] >> Please follow the directions in the developers handbook chapter on kernel >> debugging to obtain the relevant debugging information. > > Apologies. Aside from the first instance, where the machine had sat > there for 12+ hours, I never got any panic message or anything like > that which gives an opportunity for a stacktrace, etc. Doesn't matter, you can debug deadlocks too :) > [pjd] >> This is a known issue also in OpenSolaris. ZFS needs to allocate memory >> to send I/O request, and when there is no memory, it can't allocate it >> thus can't swap a process out and free it. > > Ok, so a known issue. Unless someone tells me otherwise I'll update > the ZFS-on-FreeBSD Wiki pages to warn about this issue (assuming it's > editable by me). Thanks. Kris From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 12:40:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 774DE16A4A1 for ; Sun, 9 Sep 2007 12:40:24 +0000 (UTC) (envelope-from shiftyphil@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4814413C49D for ; Sun, 9 Sep 2007 12:40:24 +0000 (UTC) (envelope-from shiftyphil@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1205642waf for ; Sun, 09 Sep 2007 05:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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:references; bh=TN3FkJW5T8T4eJk+7ME0snB8R60oF7ZN21Nwau56+Uk=; b=bPcLrBP2xKKtiNXQPRX6BQVjhiTm8RIqqEEPOCDA5I5qElX1Z0AFGARF0tcKRuLuv3RgSAfI4CCd23lMLrMvM0CjyoiAMUK65xr8To2R9sBI9FYlPaSEBVV4Rzi0lDLAtJuk1Rh6TS5doPL1Z6sZ7m0pRRC1h8f1wtzhnOrXKT0= 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:references; b=IHZ/OHPpJNHa5LdWkxhSEq6bBET8mMQXNgj8YHqtOg71LqtBs7UAEMOuSvb23VFiEtLfVAkJ0JKtAPGSxP6jSZdGsdW6bVM4aRGCBa3pQp66wvaXQbdsBBjqFJ7Xa6f7n+Au/e/4DIp63jeYTZEb7/PUBZHoYH6SIg+IIlUoKsw= Received: by 10.115.111.1 with SMTP id o1mr2811532wam.1189340036384; Sun, 09 Sep 2007 05:13:56 -0700 (PDT) Received: by 10.114.81.8 with HTTP; Sun, 9 Sep 2007 05:13:56 -0700 (PDT) Message-ID: <750ebd430709090513n55e56e71pc03b43fc3b117848@mail.gmail.com> Date: Sun, 9 Sep 2007 22:13:56 +1000 From: "Philip Higgins" To: freebsd-current@freebsd.org In-Reply-To: <2a41acea0705101314s1e711b86rd0b5ac562e0de108@mail.gmail.com> MIME-Version: 1.0 References: <2a41acea0705101314s1e711b86rd0b5ac562e0de108@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: em0: Unable to locate IO BAR ( two 82542 cards ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 12:40:24 -0000 I'm having this same issue (well, identical symptoms) with an 82534. Did you get the fix finished? Tryed with up to date current and two months old, same result. #pciconf -l -v ... em0@pci3:4:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet ... #dmesg ... pci3: on pcib1 pci3: physical bus=3 found-> vendor=0x8086, dev=0x1004, revid=0x02 bus=3, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc6fe0000, size 17, enabled map[14]: type Memory, range 32, base 0xc6fd0000, size 16, enabled pcib1: matched entry for 3.4.INTA pcib1: slot 4 INTA hardwired to IRQ 27 ... em0: mem 0xc6fe0000-0xc6ffffff,0xc6fd0000-0xc6fdffff irq 27 at device 4.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc6fe0000 em0: Unable to locate IO BAR em0: Allocation of PCI resources failed device_attach: em0 attach returned 6 ... On 5/11/07, Jack Vogel wrote: > > Sigh, I changed the logic of what adapters try to map the IO > BAR because only older adapters use it, but now that I look > at the shared code, it turns out when you get to the oldest > ones, aka 82542, they dont do it either. The code used > to make ALL adapters except the 542 try to map it, I > could revert to that, but let me think about this a bit, I > will check in a fix for it by tonight ok? > > Jack > > On 5/10/07, Mark Atkinson wrote: > > > > I just updated to -current from today on a tyan 2895 (K8WE). I applied > the > > new nfe MSI/MSIX support patches as well, however I don't think those > have > > anything to do with the problem below: > > > > FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Thu May 10 10:07:23 PDT > 2007 > > root@k8we:/usr/obj/usr/src/sys/K8WE i386 > > > > > > pci18: on pcib5 > > pci18: physical bus=18 > > found-> vendor=0x8086, dev=0x1000, revid=0x03 > > bus=18, slot=4, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0116, statreg=0x0210, cachelnsz=16 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 > ns) > > intpin=a, irq=10 > > powerspec 1 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xd8100000, size 17, > enabled > > pcib5: requested memory range 0xd8100000-0xd811ffff: good > > pcib5: matched entry for 18.4.INTA > > pcib5: slot 4 INTA hardwired to IRQ 28 > > found-> vendor=0x8086, dev=0x1000, revid=0x03 > > bus=18, slot=9, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0116, statreg=0x0210, cachelnsz=16 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 > ns) > > intpin=a, irq=11 > > powerspec 1 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xd8120000, size 17, > enabled > > pcib5: requested memory range 0xd8120000-0xd813ffff: good > > pcib5: matched entry for 18.9.INTA > > pcib5: slot 9 INTA hardwired to IRQ 29 > > em0: mem > > 0xd8100000-0xd811ffff irq 28 at device 4.0 on pci18 > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8100000 > > em0: Unable to locate IO BAR > > em0: Allocation of PCI resources failed > > device_attach: em0 attach returned 6 > > em1: mem > > 0xd8120000-0xd813ffff irq 29 at device 9.0 on pci18 > > em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8120000 > > em1: Unable to locate IO BAR > > em1: Allocation of PCI resources failed > > device_attach: em1 attach returned 6 > > > > here's the pciconf -v -l output > > > > em0@pci18:4:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82542 Gigabit Ethernet Controller' > > class = network > > subclass = ethernet > > em1@pci18:9:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82542 Gigabit Ethernet Controller' > > class = network > > subclass = ethernet > > > > Attached it the bootverbose output for this machine. > > > > -- > > Mark Atkinson > > atkin901@yahoo.com > > (!wired)?(coffee++):(wired); > > > > _______________________________________________ > > 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 Sun Sep 9 17:20:41 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C84A16A41B for ; Sun, 9 Sep 2007 17:20:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D814013C46C for ; Sun, 9 Sep 2007 17:20:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.13.4) with ESMTP id l89HIaT7050902; Sun, 9 Sep 2007 11:18:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 09 Sep 2007 11:18:45 -0600 (MDT) Message-Id: <20070909.111845.-861032475.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20070906111028.A83649@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> X-Mailer: Mew version 5.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]); Sun, 09 Sep 2007 11:18:36 -0600 (MDT) Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 17:20:41 -0000 In message: <20070906111028.A83649@xorpc.icir.org> Luigi Rizzo writes: : hi, : i was wondering what is the proper way to tell a 64 vs 32 bit architecture. : : I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not : sure if this is generic enough (ie not gcc or FreeBSD specific), : and also suitable for userland (i.e. works on linux or other platforms : as well). It is portable. gcc, and other compilers, define this when using longs and pointers as 64 bit. There's also ILP32 and ILP64 programming models, but only windows 64 uses the latter. Typically, however, there are better ways to solve problems relating to these differences. What kinds of problems are you trying to solve? Warner From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 17:39:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE9D16A417 for ; Sun, 9 Sep 2007 17:39:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCA713C442 for ; Sun, 9 Sep 2007 17:39:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1225943fka for ; Sun, 09 Sep 2007 10:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=XVbYRhGuNFiVNM3O2JYM9UpI4co4ZjTpjYMphX4kJBg=; b=TcCKIJwxsSZ1wL2knU6zHxZQT9qOQZqFu9lV+zUDDq8Zx2xSBb0Z2EwwvDV9uSqU8D3fU8Lp2fRDRfDIbsvB4C+OSL5+9/tOam1vDBNuJnssN80W2U59nRKm1RA0IHV17jodb5k3UQmmuqRnbErd+KNW/FkQ06F96gCnZY17gaA= 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=m7qVqft+AoNZWkSLYJqhGagGl/cLkWldRACzp5xmWeYoYAc2tmKCcSfXvm3vdByD+m987c4e1EqND0n+vCaKm4fpiOZ59PmJhHJFK5GSaHRyw8r8tuPYS2c2Umsti1ZgENpNtBziGO9burv5tx3fDAoTxj1uZjDBrwvcgOYL8FY= Received: by 10.86.23.17 with SMTP id 17mr3071093fgw.1189359593858; Sun, 09 Sep 2007 10:39:53 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Sun, 9 Sep 2007 10:39:53 -0700 (PDT) Message-ID: <2a41acea0709091039v3b945ffdkfee7da7d56fac320@mail.gmail.com> Date: Sun, 9 Sep 2007 10:39:53 -0700 From: "Jack Vogel" To: "Philip Higgins" In-Reply-To: <750ebd430709090513n55e56e71pc03b43fc3b117848@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0705101314s1e711b86rd0b5ac562e0de108@mail.gmail.com> <750ebd430709090513n55e56e71pc03b43fc3b117848@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: em0: Unable to locate IO BAR ( two 82542 cards ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 17:39:56 -0000 On 9/9/07, Philip Higgins wrote: > I'm having this same issue (well, identical symptoms) with an 82534. Did you > get the fix finished? > > Tryed with up to date current and two months old, same result. Hmmm, this is surprising, I thought this issue was resolved. I will have a look into this tomorrow morning when I get into work. Jack > #pciconf -l -v > ... > em0@pci3:4:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82543GC Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > ... > > #dmesg > ... > pci3: on pcib1 > pci3: physical bus=3 > found-> vendor=0x8086, dev=0x1004, revid=0x02 > bus=3, slot=4, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0116, statreg=0x0230, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xc6fe0000, size 17, enabled > map[14]: type Memory, range 32, base 0xc6fd0000, size 16, enabled > pcib1: matched entry for 3.4.INTA > pcib1: slot 4 INTA hardwired to IRQ 27 > ... > em0: mem > 0xc6fe0000-0xc6ffffff,0xc6fd0000-0xc6fdffff irq 27 at device 4.0 on pci3 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc6fe0000 > em0: Unable to locate IO BAR > em0: Allocation of PCI resources failed > device_attach: em0 attach returned 6 > ... From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 17:52:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 391AD16A417 for ; Sun, 9 Sep 2007 17:52:37 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 189E113C4B0 for ; Sun, 9 Sep 2007 17:52:37 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l89HpK6w035749; Sun, 9 Sep 2007 10:51:20 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l89HpKRv035748; Sun, 9 Sep 2007 10:51:20 -0700 (PDT) (envelope-from rizzo) Date: Sun, 9 Sep 2007 10:51:20 -0700 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20070909105120.B34897@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <20070909.111845.-861032475.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070909.111845.-861032475.imp@bsdimp.com>; from imp@bsdimp.com on Sun, Sep 09, 2007 at 11:18:45AM -0600 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 17:52:37 -0000 On Sun, Sep 09, 2007 at 11:18:45AM -0600, M. Warner Losh wrote: > In message: <20070906111028.A83649@xorpc.icir.org> > Luigi Rizzo writes: > : hi, > : i was wondering what is the proper way to tell a 64 vs 32 bit architecture. > : > : I see that some code in sys/ uses ' #ifdef __LP64__ ' but i am not > : sure if this is generic enough (ie not gcc or FreeBSD specific), > : and also suitable for userland (i.e. works on linux or other platforms > : as well). > > It is portable. gcc, and other compilers, define this when using > longs and pointers as 64 bit. There's also ILP32 and ILP64 > programming models, but only windows 64 uses the latter. > > Typically, however, there are better ways to solve problems relating > to these differences. What kinds of problems are you trying to solve? i need to do this: #ifdef BUILT_FOR_64BIT_POINTERS #define MY_MAGIC 0xdeadbeefd00de123 /* 64 bit */ #else #define MY_MAGIC 0xdeadbeef /* 32 bit */ If you know of a way to implement this without preprocessor magic, i am all ears. If the values were simpler (eg all ones or so) i could have used ~((unitptr_t)0) but this is not the case here If there is no better way i can do this static __unused char __invalid_pointer[] = "This is an invalid pointer"; #define MY_MAGIC ((void *)__invalid_pointer) and be done with it. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 19:57:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25C116A419; Sun, 9 Sep 2007 19:57:29 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3DC13C45B; Sun, 9 Sep 2007 19:57:29 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 0552223C4AB; Sun, 9 Sep 2007 21:57:27 +0200 (CEST) Date: Sun, 9 Sep 2007 21:57:27 +0200 From: Peter Schuller To: Kris Kennaway Message-ID: <20070909195727.GA97233@hyperion.scode.org> References: <855622.76488.qm@web36601.mail.mud.yahoo.com> <20070908215102.GA8291@hyperion.scode.org> <46E3519E.3040001@FreeBSD.org> <20070909100041.GA60318@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20070909100041.GA60318@hyperion.scode.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Simun Mikecin , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 19:57:29 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Ok, so a known issue. Unless someone tells me otherwise I'll update > the ZFS-on-FreeBSD Wiki pages to warn about this issue (assuming it's > editable by me). It is not editable by me. So if anyone with edit privileges wants to, what I am referring to is the quickstart guide which has swap-on-zfs as an explicit example, thus implying it will actually work ;) http://wiki.freebsd.org/ZFSQuickStartGuide For convenience, here is the URL to pjd's post that may be worth linking to: http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076831.ht= ml --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5FAmDNor2+l1i30RAmgfAKCLiLmyEYR+ZWPQKWg0ipfRHfkmMACgsJAF U6VoEu/5dFcybt7prEywAXg= =34U3 -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 20:05:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE0916A418 for ; Sun, 9 Sep 2007 20:05:10 +0000 (UTC) (envelope-from mail@petecurry.net) Received: from adam.russellhosting.net (russellit.com [64.246.48.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACE213C465 for ; Sun, 9 Sep 2007 20:05:10 +0000 (UTC) (envelope-from mail@petecurry.net) Received: from 015-806-741.area5.spcsdns.net ([68.240.64.214]:61913 helo=petecurry.net) by adam.russellhosting.net with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.63) (envelope-from ) id 1IUR9b-0003Rv-9w for freebsd-current@freebsd.org; Sun, 09 Sep 2007 14:05:05 -0400 Received: by petecurry.net (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) mail@petecurry.net; Sun, 9 Sep 2007 13:04:51 -0500 (CDT) Date: Sun, 9 Sep 2007 13:04:45 -0500 From: Pete Curry To: freebsd-current@freebsd.org Message-ID: <20070909180445.GA33652@kiwi.petecurry.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - adam.russellhosting.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petecurry.net X-Source: X-Source-Args: X-Source-Dir: Subject: Panic and LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 20:05:10 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've been getting a very reproducable panic in -CURRENT with moderate network traffic (including same-machine traffic, and especially with ssh), and a LOR on boot. kiwi# uname -a FreeBSD kiwi.petecurry.net 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Sep 9 11:01:03 CDT 2007 root@:/usr/obj/usr/src/sys/KIWIKERN amd64 The source is from about 10:00 this morning, and my kernel config and dmesg output is attached. It's been happening for at least a few weeks, about as long as I've been running -CURRENT and had this machine. The LOR message is: Sep 9 11:16:00 kiwi kernel: lock order reversal: (sleepable after non-sleepable) Sep 9 11:16:00 kiwi kernel: 1st 0xffffffff807781a8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 Sep 9 11:16:00 kiwi kernel: 2nd 0xffffffffb1e2f840 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2419 Sep 9 11:16:00 kiwi kernel: KDB: stack backtrace: Sep 9 11:16:00 kiwi kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Sep 9 11:16:00 kiwi kernel: witness_checkorder() at witness_checkorder+0x5f8 Sep 9 11:16:00 kiwi kernel: _sx_slock() at _sx_slock+0x51 Sep 9 11:16:00 kiwi kernel: fr_check() at fr_check+0x61 Sep 9 11:16:00 kiwi kernel: pfil_run_hooks() at pfil_run_hooks+0xc0 Sep 9 11:16:00 kiwi kernel: ip_output() at ip_output+0x37d Sep 9 11:16:00 kiwi kernel: udp_send() at udp_send+0x350 Sep 9 11:16:00 kiwi kernel: sosend_dgram() at sosend_dgram+0x21a Sep 9 11:16:00 kiwi kernel: kern_sendit() at kern_sendit+0x122 Sep 9 11:16:00 kiwi kernel: sendit() at sendit+0xdc Sep 9 11:16:00 kiwi kernel: sendto() at sendto+0x4d Sep 9 11:16:00 kiwi kernel: syscall() at syscall+0x1ce Sep 9 11:16:00 kiwi kernel: Xfast_syscall() at Xfast_syscall+0xab Sep 9 11:16:00 kiwi kernel: --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800c57f6c, rsp = 0x7fffffffec18, rbp = 0x14705c8 --- The panic and backtrace messages are (hand-copied, hopefully accurate): panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: enter: panic [thread pid 20 tid 100012 ] Stopped at kdb_enter+0x31: leave db> bt Tracing pid 20 tid 100012 td 0xffffff0001102000 kdb_enter() at kdb_enter+0x31 panic() at panic+0x173 sleepq_add() at sleepq_add_0x2c1 _sx_xlock_hard() at _sx_xlock_kard+0x19d _sx_xlock() at _sx_xlock+0xb8 fr_check() at fr_check+0xc05 pfil_run_hooks() at pfil_run_hooks+0xc0 ip_output() at ip_output+037d tcp_output() at tcp_output+0xad6 tcp_timer_delack+0xcc softclock() at softclock+0x297 ithread_loop() at ithread_loop+0xe0 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tramoline+0xe --- trap 0, rip= 0, rsp = 0xffffffffabeb1d30, rbp = 0 --- db> I've got a crash dump, but kgdb reports: kiwi# cd /usr/obj/usr/src/sys/KIWIKERN/ kiwi# kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_read: invalid address (0x6461657268742074) kgdb: kvm_read: invalid address (0x7320676e69797254) [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 "amd64-marcel-freebsd". Cannot access memory at address 0x1464 (kgdb) bt #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 (kgdb) Please let me know what other information that I can provide or anything that I can do to help with this issue. Thanks, - Pete Curry --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg 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 Sep 9 11:01:03 CDT 2007 root@:/usr/obj/usr/src/sys/KIWIKERN WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2004.99-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e33d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 8574763008 (8177 MB) avail memory = 8263880704 (7881 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 device_attach: acpi_perf0 attach returned 6 device_attach: acpi_perf0 attach returned 6 coretemp0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 device_attach: acpi_perf1 attach returned 6 device_attach: acpi_perf1 attach returned 6 coretemp1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 device_attach: acpi_perf2 attach returned 6 device_attach: acpi_perf2 attach returned 6 coretemp2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 device_attach: acpi_perf3 attach returned 6 device_attach: acpi_perf3 attach returned 6 coretemp3: on cpu3 p4tcc3: on cpu3 cpu4: on acpi0 device_attach: acpi_perf4 attach returned 6 device_attach: acpi_perf4 attach returned 6 coretemp4: on cpu4 p4tcc4: on cpu4 cpu5: on acpi0 device_attach: acpi_perf5 attach returned 6 device_attach: acpi_perf5 attach returned 6 coretemp5: on cpu5 p4tcc5: on cpu5 cpu6: on acpi0 device_attach: acpi_perf6 attach returned 6 device_attach: acpi_perf6 attach returned 6 coretemp6: on cpu6 p4tcc6: on cpu6 cpu7: on acpi0 device_attach: acpi_perf7 attach returned 6 device_attach: acpi_perf7 attach returned 6 coretemp7: on cpu7 p4tcc7: on cpu7 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xca2,0xca3,0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: irq 18 at device 2.0 on pci2 pci4: on pcib4 em0: port 0x3020-0x303f mem 0xb9420000-0xb943ffff,0xb9000000-0xb93fffff irq 18 at device 0.0 on pci4 em0: Ethernet address: 00:15:17:2f:e1:54 em0: [FILTER] em1: port 0x3000-0x301f mem 0xb9400000-0xb941ffff,0xb8c00000-0xb8ffffff irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:15:17:2f:e1:55 em1: [FILTER] pcib5: at device 0.3 on pci1 pci5: on pcib5 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x2000-0x200f mem 0xb8800000-0xb880000f,0xb8000000-0xb87fffff irq 26 at device 2.0 on pci5 twe0: [GIANT-LOCKED] twe0: [ITHREAD] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 pcib6: at device 3.0 on pci0 pci6: on pcib6 pcib7: at device 4.0 on pci0 pci7: on pcib7 pcib8: at device 5.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: at device 7.0 on pci0 pci10: on pcib10 pci0: at device 8.0 (no driver attached) pcib11: irq 16 at device 28.0 on pci0 pci11: on pcib11 uhci0: port 0x40a0-0x40bf 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 0x4080-0x409f irq 22 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 0x4060-0x407f irq 23 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 0x4040-0x405f irq 22 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 0xb9700400-0xb97007ff 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 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci0: port 0x1000-0x10ff mem 0xb0000000-0xb7ffffff,0xb9600000-0xb960ffff irq 17 at device 12.0 on pci12 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40c0-0x40cf irq 20 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x40d8-0x40df,0x40f4-0x40f7,0x40d0-0x40d7,0x40f0-0x40f3,0x4020-0x403f mem 0xb9700000-0xb97003ff irq 20 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] 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: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca800-0xcb7ff,0xcb800-0xcc7ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd2 at ukbd0 uhid0: on uhub0 ugen0: on uhub1 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA66 twed0: on twe0 twed0: 70910MB (145224064 sectors) lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #4 Launched! lapic7: Forcing LINT1 to edge trigger SMP: AP CPU #7 Launched! lapic5: Forcing LINT1 to edge trigger SMP: AP CPU #5 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #6 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/twed0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 11280 files 250 WARNING: /var was not properly dismounted /var: mount pending error: blocks 16 files 3 WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 IP Filter: v4.1.23 initialized. Default = pass all, Logging = enabled em0: link state changed to UP lock order reversal: (sleepable after non-sleepable) 1st 0xffffffff807781a8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffffb1e2f840 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2419 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x5f8 _sx_slock() at _sx_slock+0x51 fr_check() at fr_check+0x61 pfil_run_hooks() at pfil_run_hooks+0xc0 ip_input() at ip_input+0x2c1 ether_demux() at ether_demux+0x1d9 ether_input() at ether_input+0x1d6 em_handle_rxtx() at em_handle_rxtx+0x245 taskqueue_run() at taskqueue_run+0x94 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffabec7d30, rbp = 0 --- TCP: [192.168.1.103]:58860 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:65516 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [192.168.1.103]:50111 to [192.168.1.4]:22 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=KIWIKERN cpu HAMMER ident KIWIKERN makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Transmission Control Protocol 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 UFS_GJOURNAL # Enable gjournal-based UFS journaling 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 NTFS # NT File System 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_IA32 # Compatible with i386 binaries 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 options AUDIT # Security event auditing # 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 # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq device coretemp # Bus support. device acpi 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 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) 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 # 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 em # Intel PRO/1000 adapter Gigabit Ethernet Card # 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 urio # Diamond Rio 500 MP3 player device uscanner # Scanners --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 20:11:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E04DF16A417 for ; Sun, 9 Sep 2007 20:11:03 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF1613C457 for ; Sun, 9 Sep 2007 20:11:03 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1316031waf for ; Sun, 09 Sep 2007 13:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=ufD+dSDKVaN0CYaOY07r+3w5WqiEBVfcNunhb4bQajM=; b=cO1sgLGtUZS76+TFiwvUAXD91FEgrxGIJoSvEFcDQ3EfKLxRcbQ3/vgYd4O1zuA5u/LP1n4xUp5taWVN54jArcLNbEHGxwt0RwQTO5Zjm6u24H5UF7xo3VMd6F1u3FZ6+jO1HraggAHRY+B9vrSkz7BraYcLdG9DcU1YWInO7lk= 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=oWCO29PYwv7nUuh2dS3VkNA54g3Bv1LjHLUpPfWXps+/Ozm3Ck8/zQjT2bj5WK96uTTicCvLsu6TNVcB1U3ayhWCiAO/uf6m5R62TJMDdqXf6GvJQ2rdEydlM77ZVzLSo+3PYqVoyuoVaxz+kqV3nD5I6XuwNUZjCj66HINcdU8= Received: by 10.115.109.1 with SMTP id l1mr3036552wam.1189368662223; Sun, 09 Sep 2007 13:11:02 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 9 Sep 2007 13:11:02 -0700 (PDT) Message-ID: Date: Sun, 9 Sep 2007 13:11:02 -0700 From: "Kip Macy" To: "Pete Curry" In-Reply-To: <20070909180445.GA33652@kiwi.petecurry.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070909180445.GA33652@kiwi.petecurry.net> Cc: freebsd-current@freebsd.org Subject: Re: Panic and LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 20:11:04 -0000 This is a known issue. sx locks aren't for use in the I/O path. The firewall maintainer chooses to use them. This might be avoidable in the future if we can establish a mechanism for preventing pfil from being unloaded without protecting it with an rwlock. -Kip On 9/9/07, Pete Curry wrote: > Hi, > > I've been getting a very reproducable panic in -CURRENT with moderate > network traffic (including same-machine traffic, and especially > with ssh), and a LOR on boot. > > kiwi# uname -a > FreeBSD kiwi.petecurry.net 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun > Sep 9 11:01:03 CDT 2007 root@:/usr/obj/usr/src/sys/KIWIKERN amd64 > > The source is from about 10:00 this morning, and my kernel config > and dmesg output is attached. It's been happening for at least a > few weeks, about as long as I've been running -CURRENT and had this > machine. > > The LOR message is: > Sep 9 11:16:00 kiwi kernel: lock order reversal: (sleepable after non-sleepable) > Sep 9 11:16:00 kiwi kernel: 1st 0xffffffff807781a8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 > Sep 9 11:16:00 kiwi kernel: 2nd 0xffffffffb1e2f840 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2419 > Sep 9 11:16:00 kiwi kernel: KDB: stack backtrace: > Sep 9 11:16:00 kiwi kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Sep 9 11:16:00 kiwi kernel: witness_checkorder() at witness_checkorder+0x5f8 > Sep 9 11:16:00 kiwi kernel: _sx_slock() at _sx_slock+0x51 > Sep 9 11:16:00 kiwi kernel: fr_check() at fr_check+0x61 > Sep 9 11:16:00 kiwi kernel: pfil_run_hooks() at pfil_run_hooks+0xc0 > Sep 9 11:16:00 kiwi kernel: ip_output() at ip_output+0x37d > Sep 9 11:16:00 kiwi kernel: udp_send() at udp_send+0x350 > Sep 9 11:16:00 kiwi kernel: sosend_dgram() at sosend_dgram+0x21a > Sep 9 11:16:00 kiwi kernel: kern_sendit() at kern_sendit+0x122 > Sep 9 11:16:00 kiwi kernel: sendit() at sendit+0xdc > Sep 9 11:16:00 kiwi kernel: sendto() at sendto+0x4d > Sep 9 11:16:00 kiwi kernel: syscall() at syscall+0x1ce > Sep 9 11:16:00 kiwi kernel: Xfast_syscall() at Xfast_syscall+0xab > Sep 9 11:16:00 kiwi kernel: --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800c57f6c, rsp = 0x7fffffffec18, rbp = 0x14705c8 --- > > The panic and backtrace messages are (hand-copied, hopefully accurate): > panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 0 > KDB: enter: panic > [thread pid 20 tid 100012 ] > Stopped at kdb_enter+0x31: leave > db> bt > Tracing pid 20 tid 100012 td 0xffffff0001102000 > kdb_enter() at kdb_enter+0x31 > panic() at panic+0x173 > sleepq_add() at sleepq_add_0x2c1 > _sx_xlock_hard() at _sx_xlock_kard+0x19d > _sx_xlock() at _sx_xlock+0xb8 > fr_check() at fr_check+0xc05 > pfil_run_hooks() at pfil_run_hooks+0xc0 > ip_output() at ip_output+037d > tcp_output() at tcp_output+0xad6 > tcp_timer_delack+0xcc > softclock() at softclock+0x297 > ithread_loop() at ithread_loop+0xe0 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_tramoline+0xe > --- trap 0, rip= 0, rsp = 0xffffffffabeb1d30, rbp = 0 --- > db> > > I've got a crash dump, but kgdb reports: > kiwi# cd /usr/obj/usr/src/sys/KIWIKERN/ > kiwi# kgdb kernel.debug /var/crash/vmcore.0 > kgdb: kvm_read: invalid address (0x6461657268742074) > kgdb: kvm_read: invalid address (0x7320676e69797254) > [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 "amd64-marcel-freebsd". > Cannot access memory at address 0x1464 > (kgdb) bt > #0 0x0000000000000000 in ?? () > Cannot access memory at address 0x0 > (kgdb) > > Please let me know what other information that I can provide or > anything that I can do to help with this issue. > > Thanks, > - Pete Curry > > _______________________________________________ > 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 Sep 9 20:41:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4CC316A417 for ; Sun, 9 Sep 2007 20:41:24 +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 ACC3113C45E for ; Sun, 9 Sep 2007 20:41:24 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27135 invoked from network); 9 Sep 2007 20:41:23 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 9 Sep 2007 20:41:23 -0000 Message-ID: <46E45A6D.1010805@root.org> Date: Sun, 09 Sep 2007 13:41:17 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Kostik Belousov References: <46E0777A.8070901@root.org> <20070907133901.GL53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070907133901.GL53667@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------040800050701000906010408" Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 20:41:25 -0000 This is a multi-part message in MIME format. --------------040800050701000906010408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kostik Belousov wrote: > On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: >> I've done some major rework on the EC driver. This should help with >> various problems, including timeouts while checking battery status or >> temperature. The attached patches are for 6.x and 7.x. Please test and >> let me know if you get any new errors on dmesg or if it fixes things for >> you (especially HP/Compaq laptop owners). > Ok, I tryed it on Acer 2490-kind of laptop. I see no difference with the > patch, battery status seems to be reported correctly both before and after > applying it. > > The only thing I want to note is that reboot on the laptop is turned into > poweroff. You said in the followup to original letter that poweroff is > turned into reboot, I did not checked it; this is opposite. Please test this revised version. All it changes is forcing polling mode back on during reboot/shutdown. -Nate --------------040800050701000906010408 Content-Type: text/x-patch; name="ecng-6b.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6b.diff" --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 9 Sep 2007 20:35:53 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,7 +149,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,36 +186,46 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, + EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); + +static ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); @@ -328,7 +235,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -369,7 +277,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -688,100 +598,92 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +727,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -850,149 +764,188 @@ if (ACPI_FAILURE(Status)) break; } - EcUnlock(sc); + return_ACPI_STATUS (Status); } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { + if (cold || rebooting || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; - if (count == 0) + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); + sc->ec_burstactive = FALSE; + } if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } @@ -1000,43 +953,50 @@ static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------040800050701000906010408 Content-Type: text/x-patch; name="ecng-7b.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7b.diff" --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 6 Sep 2007 22:23:52 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -248,7 +139,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); -static __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,25 +206,14 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } @@ -349,7 +225,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -390,7 +267,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -661,7 +539,6 @@ if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,52 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +645,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +714,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +757,94 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { + if (cold || rebooting || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; - } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); sc->ec_burstactive = FALSE; } if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +852,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +872,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +888,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +898,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,21 +917,20 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } @@ -1086,6 +942,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +961,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------040800050701000906010408-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 20:45:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2ED16A420 for ; Sun, 9 Sep 2007 20:45:48 +0000 (UTC) (envelope-from mail@petecurry.net) Received: from adam.russellhosting.net (russellit.com [64.246.48.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6972613C469 for ; Sun, 9 Sep 2007 20:45:48 +0000 (UTC) (envelope-from mail@petecurry.net) Received: from 015-806-741.area5.spcsdns.net ([68.240.64.214]:61116 helo=petecurry.net) by adam.russellhosting.net with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.63) (envelope-from ) id 1IUTfD-0007YG-Tk; Sun, 09 Sep 2007 16:45:53 -0400 Received: by petecurry.net (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) mail@petecurry.net; Sun, 9 Sep 2007 15:45:39 -0500 (CDT) Date: Sun, 9 Sep 2007 15:45:36 -0500 From: Pete Curry To: Kip Macy Message-ID: <20070909204536.GB33652@kiwi.petecurry.net> References: <20070909180445.GA33652@kiwi.petecurry.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - adam.russellhosting.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petecurry.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: Panic and LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 20:45:48 -0000 Hi Kip, On Sun, Sep 09, 2007 at 01:11:02PM -0700, Kip Macy wrote: > This is a known issue. sx locks aren't for use in the I/O path. The > firewall maintainer chooses to use them. This might be avoidable in > the future if we can establish a mechanism for preventing pfil from > being unloaded without protecting it with an rwlock. > Sorry, I didn't notice this in my search. I've switched to pf instead and it seems to work fine. Thank you! - Pete Curry > -Kip > > > > On 9/9/07, Pete Curry wrote: > > Hi, > > > > I've been getting a very reproducable panic in -CURRENT with moderate > > network traffic (including same-machine traffic, and especially > > with ssh), and a LOR on boot. > > > > kiwi# uname -a > > FreeBSD kiwi.petecurry.net 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun > > Sep 9 11:01:03 CDT 2007 root@:/usr/obj/usr/src/sys/KIWIKERN amd64 > > > > The source is from about 10:00 this morning, and my kernel config > > and dmesg output is attached. It's been happening for at least a > > few weeks, about as long as I've been running -CURRENT and had this > > machine. > > > > The LOR message is: > > Sep 9 11:16:00 kiwi kernel: lock order reversal: (sleepable after non-sleepable) > > Sep 9 11:16:00 kiwi kernel: 1st 0xffffffff807781a8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 > > Sep 9 11:16:00 kiwi kernel: 2nd 0xffffffffb1e2f840 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2419 > > [snip] From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 23:14:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCB016A417 for ; Sun, 9 Sep 2007 23:14:29 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id F0AE413C45E for ; Sun, 9 Sep 2007 23:14:28 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id ECB6B10749 for ; Mon, 10 Sep 2007 08:14:27 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50129-04 for ; Mon, 10 Sep 2007 08:14:26 +0900 (JST) Received: from biotite (unknown [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Mon, 10 Sep 2007 08:14:26 +0900 (JST) Date: Mon, 10 Sep 2007 08:14:25 +0900 From: "YAMAMOTO, Taku" To: freebsd-current@freebsd.org Message-Id: <20070910081425.3c45bca7.taku@tackymt.homeip.net> Organization: Trans New Technology, Inc. X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__10_Sep_2007_08_14_25_+0900_cqp7R7NAls_11qb1" X-Virus-Scanned: amavisd-new at tackymt.homeip.net X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: setenv() doesn't export unsetenv()ed variables to environ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 23:14:29 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__10_Sep_2007_08_14_25_+0900_cqp7R7NAls_11qb1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Greetings, I found a regression in src/lib/libc/stdlib/getenv.c during tracking strange behaviour of the sshguard-pf. In short, setenv() doesn't add an entry to environ[] if the name was once removed by unsetenv(). I'm suspecting the function __setenv() lacks care of the case to reuse a deactivated entry and it needs the following change: --- lib/libc/stdlib/getenv.c.orig 2007-07-21 08:30:13.000000000 +0900 +++ lib/libc/stdlib/getenv.c 2007-09-10 08:07:22.732672106 +0900 @@ -492,7 +492,7 @@ __setenv(const char *name, size_t nameLe newEnvActive++; /* No need to rebuild environ if the variable was reused. */ - if (reuse) + if (reuse && newEnvActive == envActive) return (0); else return (__rebuild_environ(newEnvActive)); A small testcase is attached. It should emit: expecting "foo": foo expecting "bar": bar With current broken setenv(), it would emit: expecting "foo": foo expecting "bar": -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Mon__10_Sep_2007_08_14_25_+0900_cqp7R7NAls_11qb1-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 23:17:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1299A16A418 for ; Sun, 9 Sep 2007 23:17:40 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id B558313C428 for ; Sun, 9 Sep 2007 23:17:39 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 3F3C310749 for ; Mon, 10 Sep 2007 08:17:39 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50583-01 for ; Mon, 10 Sep 2007 08:17:37 +0900 (JST) Received: from biotite (unknown [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Mon, 10 Sep 2007 08:17:37 +0900 (JST) Date: Mon, 10 Sep 2007 08:17:36 +0900 From: "YAMAMOTO, Taku" To: freebsd-current@freebsd.org Message-Id: <20070910081736.45268f60.taku@tackymt.homeip.net> In-Reply-To: <20070910081425.3c45bca7.taku@tackymt.homeip.net> References: <20070910081425.3c45bca7.taku@tackymt.homeip.net> Organization: Trans New Technology, Inc. X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__10_Sep_2007_08_17_36_+0900_prmCFf2l=WNuJLww" X-Virus-Scanned: amavisd-new at tackymt.homeip.net Subject: Follow-up: setenv() doesn't export unsetenv()ed variables to environ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 23:17:40 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__10_Sep_2007_08_17_36_+0900_prmCFf2l=WNuJLww Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Ouch, the testcase had got stripped due to inappropriate MIME type. On Mon, 10 Sep 2007 08:14:25 +0900 "YAMAMOTO, Taku" wrote: > Greetings, > > I found a regression in src/lib/libc/stdlib/getenv.c during tracking > strange behaviour of the sshguard-pf. > > In short, setenv() doesn't add an entry to environ[] if the name was > once removed by unsetenv(). > > I'm suspecting the function __setenv() lacks care of the case to reuse > a deactivated entry and it needs the following change: > > --- lib/libc/stdlib/getenv.c.orig 2007-07-21 08:30:13.000000000 +0900 > +++ lib/libc/stdlib/getenv.c 2007-09-10 08:07:22.732672106 +0900 > @@ -492,7 +492,7 @@ __setenv(const char *name, size_t nameLe > newEnvActive++; > > /* No need to rebuild environ if the variable was reused. */ > - if (reuse) > + if (reuse && newEnvActive == envActive) > return (0); > else > return (__rebuild_environ(newEnvActive)); > > > A small testcase is attached. > It should emit: > expecting "foo": foo > expecting "bar": bar > > With current broken setenv(), it would emit: > expecting "foo": foo > expecting "bar": > > > -- > -|-__ YAMAMOTO, Taku > | __ < > > - A chicken is an egg's way of producing more eggs. - > -- -|-__ $B;3K\!!Bs(B / YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Mon__10_Sep_2007_08_17_36_+0900_prmCFf2l=WNuJLww Content-Type: text/plain; name="setenvtest.c" Content-Disposition: attachment; filename="setenvtest.c" Content-Transfer-Encoding: 7bit #include #include #include int main(void) { if (setenv("HOGE", "foo", 1)) warn("setenv(1st)"); system("echo 'expecting \"foo\":' $HOGE"); if (unsetenv("HOGE")) warn("unsetenv(1st)"); if (setenv("HOGE", "bar", 1)) warn("setenv(2nd)"); system("echo 'expecting \"bar\":' $HOGE"); return 0; } --Multipart=_Mon__10_Sep_2007_08_17_36_+0900_prmCFf2l=WNuJLww-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 9 23:46:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F135516A418; Sun, 9 Sep 2007 23:46:10 +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 3616313C428; Sun, 9 Sep 2007 23:46:09 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup250.ach.sch.gr [81.186.70.250]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l89NQs1L012015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Sep 2007 02:27:28 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l89NQdl7016527; Mon, 10 Sep 2007 02:26:40 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l89NQKOo016526; Mon, 10 Sep 2007 02:26:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 10 Sep 2007 02:26:19 +0300 From: Giorgos Keramidas To: obrien@freebsd.org, d@delphij.net, Robert Watson , freebsd-current@freebsd.org Message-ID: <20070909232619.GA16499@kobe.laptop> References: <20070902181119.E21906@fledge.watson.org> <46DAF092.1030708@delphij.net> <46DB5F1C.4020807@delphij.net> <20070903021119.GD12449@kobe.laptop> <46DB705C.2090205@delphij.net> <20070905172312.GA95447@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070905172312.GA95447@dragon.NUXI.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.089, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.31, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: Re: more(1) has gotten more demanding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Sep 2007 23:46:11 -0000 On 2007-09-05 10:23, David O'Brien wrote: >On Mon, Sep 03, 2007 at 10:24:28AM +0800, LI Xin wrote: >> Giorgos Keramidas wrote: >> > On 2007-09-03 09:10, Xin LI wrote: >> >> Sorry, the patch. >> http://people.freebsd.org/~delphij/for_review/main.c.diff > > Will it work for the 'b' key when invoked as 'more' Hi David, I apologize for the delay. "Yes" is the reply. > BSD more is more functional than simple SysV more which only paged in > the forward direction. Heh, yes that is true and it's one of the commonly annoying things whenever I have to use a "Core Solaris" installation :) From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 06:14:39 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326D516A419; Mon, 10 Sep 2007 06:14:39 +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 C1A5313C474; Mon, 10 Sep 2007 06:14:38 +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 1IUcXc-000NdZ-LH; Mon, 10 Sep 2007 09:14:36 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Lawrence Farr" In-reply-to: <046801c7f229$a4534510$ecf9cf30$@co.uk> References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> Comments: In-reply-to "Lawrence Farr" message dated "Sat, 08 Sep 2007 16:05:03 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2007 09:14:36 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org, 'cpghost' , 'Gavin Atkinson' Subject: Re: dump 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, 10 Sep 2007 06:14:39 -0000 > > > > the only indication I can see, is that one of the dump procs. is > > waiting on > > sbwait, and probably it's some deadlock, which is similar to what I > > keep > > seeing here, i'll try now with SCHED_ULE to see if it make a > > difference. > > > I'm running SCHED_ULE on these already, if your not I guess it's not the > scheduler? > I can get it to 'work' by fiddling with the b flag (blocksize), which still points to some timming/deadlock problem. ie: dump 0abf 64 /some/backup/file /file/to/backup now works, but dump 0abf 64 - | restore rbf 64 - hangs as before. (i don't think the b 64 in restore is needed). danny From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 08:10:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1710016A478 for ; Mon, 10 Sep 2007 08:10:46 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from mail.tac-tac.cz (mail.tac-tac.cz [194.212.102.90]) by mx1.freebsd.org (Postfix) with ESMTP id 6053813C465 for ; Mon, 10 Sep 2007 08:10:45 +0000 (UTC) (envelope-from jmadle@tac-tac.cz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tac-tac.cz (Postfix) with ESMTP id AE46A22EFB; Mon, 10 Sep 2007 09:43:11 +0200 (CEST) Received: from mail.tac-tac.cz ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21527-10; Mon, 10 Sep 2007 09:43:07 +0200 (CEST) Received: from pcjirka (unknown [1.0.0.10]) by mail.tac-tac.cz (Postfix) with SMTP id CF2B451EE; Mon, 10 Sep 2007 09:43:07 +0200 (CEST) Message-ID: <033201c7f37e$3e69d2e0$0a000001@pcjirka> From: "TAC-TAC computer s.r.o." To: References: <20070908120006.B9E6E16A4EE@hub.freebsd.org> Date: Mon, 10 Sep 2007 09:43:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tac-tac.cz Cc: remy.nonnenmacher@activnetworks.com Subject: RE: Solid hang with bge interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 08:10:46 -0000 Same problem with Supermicro H8SSL-R10. (amd64) If I remember, this bge problem was reported 3-4 month ago first time - but i have not found any idea of solution anywhere. Jiri Madle TAC-TAC computer s.r.o. jmadle@tac-tac.cz >> -----Original Message----- >> From: Remy Nonnenmacher [mailto:remy.nonnenmacher@activnetworks.com] >> Sent: 21 August 2007 10:45 >> To: Lawrence Farr >> Cc: freebsd-current@freebsd.org >> Subject: Re: Solid hang with bge interface >> >> Lawrence Farr wrote: >> > I have a Supermicro H8DAR-T based server, that was happily >> > running 6-stable from last year sometime. I swapped it out and >> > have been trying to get -CURRENT installed on it but it hangs >> > solid as soon as you configure the bge0 interface. The bge1 >> > interface will work occasionally tho. To try and rule out a >> > hardware fault I booted an AMD64-6.0RC1 cd that I had, which >> > had no problems at all with the interface: >> > >> > http://www.epcdirect.com/bootlog/6boot.txt >> > >> > But the current snapshot from June, and from todays source >> > hangs solid as soon as you try to set up the bge0 interface. >> > >> > http://www.epcdirect.com/bootlog/currentboot.txt >> > >> > As you can see, it hangs solid at "Setting hostname". >> > >> > I've also removed the 3ware card "just in case" but it made >> > no difference. Latest BIOS too. I found some references to >> > a similar problem with bge recently too: >> > >> > http://lists.freebsd.org/pipermail/freebsd-current/2007- >> August/075998.html >> > >> > >> > Anyone else seeing this? >> > >> >> Same here with a Supermicro H8SSL-I2 (Serverworks HT1000 based). >> >> bge0 locks the system hard when going up, bge1 OK (but goes down a few >> hours after start). Also, an ifconfig indicates: >> >> bge0: flags=8802 metric 0 mtu 1500 >> options=9b >> ether 00:30:48:5e:6e:56 >> media: Ethernet autoselect (none ) >> ^^^^^^^^^^^^^^^^^^ >> status: no carrier >> bge1: flags=8843 metric 0 mtu >> 1500 >> options=9b >> ether 00:30:48:5e:6e:57 >> inet 192.168.1.49 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> >> An the dmesg shows: (see "^^^^..") >> >> . >> . >> bge0: > 0x2100> mem 0xff4f0000-0xff4fffff irq 24 at device 3.0 on pci2 >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bge0: Ethernet address: 00:30:48:5e:6e:56 >> bge0: [ITHREAD] >> pci2:3:1: bad VPD cksum, remain 14 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> bge1: > 0x2100> >> mem 0xff4e0000-0xff4effff irq 25 at device 3.1 on pci2 >> miibus1: on bge1 >> brgphy1: PHY 1 on miibus1 >> brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bge1: Ethernet address: 00:30:48:5e:6e:57 >> bge1: [ITHREAD] >> . >> . >> >> (I also have strange problems with the SATA controller and recent >> kernels (that works fine on other machines) that seems to read random >> sectors (at least not those requested) causing core-dumps, compiler >> internal errors, trashed sources and false positives about corrupted >> filesystems.I don't know what is going on on this platform but it >> smells^Gdoesn't looks very sane.) >> >> RN. >> IeM >> >> > > This is still hanging with yesterdays current in i386 and AMD64, is it > worth > opening a PR? > > > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-current Digest, Vol 212, Issue 7 > *********************************************** > From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 08:14:47 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B09916A41A; Mon, 10 Sep 2007 08:14:47 +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 E07DD13C457; Mon, 10 Sep 2007 08:14:46 +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 1IUePt-000P2R-RM; Mon, 10 Sep 2007 11:14:45 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@FreeBSD.org, hackers@FreeBSD.org In-reply-to: References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> Comments: In-reply-to Danny Braniss message dated "Mon, 10 Sep 2007 09:14:36 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2007 11:14:45 +0300 From: Danny Braniss Message-ID: Cc: 'cpghost' , 'Gavin Atkinson' Subject: Re: dump 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, 10 Sep 2007 08:14:47 -0000 > > > > > > the only indication I can see, is that one of the dump procs. is > > > waiting on > > > sbwait, and probably it's some deadlock, which is similar to what I > > > keep > > > seeing here, i'll try now with SCHED_ULE to see if it make a > > > difference. > > > > > > I'm running SCHED_ULE on these already, if your not I guess it's not the > > scheduler? > > > I can get it to 'work' by fiddling with the b flag (blocksize), which still > points to some timming/deadlock problem. > ie: > dump 0abf 64 /some/backup/file /file/to/backup > now works, but > dump 0abf 64 - | restore rbf 64 - > hangs as before. (i don't think the b 64 in restore is needed). ok, it is time to look at the sources, this program has been around since the beginin of time, or at least since Unix V6 :-), and it has been hacked ever since. but now that most of you never heard of 9track tapes, etc, I was wondering if there is a point in hacking at it again. pros: dump/restore has never failed me till now. cons: there are other programs tar/cpio/gtar/etc, but they each have their nits. so here are some questions: - is the readers/writer split realy needed now? my guess it was put in in the old days to get tapes streaming - which is btw, what's not working. - is it/will it be needed for ZFS? [dump is for ufs ...] danny From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 10:05:10 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3045316A46C for ; Mon, 10 Sep 2007 10:05:10 +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 D595C13C45A for ; Mon, 10 Sep 2007 10:05:09 +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:Subject:From:X-Attribution:Date:Message-Id; b=My3QlJDVQ4IpEXFdc30zaoJtZmNcY8D6klEUCeuyCi0oPngr6BfI+/QiEDDRgDduG65XgIZyl1ZqeO/Y4Vwu/ZE9vz9mwMtjK+fD9CkEiw4VOecJcivsXNETqeM6ROSgafJXn1zCmWckiMvn+3MsO/Q+SpX3kbELyIkKguq9128aeZioMYqFYMHy/juKJojIZ0MF0IAihqrhd4//5CTj9tH9dGhMu7kAjpwG6ibD8FMWzFWIiFNZaqWn9bwnsksn; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.66) (envelope-from ) id 1IUg8j-0005St-I7 for current@freebsd.org; Mon, 10 Sep 2007 10:05:09 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1IUg7o-0006MD-5D for current@freebsd.org; Mon, 10 Sep 2007 10:04:12 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IUg7m-0004n7-8M for current@freebsd.org; Mon, 10 Sep 2007 12:04:10 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 10 Sep 2007 12:04:10 +0200 Message-Id: Cc: Subject: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 10:05:10 -0000 Hi I was wondering if anyone else is having this problem building asterisk on -CURRENT. The problem may not be with FreeBSD - it looks like gnu configure is incorrectly detecting the CPU as "i386" when it's actually a pentium3: configure: Package configured for: configure: OS type : freebsd7.0 configure: Host CPU : i386 ===> Building for asterisk-1.4.11 The i386 doesn't have any atomic primatives or something like that (maybe just according to gcc-4.2). If I frob the configured sources and change the i386 to pentium3, then the build works, but I don't have enough asterisk foo at this point to verify that it actually works. ast_expr2f.o asterisk.o astmm.o autoservice.o callerid.o cdr.o channel.o chanv ars.o cli.o config.o cryptostub.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o enum.o file.o fixedjitterbuf.o frame.o fskmodem.o http.o image.o indications.o io.o jitterbuf.o loader.o logger.o manager.o md5.o netsock.o pbx.o plc.o privacy .o rtp.o say.o sched.o sha1.o slinfactory.o srv.o stdtime/localtime.o strcompat. o tdd.o term.o threadstorage.o translate.o udptl.o ulaw.o utils.o editline/libed it.a -> asterisk channel.o(.text+0x2b52): In function `ast_channel_alloc': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' channel.o(.text+0x2ec1):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' cli.o(.text+0x3a4a): In function `ast_cli_command': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' dial.o(.text+0x3da): In function `ast_dial_append': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' loader.o(.text+0xe3c): In function `__ast_module_user_add': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' loader.o(.text+0xec9):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/aster isk/lock.h:775: more undefined references to `__sync_fetch_and_add_4' follow manager.o(.text+0x197): In function `process_events': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi ned reference to `__sync_sub_and_fetch_4' manager.o(.text+0x173e): In function `free_session': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi ned reference to `__sync_sub_and_fetch_4' manager.o(.text+0x18ab): In function `accept_thread': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' manager.o(.text+0x1962):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' manager.o(.text+0x1a67):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' manager.o(.text+0x1b15):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' manager.o(.text+0x4774): In function `action_waitevent': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi ned reference to `__sync_sub_and_fetch_4' manager.o(.text+0x5f81): In function `generic_http_callback': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' manager.o(.text+0x5f8f):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' manager.o(.text+0x6a65):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' manager.o(.text+0x70b5): In function `session_do': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' utils.o(.text+0xde8): In function `ast_atomic_dec_and_test': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi ned reference to `__sync_sub_and_fetch_4' utils.o(.text+0xe01): In function `ast_atomic_fetchadd_int': /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi ned reference to `__sync_fetch_and_add_4' gmake[1]: *** [asterisk] Error 1 gmake: *** [main] Error 2 *** Error code 2 Stop in /usr/ports/net/asterisk. *** Error code 1 Stop in /usr/ports/net/asterisk. -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 10:50:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C9E16A417 for ; Mon, 10 Sep 2007 10:50:07 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 22A2913C45E for ; Mon, 10 Sep 2007 10:50:07 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.13] (helo=[10.29.62.13]) by fish.ish.com.au with esmtpa (Exim 4.43) id 1IUgmZ-0004AO-U7; Mon, 10 Sep 2007 20:46:25 +1000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-226-660800478" Message-Id: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> Content-Transfer-Encoding: 7bit From: Aristedes Maniatis Date: Mon, 10 Sep 2007 20:49:57 +1000 To: freebsd-current@freebsd.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 10:50:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-226-660800478 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've been able to locate some old posts about the Adaptec AIC9410 chipset. I've acquired one of these in a new server: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-3.cfm? PID=TWR We are looking to set up 2 SATA drives in a mirrored pair and started with trying to get it to work under FreeBSD 6. When I couldn't get it to detect the driver I then tried the most recent August CURRENT snapshot. It does not appear to recognise the drives either as a RAID set or separately when booting from the FreeBSD current CD. The only historical references I could find were: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg79964.html where a year ago Scott Long suggests that it might work in HostRAID mode but not in standalone mode. I've Googled extensively and couldn't find a description of how HostRAID mode is different to full 'regular' RAID. It appears to be some sort of RAID where the system CPU does more of the work, but I'm not sure. My questions: * is the AIC9410 supported in any version of FreeBSD, whether I am using the Adaptec HostRAID or just mounting the drives individually? * does raidutil (part of ports/systutils/asr-utils) usable with this chipset? Cheers Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A --Apple-Mail-226-660800478 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkblIVYACgkQ72p9Lj5JECrR6ACfX7hitvxNXY90mhQXaH3cZQ8U pTUAn305Ym0qk5yHY8ZaCCkl5Cm8FSVu =7DRL -----END PGP SIGNATURE----- --Apple-Mail-226-660800478-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 11:18:50 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D6D16A419 for ; Mon, 10 Sep 2007 11:18:50 +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 1E40B13C428 for ; Mon, 10 Sep 2007 11:18:49 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8ABImk4069889; Mon, 10 Sep 2007 15:18:48 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1189423128; bh=q2vsktf13mVmHqJNUn0rZIx2oECWwe3HHbkTo8H bzN0=; l=595; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=KwlziIoVXhwVNoldH/YrX5FMgrfv2RQOiQQEsROx K0d4J07HkZDFHObYgiGCQErgLLdDA9bEej4ObkKpl2EDvt17r+bQBe63UTEreyXpaTz 7HgyjKHqGPjrilIKYONU+xwqegzeRa8Vxsx+U4N49Lvsz70MNqs8r/BItRR+K76U= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8ABIkQq069888; Mon, 10 Sep 2007 15:18:46 +0400 (MSD) (envelope-from ache) Date: Mon, 10 Sep 2007 15:18:45 +0400 From: Andrey Chernov To: "YAMAMOTO, Taku" , scf@FreeBSD.org Message-ID: <20070910111845.GA69818@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "YAMAMOTO, Taku" , scf@FreeBSD.org, freebsd-current@FreeBSD.ORG References: <20070910081425.3c45bca7.taku@tackymt.homeip.net> <20070910081736.45268f60.taku@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910081736.45268f60.taku@tackymt.homeip.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@FreeBSD.org Subject: Re: Follow-up: setenv() doesn't export unsetenv()ed variables to environ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 11:18:50 -0000 On Mon, Sep 10, 2007 at 08:17:36AM +0900, YAMAMOTO, Taku wrote: > > --- lib/libc/stdlib/getenv.c.orig 2007-07-21 08:30:13.000000000 +0900 > > +++ lib/libc/stdlib/getenv.c 2007-09-10 08:07:22.732672106 +0900 > > @@ -492,7 +492,7 @@ __setenv(const char *name, size_t nameLe > > newEnvActive++; > > > > /* No need to rebuild environ if the variable was reused. */ > > - if (reuse) > > + if (reuse && newEnvActive == envActive) > > return (0); > > else > > return (__rebuild_environ(newEnvActive)); Looks like the right fix. CC'ed to author. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 11:25:14 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A01E716A417 for ; Mon, 10 Sep 2007 11:25:14 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6585C13C46A for ; Mon, 10 Sep 2007 11:25:14 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8ABNtIR045989; Mon, 10 Sep 2007 04:23:55 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8ABNtmD045988; Mon, 10 Sep 2007 04:23:55 -0700 (PDT) (envelope-from rizzo) Date: Mon, 10 Sep 2007 04:23:55 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20070910042355.A45937@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ianf@clue.co.za on Mon, Sep 10, 2007 at 12:04:10PM +0200 Cc: current@freebsd.org Subject: Re: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 11:25:14 -0000 On Mon, Sep 10, 2007 at 12:04:10PM +0200, Ian FREISLICH wrote: > Hi > > I was wondering if anyone else is having this problem building > asterisk on -CURRENT. The problem may not be with FreeBSD - it > looks like gnu configure is incorrectly detecting the CPU as "i386" > when it's actually a pentium3: > > configure: Package configured for: > configure: OS type : freebsd7.0 > configure: Host CPU : i386 > ===> Building for asterisk-1.4.11 > > The i386 doesn't have any atomic primatives or something like that > (maybe just according to gcc-4.2). If I frob the configured sources > and change the i386 to pentium3, then the build works, but I don't > have enough asterisk foo at this point to verify that it actually > works. i don't completely understand what is happening here - i386 presumably refers to the architecture, not to the very-low-level details of the architecture, so there should not be anything specific to one processor of the family in the flags passed to the compiler. Could it be that it's a compiler bug instead (or something in your /etc/make.conf which is forcing compiler-specific optimizations but only for a part of the build or the libraries) ? cheers luigi > ast_expr2f.o asterisk.o astmm.o autoservice.o callerid.o cdr.o channel.o chanv > ars.o cli.o config.o cryptostub.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o > enum.o file.o fixedjitterbuf.o frame.o fskmodem.o http.o image.o indications.o > io.o jitterbuf.o loader.o logger.o manager.o md5.o netsock.o pbx.o plc.o privacy > .o rtp.o say.o sched.o sha1.o slinfactory.o srv.o stdtime/localtime.o strcompat. > o tdd.o term.o threadstorage.o translate.o udptl.o ulaw.o utils.o editline/libed > it.a -> asterisk > channel.o(.text+0x2b52): In function `ast_channel_alloc': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > channel.o(.text+0x2ec1):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > cli.o(.text+0x3a4a): In function `ast_cli_command': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > dial.o(.text+0x3da): In function `ast_dial_append': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > loader.o(.text+0xe3c): In function `__ast_module_user_add': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > loader.o(.text+0xec9):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/aster > isk/lock.h:775: more undefined references to `__sync_fetch_and_add_4' follow > manager.o(.text+0x197): In function `process_events': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi > ned reference to `__sync_sub_and_fetch_4' > manager.o(.text+0x173e): In function `free_session': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi > ned reference to `__sync_sub_and_fetch_4' > manager.o(.text+0x18ab): In function `accept_thread': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > manager.o(.text+0x1962):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > manager.o(.text+0x1a67):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > manager.o(.text+0x1b15):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > manager.o(.text+0x4774): In function `action_waitevent': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi > ned reference to `__sync_sub_and_fetch_4' > manager.o(.text+0x5f81): In function `generic_http_callback': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > manager.o(.text+0x5f8f):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > manager.o(.text+0x6a65):/usr/ports/net/asterisk/work/asterisk-1.4.11/include/ast > erisk/lock.h:775: undefined reference to `__sync_fetch_and_add_4' > manager.o(.text+0x70b5): In function `session_do': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > utils.o(.text+0xde8): In function `ast_atomic_dec_and_test': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:809: undefi > ned reference to `__sync_sub_and_fetch_4' > utils.o(.text+0xe01): In function `ast_atomic_fetchadd_int': > /usr/ports/net/asterisk/work/asterisk-1.4.11/include/asterisk/lock.h:775: undefi > ned reference to `__sync_fetch_and_add_4' > gmake[1]: *** [asterisk] Error 1 > gmake: *** [main] Error 2 > *** Error code 2 > > Stop in /usr/ports/net/asterisk. > *** Error code 1 > > Stop in /usr/ports/net/asterisk. > > > -- > Ian Freislich > > _______________________________________________ > 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 Mon Sep 10 11:28:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BBF416A419 for ; Mon, 10 Sep 2007 11:28:29 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by mx1.freebsd.org (Postfix) with SMTP id 6018413C45D for ; Mon, 10 Sep 2007 11:28:28 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 66507 invoked from network); 10 Sep 2007 11:28:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=GA7rckr1rktmM7BXEIjEr6oLax1VVB8SvOsXOksO91aDmmz+jcQ44mBzvkoLzrtncJURVxCc3ByeX38A+Fp2VQ4gZqPmoewKPg4meIEoD2z7EzrbhKRa/EZci7fll/G114JylbsZJkXqJ21xrS1POtXMsEit0uMYE1x0es/UE6E= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.133.55.166 with login) by smtp802.mail.ird.yahoo.com with SMTP; 10 Sep 2007 11:28:26 -0000 X-YMail-OSG: ZKXx4hcVM1lecdiFeAmvtkGDDeXNCBYz1j0.nsHnQK0I6Fy9qmfv0u5nTSTugNZyeJHc3R5fgQ-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Mon, 10 Sep 2007 12:28:25 +0100 User-Agent: KMail/1.9.7 References: <046801c7f229$a4534510$ecf9cf30$@co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709101228.25867.Thomas.Sparrevohn@btinternet.com> Subject: Re: dump 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, 10 Sep 2007 11:28:29 -0000 On Monday 10 September 2007 07:14:36 Danny Braniss wrote: > > > > > > the only indication I can see, is that one of the dump procs. is > > > waiting on > > > sbwait, and probably it's some deadlock, which is similar to what I > > > keep > > > seeing here, i'll try now with SCHED_ULE to see if it make a > > > difference. > > > > > > I'm running SCHED_ULE on these already, if your not I guess it's not the > > scheduler? > > > I can get it to 'work' by fiddling with the b flag (blocksize), which still > points to some timming/deadlock problem. > ie: > dump 0abf 64 /some/backup/file /file/to/backup > now works, but > dump 0abf 64 - | restore rbf 64 - > hangs as before. (i don't think the b 64 in restore is needed). I have been able to reproduce the deadlock with any configuration - just using the dump part - never found out what caused it. From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 12:32:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC4E16A420 for ; Mon, 10 Sep 2007 12:32:28 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (bns.tns.cz [213.194.214.115]) by mx1.freebsd.org (Postfix) with ESMTP id 6D31F13C47E for ; Mon, 10 Sep 2007 12:32:25 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (localhost [127.0.0.1]) by bns.tns.cz (Postfix) with ESMTP id 4D37055E401 for ; Mon, 10 Sep 2007 14:32:24 +0200 (CEST) Received: from belzebub.tns.cz (belzebub [192.168.144.3]) by bns.tns.cz with ESMTP id 4DP9PB0000190YQ2PM0; Mon, 10 Sep 2007 14:32:24 +0200 (CEST) Received: by belzebub.tns.cz (Postfix, from userid 1001) id E682616ADBA; Mon, 10 Sep 2007 14:34:51 +0200 (CEST) Date: Mon, 10 Sep 2007 14:34:51 +0200 From: Roman Pavlik To: freebsd-current@freebsd.org Message-ID: <20070910123451.GA2349@belzebub.tns.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.12-2006-07-14 Subject: Compaq HP 6710b freezes on 7-CURRENT-SNAP-200708 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 12:32:28 -0000 Hi, I try to install 7-CURRENT on Compaq HP 6710b because of Intel 865GM support. Unfortunatelly, machine freezes during boot (last message is pci24: on pcib3). 6.2-STABLE works without problem. pciconf -lv attached. Than you for your advice. -- Roman Pavlík hostb0@pci0:0:0: class=0x060000 card=0x30c0103c chip=0x2a008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI none0@pci0:2:0: class=0x030000 card=0x30c0103c chip=0x2a028086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA none1@pci0:2:1: class=0x038000 card=0x30c0103c chip=0x2a038086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' class = display uhci0@pci0:26:0: class=0x0c0300 card=0x30c0103c chip=0x28348086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci1@pci0:26:1: class=0x0c0300 card=0x30c0103c chip=0x28358086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci0@pci0:26:7: class=0x0c0320 card=0x30c0103c chip=0x283a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB none2@pci0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = multimedia pcib1@pci0:28:0: class=0x060400 card=0x30c0103c chip=0x283f8086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib2@pci0:28:1: class=0x060400 card=0x30c0103c chip=0x28418086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:28:2: class=0x060400 card=0x30c0103c chip=0x28438086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uhci2@pci0:29:0: class=0x0c0300 card=0x30c0103c chip=0x28308086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci3@pci0:29:1: class=0x0c0300 card=0x30c0103c chip=0x28318086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci4@pci0:29:2: class=0x0c0300 card=0x30c0103c chip=0x28328086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci1@pci0:29:7: class=0x0c0320 card=0x30c0103c chip=0x28368086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib4@pci0:30:0: class=0x060401 card=0x30c0103c chip=0x24488086 rev=0xf3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x30c0103c chip=0x28158086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x30c0103c chip=0x28508086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = mass storage subclass = ATA atapci1@pci0:31:2: class=0x010601 card=0x30c0103c chip=0x28298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = mass storage none3@pci16:0:0: class=0x028000 card=0x135c103c chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network bge0@pci24:0:0: class=0x020000 card=0x30c0103c chip=0x169314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet cbb0@pci2:4:0: class=0x060700 card=0x30c0103c chip=0x04761180 rev=0xb6 hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 CardBus Controller' class = bridge subclass = PCI-CardBus From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 12:36:10 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE9F16A418 for ; Mon, 10 Sep 2007 12:36:10 +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 C845113C481 for ; Mon, 10 Sep 2007 12:36:09 +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:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=UI63atEUCotG1CDW36ceZAG3C4J7tPKv//QliMvdnhu6P+8zs/8Zr24B5Rj1NvAxyM1Hp/eqD9UrIe9+cSdrh1vPLovH2r3wFRFDcLstH0jmLUhEaGzRWuq1KsL59imrQsVwUwu1vA2+i4Cdib7u4r16kW+nDeFM3DjVY2HUOqRLcBlZMm/sfjAQ18oNJz/x8pqH5/IYQ2WrAmh6pZncPHT/DEfq0QvUf288t3CxLHsg7YIBjDWLDpSto3F8m4fv; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.66) (envelope-from ) id 1IUiUr-0008Qq-Ut; Mon, 10 Sep 2007 12:36:09 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1IUiUG-0007gr-8C; Mon, 10 Sep 2007 12:35:32 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IUiUE-000NkE-7B; Mon, 10 Sep 2007 14:35:30 +0200 To: Luigi Rizzo From: Ian FREISLICH In-Reply-To: Message from Luigi Rizzo of "Mon, 10 Sep 2007 04:23:55 MST." <20070910042355.A45937@xorpc.icir.org> X-Attribution: BOFH Date: Mon, 10 Sep 2007 14:35:30 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 12:36:10 -0000 Luigi Rizzo wrote: > On Mon, Sep 10, 2007 at 12:04:10PM +0200, Ian FREISLICH wrote: > > Hi > > > > I was wondering if anyone else is having this problem building > > asterisk on -CURRENT. The problem may not be with FreeBSD - it > > looks like gnu configure is incorrectly detecting the CPU as "i386" > > when it's actually a pentium3: > > > > configure: Package configured for: > > configure: OS type : freebsd7.0 > > configure: Host CPU : i386 > > ===> Building for asterisk-1.4.11 > > > > The i386 doesn't have any atomic primatives or something like that > > (maybe just according to gcc-4.2). If I frob the configured sources > > and change the i386 to pentium3, then the build works, but I don't > > have enough asterisk foo at this point to verify that it actually > > works. > > i don't completely understand what is happening here - i386 presumably > refers to the architecture, not to the very-low-level details of > the architecture, so there should not be anything specific to > one processor of the family in the flags passed to the compiler. The trouble is that the asterisk build translates this into -march=i386 and -mcpu=i386 or -mtune=i386 which has that low level effect. At least the old asterisk port did this, I haven't yet figured out what the new 1.4.11 asterisk is doing. I'm inclined to believe that i386 in the FreeBSD context means something fundamentally different to the same in the Linux context. > Could it be that it's a compiler bug instead (or something in > your /etc/make.conf which is forcing compiler-specific optimizations > but only for a part of the build or the libraries) ? It builds if I don't set CPUTYPE=p3 in /etc/make.conf. So, I guess that's the fix. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 12:41:36 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2399816A418 for ; Mon, 10 Sep 2007 12:41:36 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id E67F813C494 for ; Mon, 10 Sep 2007 12:41:35 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8ACeFZc046760; Mon, 10 Sep 2007 05:40:15 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8ACeFAE046759; Mon, 10 Sep 2007 05:40:15 -0700 (PDT) (envelope-from rizzo) Date: Mon, 10 Sep 2007 05:40:15 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20070910054015.A46640@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ianf@clue.co.za on Mon, Sep 10, 2007 at 02:35:30PM +0200 Cc: current@freebsd.org Subject: Re: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 12:41:36 -0000 On Mon, Sep 10, 2007 at 02:35:30PM +0200, Ian FREISLICH wrote: > Luigi Rizzo wrote: > > On Mon, Sep 10, 2007 at 12:04:10PM +0200, Ian FREISLICH wrote: > > > Hi > > > > > > I was wondering if anyone else is having this problem building > > > asterisk on -CURRENT. The problem may not be with FreeBSD - it > > > looks like gnu configure is incorrectly detecting the CPU as "i386" > > > when it's actually a pentium3: > > > > > > configure: Package configured for: > > > configure: OS type : freebsd7.0 > > > configure: Host CPU : i386 > > > ===> Building for asterisk-1.4.11 > > > > > > The i386 doesn't have any atomic primatives or something like that > > > (maybe just according to gcc-4.2). If I frob the configured sources > > > and change the i386 to pentium3, then the build works, but I don't > > > have enough asterisk foo at this point to verify that it actually > > > works. ... > > Could it be that it's a compiler bug instead (or something in > > your /etc/make.conf which is forcing compiler-specific optimizations > > but only for a part of the build or the libraries) ? > > It builds if I don't set CPUTYPE=p3 in /etc/make.conf. So, I guess > that's the fix. and there's another curious thing here, which i realised after posting my email - asterisk uses gmake, not bmake, so does gmake read /etc/make.conf too ? Who else uses that file ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 13:06:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5873316A417 for ; Mon, 10 Sep 2007 13:06:21 +0000 (UTC) (envelope-from onemda@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 EE2A413C468 for ; Mon, 10 Sep 2007 13:06:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so201614anc for ; Mon, 10 Sep 2007 06:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=6BPP62BY9foW5aZZeKZHqOGnaCTlbDAB0ZfGjryEwBY=; b=A5k505zneiyeQj5jmvVsQ80yV0oWqy86xQyWA/TPsXRjqlYS/pFpq8QKcMleofG4yt/vnzEv9TNJVh1enkiMa18TntTqqXg4qoYfZyeKZELQrsysrGXUknqAIt4rfjjQWik+DGhB/kNL/2SUoK7k+0QWf0GfazeN3ccoew3bQ5w= 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=MJDaOpV6oiFPGOEDhplSbHJ0azNwCOSDyh/U6EDX3x/ZMj7UMlPZjqU4V/MEdw+P7KKQdZ/4OqAG9YzY9vUt7wKRfpGfml4wVoRl6moAghtrdudhLPy32xPh9nQ2HofqgGT4iTmAcLe/2L3+GregVnvXZzIZzIl4CutGJxVBQW4= Received: by 10.142.82.17 with SMTP id f17mr222002wfb.1189427926925; Mon, 10 Sep 2007 05:38:46 -0700 (PDT) Received: by 10.142.90.1 with HTTP; Mon, 10 Sep 2007 05:38:46 -0700 (PDT) Message-ID: <3a142e750709100538y52d9586bm85cef13dd055ff07@mail.gmail.com> Date: Mon, 10 Sep 2007 12:38:46 +0000 From: "PBM ." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: powerd may lock display if adaptive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 13:06:21 -0000 On current try run this after fresh reboot # powerd -a adaptive -b adaptive -n adaptive then log on as normal user in console and run % primes 44 after some calculations display should freeze, but everything still works, sound is playing, you may stop calculations and start X or change vty but display will not change - still displaying console and prime numbers. I would like if somebody else may this confirm. From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 13:07:19 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B34A16A420; Mon, 10 Sep 2007 13:07:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B957A13C480; Mon, 10 Sep 2007 13:07:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IUiyq-000IAz-3f; Mon, 10 Sep 2007 16:07:17 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8AD74SX042427; Mon, 10 Sep 2007 16:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8AD7434042426; Mon, 10 Sep 2007 16:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Sep 2007 16:07:04 +0300 From: Kostik Belousov To: Nate Lawson Message-ID: <20070910130704.GC53667@deviant.kiev.zoral.com.ua> References: <46E0777A.8070901@root.org> <20070907133901.GL53667@deviant.kiev.zoral.com.ua> <46E45A6D.1010805@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TIEGfCGDzZzDroj5" Content-Disposition: inline In-Reply-To: <46E45A6D.1010805@root.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 7155bbd8d023de41950ebecbe4708355 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1451 [September 10 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 13:07:19 -0000 --TIEGfCGDzZzDroj5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 09, 2007 at 01:41:17PM -0700, Nate Lawson wrote: > Kostik Belousov wrote: > > On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > >> I've done some major rework on the EC driver. This should help with > >> various problems, including timeouts while checking battery status or > >> temperature. The attached patches are for 6.x and 7.x. Please test a= nd > >> let me know if you get any new errors on dmesg or if it fixes things f= or > >> you (especially HP/Compaq laptop owners). > > Ok, I tryed it on Acer 2490-kind of laptop. I see no difference with the > > patch, battery status seems to be reported correctly both before and af= ter > > applying it. > >=20 > > The only thing I want to note is that reboot on the laptop is turned in= to > > poweroff. You said in the followup to original letter that poweroff is > > turned into reboot, I did not checked it; this is opposite. >=20 > Please test this revised version. All it changes is forcing polling > mode back on during reboot/shutdown. I tested with ecng-7b. Both reboot and halt -p worked as expected. Thanks. --TIEGfCGDzZzDroj5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5UF3C3+MBN1Mb4gRAvtSAJ9conuDACy+xhtiUfxYLtWHWbFWUQCdHm6A uhs/oTu5AVV0dN5sJlNNAz0= =l7tf -----END PGP SIGNATURE----- --TIEGfCGDzZzDroj5-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 13:13:42 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B90AA16A417 for ; Mon, 10 Sep 2007 13:13:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 29EF113C46B for ; Mon, 10 Sep 2007 13:13:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A577AC.dip.t-dialin.net [84.165.119.172]) by redbull.bpaserver.net (Postfix) with ESMTP id B1E5A2E185; Mon, 10 Sep 2007 15:13:08 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 695E05B4926; Mon, 10 Sep 2007 15:12:50 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l8ADCn0u054838; Mon, 10 Sep 2007 15:12:49 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 10 Sep 2007 15:12:48 +0200 Message-ID: <20070910151248.2ayzbtrdww40kkso@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 10 Sep 2007 15:12:48 +0200 From: Alexander Leidinger To: Ian FREISLICH References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Luigi Rizzo , current@freebsd.org Subject: Re: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 13:13:42 -0000 Quoting Ian FREISLICH (from Mon, 10 Sep 2007 =20 14:35:30 +0200): > Luigi Rizzo wrote: >> On Mon, Sep 10, 2007 at 12:04:10PM +0200, Ian FREISLICH wrote: >> > Hi >> > >> > I was wondering if anyone else is having this problem building >> > asterisk on -CURRENT. The problem may not be with FreeBSD - it >> > looks like gnu configure is incorrectly detecting the CPU as "i386" >> > when it's actually a pentium3: >> > >> > configure: Package configured for: >> > configure: OS type : freebsd7.0 >> > configure: Host CPU : i386 >> > =3D=3D=3D> Building for asterisk-1.4.11 >> > >> > The i386 doesn't have any atomic primatives or something like that >> > (maybe just according to gcc-4.2). If I frob the configured sources >> > and change the i386 to pentium3, then the build works, but I don't >> > have enough asterisk foo at this point to verify that it actually >> > works. >> >> i don't completely understand what is happening here - i386 presumably >> refers to the architecture, not to the very-low-level details of >> the architecture, so there should not be anything specific to >> one processor of the family in the flags passed to the compiler. > > The trouble is that the asterisk build translates this into -march=3Di386 > and -mcpu=3Di386 or -mtune=3Di386 which has that low level effect. At > least the old asterisk port did this, I haven't yet figured out > what the new 1.4.11 asterisk is doing. > > I'm inclined to believe that i386 in the FreeBSD context means > something fundamentally different to the same in the Linux context. On Linux this is set to the target architecture which shall be =20 supported. Values are i386, i486, i586, ... and maybe some not so =20 generic ones like pentium4 (maybe all values which gcc supports for =20 -march). We just put the architecture of the system (${ARCH}) into it. On =20 FreeBSD-amd64 this is amd64 (linux uses x86_64), for FreeBSD-i386 this =20 is i386, ... I think we don't set it to something else, because nobody cared to do =20 it so far. Now... when you have a look at =20 http://www.Leidinger.net/FreeBSD/port-patches/Mk:bsd.port.mk.diff you =20 will see (if you search for it, the diff contains more than just this =20 patch) how we could do this based upon the value of CPUTYPE (the =20 packages are tailored to the same CPU as the world). Bye, Alexander. --=20 Men of peace usually are [brave]. =09=09-- Spock, "The Savage Curtain", stardate 5906.5 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 13:15:17 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3A016A41A for ; Mon, 10 Sep 2007 13:15:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9B20B13C465 for ; Mon, 10 Sep 2007 13:15:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A577AC.dip.t-dialin.net [84.165.119.172]) by redbull.bpaserver.net (Postfix) with ESMTP id 5BF092E098; Mon, 10 Sep 2007 15:15:11 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 1DC7D5B4926; Mon, 10 Sep 2007 15:14:53 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l8ADEqFr055189; Mon, 10 Sep 2007 15:14:52 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 10 Sep 2007 15:14:52 +0200 Message-ID: <20070910151452.l764p09p2ckg8wcw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 10 Sep 2007 15:14:52 +0200 From: Alexander Leidinger To: Luigi Rizzo References: <20070910054015.A46640@xorpc.icir.org> In-Reply-To: <20070910054015.A46640@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.585, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, SARE_MILLIONSOF 0.32) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Ian FREISLICH , current@freebsd.org Subject: Re: Building asterisk - undefined reference to `__sync_fetch_and_add_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, 10 Sep 2007 13:15:17 -0000 Quoting Luigi Rizzo (from Mon, 10 Sep 2007 05:40:15 -0700): > and there's another curious thing here, which i realised after posting > my email - asterisk uses gmake, not bmake, so does gmake read > /etc/make.conf too ? Who else uses that file ? gmake doesn't read make.conf, but before gmake comes into play, configure is called by our make, which gets its CFLAGS by some magic depending on the value of CPUTYPE. Bye, Alexander. -- SPAGMUMPS: Any of the millions of Styrofoam wads that accompany mail-order items. -- "Sniglets", Rich Hall & Friends http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 13:20:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E26F16A417 for ; Mon, 10 Sep 2007 13:20:59 +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 73D8F13C467 for ; Mon, 10 Sep 2007 13:20:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8ADKb77030472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Sep 2007 16:20:51 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8ADKEvE010220; Mon, 10 Sep 2007 16:20:32 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8ADKCo2010219; Mon, 10 Sep 2007 16:20:12 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 10 Sep 2007 16:20:11 +0300 From: Giorgos Keramidas To: "PBM ." Message-ID: <20070910132011.GB10100@kobe.laptop> References: <3a142e750709100538y52d9586bm85cef13dd055ff07@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750709100538y52d9586bm85cef13dd055ff07@mail.gmail.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.959, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: powerd may lock display if adaptive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 13:20:59 -0000 On 2007-09-10 12:38, "PBM ." wrote: > On current try run this after fresh reboot > # powerd -a adaptive -b adaptive -n adaptive > > then log on as normal user in console and run > % primes 44 > > after some calculations display should freeze, but everything still > works, sound is playing, you may stop calculations and start X or > change vty but display will not change - still displaying console and > prime numbers. > > I would like if somebody else may this confirm. Confirmed. I couldn't really find a way to reproduce these "X display freezes", but they've been plaguing my laptop for a while now. From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 14:19:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C60016A41A for ; Mon, 10 Sep 2007 14:19:53 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 78E8B13C461 for ; Mon, 10 Sep 2007 14:19:52 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A738C.dip.t-dialin.net [84.154.115.140]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l8AEJgsd017539 for ; Mon, 10 Sep 2007 16:19:43 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l8AEJaQc039112 for ; Mon, 10 Sep 2007 16:19:36 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id l8AEJZmD058242 for ; Mon, 10 Sep 2007 16:19:35 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200709101419.l8AEJZmD058242@fire.js.berklix.net> To: freebsd-current@freebsd.org In-reply-to: <74423CD8-F9C1-454D-83BB-0114402C2CCC@jump-ing.de> References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> <74423CD8-F9C1-454D-83BB-0114402C2CCC@jump-ing.de> Comments: In-reply-to Markus Hitter message dated "Mon, 10 Sep 2007 14:14:00 +0200." Date: Mon, 10 Sep 2007 16:19:35 +0200 From: "Julian H. Stacey" Subject: Re: dump 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, 10 Sep 2007 14:19:53 -0000 Markus Hitter wrote: > > Am 10.09.2007 um 10:14 schrieb Danny Braniss: > > > so here are some questions: > > - is the readers/writer split realy needed now? my guess it was > > put in in the old days to get tapes streaming - which is > > btw, > > what's not working. > > Before you put a lot of efforts into this: Why don't you just let > dump/restore die and put functionality, which is needed and unique to > dump, into tar? Bundling the kitchen sink has worried some since first cries of "Emacs = Bloat": Some believe. Some don't. Religious. > Tar is far more popular, today's world is > multiplatform, today's world is multi-filesystem and if you rewrite > dump, you force admins to rewrite their scripts anyways. > > I've always considered it as sub-optimal to have several tools for > one task. Depend if others agree one definition of task. I wouldnt merge dump & restor either. Principle of least suprise, Maintain portability of people & tools between the many flavours of Unix. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 14:45:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DEA416A41A for ; Mon, 10 Sep 2007 14:45:07 +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 AC52813C459 for ; Mon, 10 Sep 2007 14:45:04 +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 l8AELGWl032378; Mon, 10 Sep 2007 08:21:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E552C9.7090106@samsco.org> Date: Mon, 10 Sep 2007 08:20:57 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Aristedes Maniatis References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> In-Reply-To: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> 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]); Mon, 10 Sep 2007 08:21:17 -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 Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 14:45:07 -0000 Aristedes Maniatis wrote: > I've been able to locate some old posts about the Adaptec AIC9410 > chipset. I've acquired one of these in a new server: > > http://www.supermicro.com/products/system/4U/7045/SYS-7045B-3.cfm?PID=TWR > > We are looking to set up 2 SATA drives in a mirrored pair and started > with trying to get it to work under FreeBSD 6. When I couldn't get it to > detect the driver I then tried the most recent August CURRENT snapshot. > It does not appear to recognise the drives either as a RAID set or > separately when booting from the FreeBSD current CD. > > The only historical references I could find were: > > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg79964.html > > where a year ago Scott Long suggests that it might work in HostRAID mode > but not in standalone mode. I've Googled extensively and couldn't find a > description of how HostRAID mode is different to full 'regular' RAID. It > appears to be some sort of RAID where the system CPU does more of the > work, but I'm not sure. > > My questions: > > * is the AIC9410 supported in any version of FreeBSD, whether I am using > the Adaptec HostRAID or just mounting the drives individually? > > * does raidutil (part of ports/systutils/asr-utils) usable with this > chipset? > > No on both accounts, sorry. Maybe in the future. Scott From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 16:26:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BE816A41B; Mon, 10 Sep 2007 16:26:06 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 26C9313C458; Mon, 10 Sep 2007 16:26:05 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l8AGPYH7012979; Mon, 10 Sep 2007 09:25:34 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <46E56FFE.7000208@freebsd.org> Date: Mon, 10 Sep 2007 09:25:34 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, freebsd-current@freebsd.org, 'cpghost' , 'Gavin Atkinson' Subject: Re: dump 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, 10 Sep 2007 16:26:06 -0000 Danny Braniss wrote: > [dump] has been around since the beginin of time, > or at least since Unix V6 :-), and it has been hacked ever since. but now that > most of you never heard of 9track tapes, etc, I was wondering if there is a > point in hacking at > it again. > pros: dump/restore has never failed me till now. > cons: there are other programs tar/cpio/gtar/etc, but they each have their > nits. I think there is real value in a backup/restore option that is specifically designed for UFS volumes. In particular, it's the only way to be comfortably certain that all UFS-specific attributes (ACLs, extended attributes, etc) are correctly backed-up and restored. Tar, cpio, and other similar programs are widely used for purposes other than whole-system backup. As such, they have to balance requirements that simply aren't of interest to dump/restore. Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 16:43:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CCFC16A419 for ; Mon, 10 Sep 2007 16:43:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail16.mail.yandex.net (webmail16.mail.yandex.net [213.180.200.38]) by mx1.freebsd.org (Postfix) with ESMTP id 10AEF13C442 for ; Mon, 10 Sep 2007 16:43:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail16) by mail.yandex.ru id S8675733AbXIJQnK for ; Mon, 10 Sep 2007 20:43:10 +0400 X-Yandex-Spam: 1 Received: from [81.222.112.174] ([81.222.112.174]) by mail.yandex.ru with HTTP; Mon, 10 Sep 2007 20:43:09 +0400 From: "Andrey V. Elsukov" To: scottl@samsco.org In-Reply-To: 1550000000210817830 References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> 1550000000210817830 MIME-Version: 1.0 Message-Id: <1022871189442590@webmail16.yandex.ru> Date: Mon, 10 Sep 2007 20:43:10 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-current@freebsd.org, ari@ish.com.au Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 16:43:16 -0000 Scott Long wrote: > > * is the AIC9410 supported in any version of FreeBSD, whether I am using > > the Adaptec HostRAID or just mounting the drives individually? > > > > * does raidutil (part of ports/systutils/asr-utils) usable with this > > chipset? > > > > > No on both accounts, sorry. Maybe in the future. A stupid question: is it possible that this controller is AHCI capable? -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 17:39:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A71A16A468 for ; Mon, 10 Sep 2007 17:39:12 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [89.185.226.22]) by mx1.freebsd.org (Postfix) with ESMTP id 63CA313C4DA for ; Mon, 10 Sep 2007 17:39:10 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [89.185.226.22]) by nxm.secservers.com (8.13.4/8.13.8) with ESMTP id l8AHd8ws018941 for ; Mon, 10 Sep 2007 19:39:08 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current Content-Type: text/plain Date: Mon, 10 Sep 2007 19:38:58 +0200 Message-Id: <1189445938.1321.5.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: PF NAT regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 17:39:12 -0000 Hello, I have recently upgraded 6.2-STABLE based router to -CURRENT kernel and I found out the following in /etc/pf.conf does not work anymore: ext_if="sis0" nat on $ext_if from ! ($ext_if) to any -> ($ext_if) It works again when I change it to: nat on $ext_if from any to any -> ($ext_if) Michal From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 17:51:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EBBB16A537 for ; Mon, 10 Sep 2007 17:51:36 +0000 (UTC) (envelope-from tmseck-lists@netcologne.de) Received: from smtp3.netcologne.de (smtp3.netcologne.de [194.8.194.66]) by mx1.freebsd.org (Postfix) with ESMTP id ACAE213C474 for ; Mon, 10 Sep 2007 17:51:35 +0000 (UTC) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-244-104.netcologne.de [213.196.244.104]) by smtp3.netcologne.de (Postfix) with SMTP id 84EFA67C5D for ; Mon, 10 Sep 2007 19:22:24 +0200 (CEST) Received: (qmail 868 invoked from network); 10 Sep 2007 17:22:24 -0000 Received: from unknown (HELO bledge.tmseck.homedns.org) (192.168.1.4) by 0 with SMTP; 10 Sep 2007 17:22:24 -0000 Received: from bledge.tmseck.homedns.org (localhost [127.0.0.1]) by bledge.tmseck.homedns.org (8.14.1/8.14.1) with ESMTP id l8AHMN24010653; Mon, 10 Sep 2007 19:22:23 +0200 (CEST) (envelope-from tmseck-lists@netcologne.de) Received: (from thomas@localhost) by bledge.tmseck.homedns.org (8.14.1/8.14.1/Submit) id l8AHMMJu010652; Mon, 10 Sep 2007 19:22:22 +0200 (CEST) (envelope-from tmseck-lists@netcologne.de) X-Authentication-Warning: bledge.tmseck.homedns.org: thomas set sender to tmseck-lists@netcologne.de using -f Date: Mon, 10 Sep 2007 19:22:22 +0200 From: Thomas-Martin Seck To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Message-ID: <20070910172221.GA6504@bledge.tmseck.homedns.org> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms Cc: Subject: Odd segfault during Squid-2.6.16 compilation 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: Mon, 10 Sep 2007 17:51:36 -0000 [x-post to freebsd-current@ and freebsd-ports@, replies should probably go to freebsd-current only since I only observe this issue on 7-CURRENT] All, I am currently struggling with an odd issue that keeps me (or rather miwi@) from updating www/squid to 2.6.16: During the compilation process, Squid uses a helper application cf_gen to build the default squid.conf file from a template file, cf.data. On CURRENT, cf_gen segfaults when processing said file while it works just fine on 6.2-STABLE and 5.5-STABLE. Compiling Squid with gcc 4.2.1 (installed via the package available on ftp.freebsd.org) on 6.2-STABLE works, too. According to miwi, compiling Squid with gcc 3.4 on CURRENT does not fix the issue (is this correct, Martin?). So it seems that this segfault occurs only on CURRENT and even with CFLAGS="-O0 -g" set and is maybe not dependent on the compiler being used. There is no malloc.conf link and MALLOC_OPTIONS are unset. Kernel is a stripped down GENERIC. This problem occurs on my i386 box and on miwi's ports tinderbox (amd64 as well as i386). My CURRENT installation is "FreeBSD 7.0-CURRENT #84: Thu Aug 30 16:48:08 CEST 2007". Trying to debug this gives the following: 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"... Core was generated by `cf_gen'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.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 0x281521d6 in strcmp () from /lib/libc.so.7 (gdb) bt #0 0x281521d6 in strcmp () from /lib/libc.so.7 #1 0x08048db4 in checkDepend (directive=0x282058c0 "external_acl_type", name=0xbfbfe12e "externalAclHelper", types=0x282025e0, entries=0x28207730) at cf_gen.c:133 #2 0x08049534 in main (argc=3, argv=0xbfbfe5e4) at cf_gen.c:284 (gdb) up #1 0x08048db4 in checkDepend (directive=0x282058c0 "external_acl_type", name=0xbfbfe12e "externalAclHelper", types=0x282025e0, entries=0x28207730) at cf_gen.c:133 133 if (strcmp(entry->name, dep->name) == 0) (gdb) p *entry $1 = {name = 0x282069f0 "comment", alias = 0x0, type = 0x0, loc = 0x282069f8 "none", default_value = 0x0, default_if_none = 0x0, comment = 0x0, ifdef = 0x0, doc = 0x28206a00, nocomment = 0x0, array_flag = 0, next = 0x28207700} (gdb) p *dep $2 = {name = 0x22a02270
, next = 0x235022d0} (gdb) quit Does this sound familiar to anyone? From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 18:15:55 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C49716A417 for ; Mon, 10 Sep 2007 18:15:55 +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 9D50213C461 for ; Mon, 10 Sep 2007 18:15:54 +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 l8AI3mX2063600; Mon, 10 Sep 2007 14:03:48 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 10 Sep 2007 14:03:40 -0400 User-Agent: KMail/1.6.2 References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> In-Reply-To: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709101403.41505.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4230/Mon Sep 10 12:39:48 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Aristedes Maniatis Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 18:15:55 -0000 On Monday 10 September 2007 06:49 am, Aristedes Maniatis wrote: > The only historical references I could find were: > > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg79964.html > > where a year ago Scott Long suggests that it might work in HostRAID > mode but not in standalone mode. If someone's interested, non-HostRAID driver for Linux is here: http://www.adaptec.com/en-US/speed/sas/linux/adp94xx-1_0_8-12_src_tgz.htm This driver is dual-licensed under BSD/GPL as it was based on Justin Gibbs' aic7xxx driver, I believe. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 18:22:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52BFE16A418 for ; Mon, 10 Sep 2007 18:22:02 +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 BE3ED13C45D for ; Mon, 10 Sep 2007 18:22:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-064-191-199.pools.arcor-ip.net [88.64.191.199] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IUntX3UGl-00022S; Mon, 10 Sep 2007 20:22:00 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 10 Sep 2007 20:21:53 +0200 User-Agent: KMail/1.9.7 References: <1189445938.1321.5.camel@genius.i.cz> In-Reply-To: <1189445938.1321.5.camel@genius.i.cz> 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="nextPart1929354.U5fSiiLJCJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709102021.58702.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18g6Y/MyV4JfvA2lwD4kZ+NSex0zXdwK2WNoRo Bn/BCUUd8U9fE2hG7mOOQqJV9LYZ+f0d8o3t2ww2wOLipAwUbw NjBZf4VmFnpi4s8WVB2xjveAdEamHnIYIoI6BznZsA= Cc: Michal Mertl Subject: Re: PF NAT regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 18:22:02 -0000 --nextPart1929354.U5fSiiLJCJ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 10 September 2007, Michal Mertl wrote: > Hello, > > I have recently upgraded 6.2-STABLE based router to -CURRENT kernel and > I found out the following in /etc/pf.conf does not work anymore: > > ext_if=3D"sis0" > nat on $ext_if from ! ($ext_if) to any -> ($ext_if) > > It works again when I change it to: > > nat on $ext_if from any to any -> ($ext_if) Can you show me "ifconfig sis0" and "pfctl -vvvsn" for either rule? It=20 might be a problem with picking up aliases correctly. You could also try=20 to limit the nat rule by specifying "inet". A tcpdump on sis0 might also=20 be helpful to figure out what's going on, as could be "pfctl -xm" to=20 enable extended debugging on the console. This should print which=20 address is chosen for any translation. Finally you might want to look at=20 the rule counters and the state table after trying a couple of=20 connections. =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 --nextPart1929354.U5fSiiLJCJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG5YtGXyyEoT62BG0RAn3mAJ9POd7Jg9mQeu/OhWpjV8QaoIGVHACffSB8 P/Cm3/CKch5k7XEQ+xxONDI= =xQ8F -----END PGP SIGNATURE----- --nextPart1929354.U5fSiiLJCJ-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 19:28:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6A516A419 for ; Mon, 10 Sep 2007 19:28:31 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [89.185.226.22]) by mx1.freebsd.org (Postfix) with ESMTP id BFA2513C457 for ; Mon, 10 Sep 2007 19:28:30 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [89.185.226.22]) by nxm.secservers.com (8.13.4/8.13.8) with ESMTP id l8AJS2EA029015; Mon, 10 Sep 2007 21:28:02 +0200 (CEST) (envelope-from mime@traveller.cz) Message-ID: <46E59AB8.3050005@traveller.cz> Date: Mon, 10 Sep 2007 21:27:52 +0200 From: Michal Mertl User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Max Laier References: <1189445938.1321.5.camel@genius.i.cz> <200709102021.58702.max@love2party.net> In-Reply-To: <200709102021.58702.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PF NAT regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 19:28:31 -0000 Max Laier napsal(a): > On Monday 10 September 2007, Michal Mertl wrote: > >> Hello, >> >> I have recently upgraded 6.2-STABLE based router to -CURRENT kernel and >> I found out the following in /etc/pf.conf does not work anymore: >> >> ext_if="sis0" >> nat on $ext_if from ! ($ext_if) to any -> ($ext_if) >> >> It works again when I change it to: >> >> nat on $ext_if from any to any -> ($ext_if) >> > > Can you show me "ifconfig sis0" and "pfctl -vvvsn" for either rule? It > might be a problem with picking up aliases correctly. You could also try > to limit the nat rule by specifying "inet". A tcpdump on sis0 might also > be helpful to figure out what's going on, as could be "pfctl -xm" to > enable extended debugging on the console. This should print which > address is chosen for any translation. Finally you might want to look at > the rule counters and the state table after trying a couple of > connections I am sorry, I can't reproduce the problem myself anymore :-(. I do not understand how could it have happened - it seemed clear to me before - first version -> no NAT vs. second version -> NAT. I am pretty sure I repeated the test several times. And of course NAT did not work as otherwise I would not be trying to change the ruleset. There is only one IP address on the sis0 interface and it is being assigned by DHCP. If I have problems again I will try to better diagnose the situation. Michal From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 20:00:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F9916A418 for ; Mon, 10 Sep 2007 20:00:02 +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 E006113C480 for ; Mon, 10 Sep 2007 20:00:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2C86245E97; Mon, 10 Sep 2007 21:59:59 +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 0E37B45EA4 for ; Mon, 10 Sep 2007 21:59:52 +0200 (CEST) Date: Mon, 10 Sep 2007 21:58:33 +0200 From: Pawel Jakub Dawidek To: current@freebsd.org Message-ID: <20070910195833.GE1103@garage.freebsd.pl> References: <20070906184853.GB90021@roadrunner.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XRI2XbIfl/05pQwm" Content-Disposition: inline In-Reply-To: <20070906184853.GB90021@roadrunner.spoerlein.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 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: Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 20:00:02 -0000 --XRI2XbIfl/05pQwm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2007 at 08:48:53PM +0200, Ulrich Spoerlein wrote: > Hi, it's me again with another stupid question, >=20 > ever since I switched my /usr and /home to ZFS, the system has become > _very_ unresponsive under load. This is not because of CPU load, but I/O > load. Can you try recent HEAD? I committed a change that allows ZFS cache (ARC) to use more memory. This should be safe after dfr@'s vnode leak fix and should also help performance. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XRI2XbIfl/05pQwm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5aHpForvXbEpPzQRAmwbAKDVpJXSlIdcQ0MrI1GZZ3HLWXwZiwCgxTXH MEueDjTFnmRTD88MkAYiU9M= =6pts -----END PGP SIGNATURE----- --XRI2XbIfl/05pQwm-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 20:40:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C1C16A41B for ; Mon, 10 Sep 2007 20:40:47 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id F090713C474 for ; Mon, 10 Sep 2007 20:40:46 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 9CC2923C4CF; Mon, 10 Sep 2007 22:40:45 +0200 (CEST) Date: Mon, 10 Sep 2007 22:40:45 +0200 From: Peter Schuller To: current@freebsd.org Message-ID: <20070910204045.GA89544@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Memory accounting discrepancy in top (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 20:40:47 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, (I realize I am posting alot to -current lately. If people feel I am too quick to flood the lists let me know, but I do try to keep to things that seem relevant for -current.) I have a machine (Dell 2950) where I orignally thought there was a memory visibility problem. It has 4 GB in total which seemed to be detected on boot based on dmesg, yet top showed a total of slightly above 2 GB. I posted to -questions about this in the belief that this was the case from boot onwards. However, I discovered that after boot memory adds up in top, but then goes down. Observe the following progression of top memory and their totals over the course of about a day, on amd64 with CURRENT from 2007-09-09: Mem: 10M Active, 1388K Inact, 84M Wired, 268K Cache, 800K Buf, 3822M Free Total: 3918 Mem: 272M Active, 31M Inact, 650M Wired, 42M Cache, 992K Buf, 1391M Free Total: 2386.9 Mem: 274M Active, 32M Inact, 655M Wired, 52M Cache, 992K Buf, 1372M Free Total: 2385.9 Mem: 282M Active, 31M Inact, 646M Wired, 53M Cache, 992K Buf, 1372M Free Total: 2384.9 Mem: 332M Active, 146M Inact, 719M Wired, 52M Cache, 214M Buf, 1071M Free Total: 2534 Possibly related is that on this machine I also recently saw a strange situation where the amount of "inactive" memory was very high (2.5 gb) when I would have expected 10-400 mb or something along those lines. Even stranger is that if I then ran a memory grabbing process, that memory would go from inactive to active, and then back to FREE when the program terminated. This happened WITHOUT any disk I/O (swapping). This was the reason why I cvsup:ed the machine on -09. My understanding is that memory that is 'inactive' could only be freed for use by another process by either the memory being de-allocated, or going into swap. Thus I am/was unable to explain how the memory could be pushed from inactive to free, by running a process that temporarily gobbled up a few hundred megs of RAM, without seeing corresponding disk I/O. This situation occurred after I had dd:ed 8 gigabytes of zeros onto a file on UFS, mdconfig attached it, and swapon:ed it. It may or may not have been like this immediately before I did this; I do not know for sure. This was after an otherwise fresh boot with nothing big running, which is why the 2.5 GB seemed like a huge number. loader.conf on this machine: vm.kmem_size_max=3D"1258291200" vfs.zfs.prefetch_disable=3D"1" vfs.zfs.arc_max=3D"838860800" geom_label_load=3D"YES" geom_mirror_load=3D"YES" zfs_load=3D"YES" vfs.root.mountfrom=3D"zfs:tank/root" kern.ipc.semmni=3D256 kern.ipc.semmns=3D512 kern.ipc.semmnu=3D256 vmstat -m on the machine as it appears now with the top discrepancy, but NOT necessarily matching the time of the unaccounted-for "inactive" memory. Note that 'solaris' seems higher than it should be given arc_max: Type InUse MemUse HighUse Requests Size(s) DEVFS2 160 10K - 568 16,32,64 DEVFS_RULE 34 16K - 34 64,512 DEVFS 60 2K - 61 16,128 ntfs_nthash 1 512K - 1 =20 pfs_nodes 20 5K - 20 256 GEOM 256 44K - 135264 16,32,64,128,256,512,1024,2048 ata_dma 2 1K - 2 256 isadev 7 1K - 7 128 acd_driver 1 2K - 1 2048 cdev 23 6K - 23 256 sigio 1 1K - 1 64 filedesc 415 328K - 130951 16,32,512,1024,2048,4096 kenv 76 11K - 82 16,32,64 kqueue 120 135K - 164250 256,2048 proc-args 180 9K - 166624 16,32,64,128,256 ithread 96 18K - 96 32,128,256 prison 9 9K - 9 16,64,2048 CAM dev queue 1 1K - 1 128 KTRACE 100 13K - 100 128 CAM queue 3 1K - 3 16 linker 125 260K - 164 16,32,64,128,256,512,1024,2048 lockf 44 6K - 1473726 128 acpisem 15 2K - 15 128 ip6ndp 4 1K - 4 64,128 temp 30 272K - 186563 16,32,64,128,256,512,1024,2048= ,4096 devbuf 16748 35139K - 16847 16,32,64,128,256,512,1024,2048= ,4096 module 376 47K - 376 128 mtx_pool 1 8K - 1 =20 subproc 854 1502K - 88424 512,4096 proc 2 16K - 2 =20 session 88 11K - 18149 128 pgrp 104 13K - 21773 128 cred 279 70K - 2578543 256 uidinfo 19 4K - 7194 64,2048 plimit 98 25K - 87992 256 kbdmux 6 9K - 6 16,256,512,2048,4096 sysctltmp 0 0K - 55695 16,32,64,128 sysctloid 4144 208K - 4194 16,32,64,128 sysctl 0 0K - 34582 16,32,64 umtx 592 74K - 592 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 bus-sc 87 88K - 3128 16,32,64,128,256,512,1024,2048= ,4096 bus 1019 81K - 22677 16,32,64,128,256,1024 devstat 28 57K - 28 32,4096 eventhandler 77 7K - 77 64,128 kobj 235 940K - 5123 4096 md_disk 1 2K - 1 2048 mfibuf 6 139K - 32 32,256,512,2048 rman 114 14K - 584 16,64,128 sbuf 0 0K - 39534 16,32,64,128,256,512,1024,2048= ,4096 CAM SIM 1 1K - 1 256 CAM periph 2 1K - 9 16,32,64,128,256 taskqueue 9 1K - 9 16,32,128 Unitno 9 1K - 55 32,64 iov 0 0K - 833411 16,64,128,256,512,1024,2048 ioctlops 0 0K - 341736 16,32,64,128,256,512,1024,2048= ,4096 msg 4 30K - 4 2048,4096 sem 4 76K - 4 =20 shm 1 16K - 1 =20 ttys 3696 502K - 16667 128,1024 ptys 23 6K - 23 256 acpidev 54 4K - 54 64 mbuf_tag 0 0K - 4322792 32,64 pcb 50 154K - 75751 16,32,64,128,4096 soname 77 9K - 1302904 16,32,128 biobuf 0 0K - 3 2048 vfscache 1 1024K - 1 =20 vfs_hash 1 512K - 1 =20 vnodes 19 1K - 78 32,256 vnodemarker 0 0K - 105700 512 mount 198 8K - 357 16,32,64,128,256 CAM XPT 10 2K - 25 32,64,128,1024 BPF 3 1K - 3 128 ether_multi 15 1K - 16 16,32,64 ifaddr 55 17K - 55 32,64,128,256,512,2048,4096 ifnet 4 7K - 4 256,2048 clone 5 20K - 5 4096 arpcom 2 1K - 2 16 lo 1 1K - 1 32 routetbl 39 7K - 23058 32,64,128,256,512 in_multi 2 1K - 2 64 sctp_iter 0 0K - 6 256 sctp_ifn 2 1K - 2 128 sctp_ifa 7 1K - 7 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 6 16 hostcache 1 36K - 1 =20 tcplog 0 0K - 3341 256 syncache 1 100K - 1 =20 in6_multi 16 1K - 16 32,64,128 pci_link 16 2K - 16 32,128 nfss_daemon 1 16K - 1 =20 audit_evclass 150 5K - 187 32 newblk 1 1K - 1 512 inodedep 1 512K - 1 =20 pagedep 1 128K - 1 =20 ufs_dirhash 771 150K - 771 16,32,64,128,256,512 ufs_mount 6 21K - 6 512,2048,4096 UMAHash 3 14K - 12 512,1024,2048,4096 vm_pgdata 2 129K - 2 128 memdesc 1 4K - 1 4096 acpica 843 74K - 26775 16,32,64,128,256,512,1024 acpitask 0 0K - 1 64 io_apic 2 4K - 2 2048 ata_generic 1 1K - 1 1024 msi 2 1K - 2 128 nexusdev 4 1K - 4 16 entropy 1024 64K - 1024 64 atkbddev 2 1K - 2 64 USBdev 21 8K - 21 16,32,128,256,512 USB 87 19K - 102 16,32,64,128,256,1024 DEVFS1 160 80K - 164 512 DEVFS3 917 230K - 938 256 zones_data 4 1K - 4 16 solaris 1163491 949421K - 217472361 16,32,64,128,256,512,1024,= 2048,4096 kstat_data 1 1K - 1 64 mirror_data 4 2K - 31 64,256,512 linux 14 1K - 14 16,64 ZFS related sysctls (grep zfs): vfs.zfs.arc_min: 39321600 vfs.zfs.arc_max: 838860800 vfs.zfs.mdcomp_disable: 0 vfs.zfs.prefetch_disable: 1 vfs.zfs.zio.taskq_threads: 0 vfs.zfs.recover: 0 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.debug: 0 kstat.zfs.misc.arcstats.hits: 12088667 kstat.zfs.misc.arcstats.misses: 769430 kstat.zfs.misc.arcstats.demand_data_hits: 3589717 kstat.zfs.misc.arcstats.demand_data_misses: 46936 kstat.zfs.misc.arcstats.demand_metadata_hits: 8498950 kstat.zfs.misc.arcstats.demand_metadata_misses: 722494 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 3374213 kstat.zfs.misc.arcstats.mru_ghost_hits: 6831 kstat.zfs.misc.arcstats.mfu_hits: 8714454 kstat.zfs.misc.arcstats.mfu_ghost_hits: 66142 kstat.zfs.misc.arcstats.deleted: 576876 kstat.zfs.misc.arcstats.recycle_miss: 52143 kstat.zfs.misc.arcstats.mutex_miss: 1173 kstat.zfs.misc.arcstats.evict_skip: 61 kstat.zfs.misc.arcstats.hash_elements: 145695 kstat.zfs.misc.arcstats.hash_elements_max: 150128 kstat.zfs.misc.arcstats.hash_collisions: 2187962 kstat.zfs.misc.arcstats.hash_chains: 42687 kstat.zfs.misc.arcstats.hash_chain_max: 12 kstat.zfs.misc.arcstats.p: 479967938 kstat.zfs.misc.arcstats.c: 628830540 kstat.zfs.misc.arcstats.c_min: 39321600 kstat.zfs.misc.arcstats.c_max: 838860800 kstat.zfs.misc.arcstats.size: 628438016 So once again I don't have debugging information/traces available, because I am not sure what would be wanted. If asked for I will provide anything I can provide given the circumstances. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5avMDNor2+l1i30RAuq/AJ9A75j4PBEW3XNCKmaos167qIJk5wCeMler lXN33Y2IfAqgya3n8Ir3TdQ= =StC2 -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 00:52:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C333916A468 for ; Tue, 11 Sep 2007 00:52:35 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 7673413C45D for ; Tue, 11 Sep 2007 00:52:35 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from ip-182.ish.com.au ([203.29.62.182]) by fish.ish.com.au with esmtpa (Exim 4.43) id 1IUtw2-0003w8-7L; Tue, 11 Sep 2007 10:48:58 +1000 In-Reply-To: <1022871189442590@webmail16.yandex.ru> References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> 1550000000210817830 <1022871189442590@webmail16.yandex.ru> Mime-Version: 1.0 (Apple Message framework v752.2) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D8DE815-E4D9-480A-9CD6-A4B2343826CC@ish.com.au> Content-Transfer-Encoding: 7bit From: Aristedes Maniatis Date: Tue, 11 Sep 2007 10:52:30 +1000 To: Andrey V. Elsukov X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 00:52:35 -0000 On 11/09/2007, at 2:43 AM, Andrey V. Elsukov wrote: > A stupid question: is it possible that this controller is AHCI > capable? I couldn't find any reference to AHCI in the bios or in the controller specs. So I think not. In the end we found that this motherboard also had the Intel ESB2 SATA controller on board with 6 SATA ports, so we are successfully using that with current. Thank you Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 00:59:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59A3016A41A for ; Tue, 11 Sep 2007 00:59:10 +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 12B6A13C478 for ; Tue, 11 Sep 2007 00:59: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 l8B0x547035435; Mon, 10 Sep 2007 18:59:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E5E845.9080309@samsco.org> Date: Mon, 10 Sep 2007 18:58:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Jung-uk Kim References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> <200709101403.41505.jkim@FreeBSD.org> In-Reply-To: <200709101403.41505.jkim@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]); Mon, 10 Sep 2007 18:59:06 -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, Aristedes Maniatis Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 00:59:10 -0000 Jung-uk Kim wrote: > On Monday 10 September 2007 06:49 am, Aristedes Maniatis wrote: >> The only historical references I could find were: >> >> http://www.mail-archive.com/freebsd-stable@freebsd.org/msg79964.html >> >> where a year ago Scott Long suggests that it might work in HostRAID >> mode but not in standalone mode. > > If someone's interested, non-HostRAID driver for Linux is here: > > http://www.adaptec.com/en-US/speed/sas/linux/adp94xx-1_0_8-12_src_tgz.htm > > This driver is dual-licensed under BSD/GPL as it was based on Justin > Gibbs' aic7xxx driver, I believe. > Well, it's based on work that Gibbs did before he and I left Adaptec. Porting it will be a very big task; if anyone has a serious interest in this, please contact me in private. Scott From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 01:00:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 313B316A41A for ; Tue, 11 Sep 2007 01:00:24 +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 E016813C45A for ; Tue, 11 Sep 2007 01:00:23 +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 l8B10KSq035468; Mon, 10 Sep 2007 19:00:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E5E890.1090008@samsco.org> Date: Mon, 10 Sep 2007 19:00:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Aristedes Maniatis References: <5C400D5C-7E83-41D2-A66F-C3903D6E1AB1@ish.com.au> 1550000000210817830 <1022871189442590@webmail16.yandex.ru> <9D8DE815-E4D9-480A-9CD6-A4B2343826CC@ish.com.au> In-Reply-To: <9D8DE815-E4D9-480A-9CD6-A4B2343826CC@ish.com.au> 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]); Mon, 10 Sep 2007 19:00:21 -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: "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: AIC9410 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 01:00:24 -0000 Aristedes Maniatis wrote: > > On 11/09/2007, at 2:43 AM, Andrey V. Elsukov wrote: > >> A stupid question: is it possible that this controller is AHCI capable? > > I couldn't find any reference to AHCI in the bios or in the controller > specs. So I think not. In the end we found that this motherboard also > had the Intel ESB2 SATA controller on board with 6 SATA ports, so we are > successfully using that with current. > This device has nothing in common with AHCI. Scott From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 01:19:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE1A16A419 for ; Tue, 11 Sep 2007 01:19:33 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 302DE13C457 for ; Tue, 11 Sep 2007 01:19:32 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IUuPa-0004mn-HQ for ; Tue, 11 Sep 2007 10:19:31 +0900 Message-ID: <46E5ED1E.9040702@fusiongol.com> Date: Tue, 11 Sep 2007 10:19:26 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Xorg detaches one of my hard drives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 01:19:33 -0000 I started up xorg on my Gigabyte GA-G33-DS3R motherboard, which contains 6 drives on the ICH9 SATA interface:-(ad6,ad8,ad10,ad12,ad14,ad16) I Didn't expect to see this kernel message mixed amongst the xorg startup messages though:- subdisk16: detached ad16: detached ...and sure enough, it was no longer in /dev Any clue why xorg feels it has the right to kick one of my drives off the system? Note that the same thing happens whether ICH9 is in RAID or (now working) AHCI mode. IRQ issue? From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 04:11:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 618FB16A419 for ; Tue, 11 Sep 2007 04:11:19 +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 2666513C46E for ; Tue, 11 Sep 2007 04:11:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IUwpy-0001WA-Sc for freebsd-current@freebsd.org; Tue, 11 Sep 2007 05:54:55 +0200 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Sep 2007 05:54:54 +0200 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Sep 2007 05:54:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Mon, 10 Sep 2007 10:28:08 -0700 Lines: 16 Message-ID: References: <2a41acea0705101314s1e711b86rd0b5ac562e0de108@mail.gmail.com> <750ebd430709090513n55e56e71pc03b43fc3b117848@mail.gmail.com> <2a41acea0709091039v3b945ffdkfee7da7d56fac320@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.5 Sender: news Subject: Re: em0: Unable to locate IO BAR ( two 82542 cards ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 04:11:19 -0000 Jack Vogel wrote: > On 9/9/07, Philip Higgins wrote: >> I'm having this same issue (well, identical symptoms) with an 82534. Did >> you get the fix finished? >> >> Tryed with up to date current and two months old, same result. > > Hmmm, this is surprising, I thought this issue was resolved. I > will have a look into this tomorrow morning when I get into work. My 82542's have been working well since you originally fixed this issue. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 04:13:17 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8613F16A468; Tue, 11 Sep 2007 04:13:17 +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 394C113C480; Tue, 11 Sep 2007 04:13:16 +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 l8B4DDTv036142; Mon, 10 Sep 2007 22:13:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E615C4.1010605@samsco.org> Date: Mon, 10 Sep 2007 22:12:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Content-Type: multipart/mixed; boundary="------------070500040300070701010809" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 10 Sep 2007 22:13:13 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED,UPPERCASE_25_50 autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: njl@FreeBSD.ORG Subject: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 04:13:17 -0000 This is a multi-part message in MIME format. --------------070500040300070701010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, The attached patch should make CAM behave properly with regard to probing device serial numbers only when the device advertises that it supports it. It will hopefully eliminate the need for the CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated legacy problem that may or may not be possible to fix). This should especially benefit USB-UMASS devices, where the console output should be less noisy. It might even make more devices work out-of-the-box. So please focus testing on USB, but I'd also ask that people test the following devices as well as any firewire devices: * Western Digital My Book 250GB (USB) * Maxtor Personal Storage 3000XT (Firewire) Thanks, Scott --------------070500040300070701010809 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="cam_xpt.sn0.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cam_xpt.sn0.diff" Index: cam_xpt.c =================================================================== RCS file: /usr/ncvs/src/sys/cam/cam_xpt.c,v retrieving revision 1.190 diff -u -r1.190 cam_xpt.c --- cam_xpt.c 30 Jun 2007 14:58:56 -0000 1.190 +++ cam_xpt.c 11 Sep 2007 04:00:19 -0000 @@ -464,7 +464,7 @@ { /* I can't believe we need a quirk for DPT volumes. */ { T_ANY, SIP_MEDIA_FIXED|SIP_MEDIA_REMOVABLE, "DPT", "*", "*" }, - CAM_QUIRK_NOSERIAL|CAM_QUIRK_NOLUNS, + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/255 }, { @@ -495,7 +495,7 @@ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "EXABYTE", "EXB-8200*", "*" }, - CAM_QUIRK_NOSERIAL|CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, { /* @@ -506,7 +506,7 @@ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "EXABYTE", "IPL-6860*", "*" }, - CAM_QUIRK_NOSERIAL|CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, { /* @@ -551,17 +551,6 @@ }, { /* - * Maxtor Personal Storage 3000XT (Firewire) - * hangs upon serial number probing. - */ - { - T_DIRECT, SIP_MEDIA_FIXED, "Maxtor", - "1394 storage", "*" - }, - CAM_QUIRK_NOSERIAL, /*mintags*/0, /*maxtags*/0 - }, - { - /* * Would repond to all LUNs if asked for. */ { @@ -620,18 +609,6 @@ CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, { - /* - * Western Digital My Book 250GB (USB) - * hangs upon serial number probing. - * PR: 107495 - */ - { - T_DIRECT, SIP_MEDIA_FIXED, "WD", - "2500JB External", "*" - }, - CAM_QUIRK_NOSERIAL, /*mintags*/0, /*maxtags*/0 - }, - { /* Default tagged queuing parameters for all devices */ { T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, @@ -5472,7 +5449,8 @@ PROBE_INQUIRY, /* this counts as DV0 for Basic Domain Validation */ PROBE_FULL_INQUIRY, PROBE_MODE_SENSE, - PROBE_SERIAL_NUM, + PROBE_SERIAL_NUM_0, + PROBE_SERIAL_NUM_1, PROBE_TUR_FOR_NEGOTIATION, PROBE_INQUIRY_BASIC_DV1, PROBE_INQUIRY_BASIC_DV2, @@ -5815,10 +5793,42 @@ } xpt_print(periph->path, "Unable to mode sense control page - " "malloc failure\n"); - softc->action = PROBE_SERIAL_NUM; + softc->action = PROBE_SERIAL_NUM_0; } /* FALLTHROUGH */ - case PROBE_SERIAL_NUM: + case PROBE_SERIAL_NUM_0: + { + struct scsi_vpd_supported_page_list *vpd_list = NULL; + struct cam_ed *device; + + device = periph->path->device; + if ((device->quirk->quirks & CAM_QUIRK_NOSERIAL) == 0) { + vpd_list = malloc(sizeof(*vpd_list), M_CAMXPT, + M_NOWAIT | M_ZERO); + } + + if (vpd_list != NULL) { + scsi_inquiry(csio, + /*retries*/4, + probedone, + MSG_SIMPLE_Q_TAG, + (u_int8_t *)vpd_list, + sizeof(*vpd_list) + 28, + /*evpd*/TRUE, + SVPD_SUPPORTED_PAGE_LIST, + SSD_MIN_SIZE, + /*timeout*/60 * 1000); + break; + } + /* + * We'll have to do without, let our probedone + * routine finish up for us. + */ + start_ccb->csio.data_ptr = NULL; + probedone(periph, start_ccb); + return; + } + case PROBE_SERIAL_NUM_1: { struct scsi_vpd_unit_serial_number *serial_buf; struct cam_ed* device; @@ -5828,10 +5838,8 @@ device->serial_num = NULL; device->serial_num_len = 0; - if ((device->quirk->quirks & CAM_QUIRK_NOSERIAL) == 0) - serial_buf = (struct scsi_vpd_unit_serial_number *) - malloc(sizeof(*serial_buf), M_CAMXPT, - M_NOWAIT | M_ZERO); + serial_buf = (struct scsi_vpd_unit_serial_number *) + malloc(sizeof(*serial_buf), M_CAMXPT, M_NOWAIT|M_ZERO); if (serial_buf != NULL) { scsi_inquiry(csio, @@ -6056,7 +6064,7 @@ if (INQ_DATA_TQ_ENABLED(inq_buf)) softc->action = PROBE_MODE_SENSE; else - softc->action = PROBE_SERIAL_NUM; + softc->action = PROBE_SERIAL_NUM_0; path->device->flags &= ~CAM_DEV_UNCONFIGURED; @@ -6121,11 +6129,61 @@ } xpt_release_ccb(done_ccb); free(mode_hdr, M_CAMXPT); - softc->action = PROBE_SERIAL_NUM; + softc->action = PROBE_SERIAL_NUM_0; xpt_schedule(periph, priority); return; } - case PROBE_SERIAL_NUM: + case PROBE_SERIAL_NUM_0: + { + struct ccb_scsiio *csio; + struct scsi_vpd_supported_page_list *page_list; + int length, serialnum_supported, i; + + serialnum_supported = 0; + csio = &done_ccb->csio; + page_list = + (struct scsi_vpd_supported_page_list *)csio->data_ptr; + + if (page_list == NULL) { + /* + * Don't process the command as it was never sent + */ + } else if ((csio->ccb_h.status & CAM_STATUS_MASK) == CAM_REQ_CMP + && (page_list->length > 0)) { + length = min(page_list->length, csio->dxfer_len - 4); + for (i = 0; i < length; i++) { + if (page_list->list[i] == + SVPD_UNIT_SERIAL_NUMBER) { + serialnum_supported = 1; + break; + } + } + } else if (cam_periph_error(done_ccb, 0, + SF_RETRY_UA|SF_NO_PRINT, + &softc->saved_ccb) == ERESTART) { + return; + } else if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) { + /* Don't wedge the queue */ + xpt_release_devq(done_ccb->ccb_h.path, /*count*/1, + /*run_queue*/TRUE); + } + + if (page_list != NULL) + free(page_list, M_DEVBUF); + + if (serialnum_supported) { + xpt_release_ccb(done_ccb); + softc->action = PROBE_SERIAL_NUM_1; + xpt_schedule(periph, priority); + return; + } + xpt_release_ccb(done_ccb); + softc->action = PROBE_TUR_FOR_NEGOTIATION; + xpt_schedule(periph, done_ccb->ccb_h.pinfo.priority); + return; + } + + case PROBE_SERIAL_NUM_1: { struct ccb_scsiio *csio; struct scsi_vpd_unit_serial_number *serial_buf; Index: scsi/scsi_all.h =================================================================== RCS file: /usr/ncvs/src/sys/cam/scsi/scsi_all.h,v retrieving revision 1.28 diff -u -r1.28 scsi_all.h --- scsi/scsi_all.h 4 Dec 2006 23:04:13 -0000 1.28 +++ scsi/scsi_all.h 11 Sep 2007 03:10:52 -0000 @@ -663,6 +663,17 @@ u_int8_t vendor_specific1[SID_VENDOR_SPECIFIC_1_SIZE]; }; +struct scsi_vpd_supported_page_list +{ + u_int8_t device; + u_int8_t page_code; +#define SVPD_SUPPORTED_PAGE_LIST 0x00 + u_int8_t reserved; + u_int8_t length; /* number of VPD entries */ +#define SVPD_SUPPORTED_PAGES_SIZE 251 + u_int8_t list[SVPD_SUPPORTED_PAGES_SIZE]; +}; + struct scsi_vpd_unit_serial_number { u_int8_t device; --------------070500040300070701010809-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 04:32:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F56E16A418 for ; Tue, 11 Sep 2007 04:32:01 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 09D4413C467 for ; Tue, 11 Sep 2007 04:32:00 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by wa-out-1112.google.com with SMTP id k17so1817174waf for ; Mon, 10 Sep 2007 21:32:00 -0700 (PDT) Received: by 10.142.100.1 with SMTP id x1mr269053wfb.1189485120552; Mon, 10 Sep 2007 21:32:00 -0700 (PDT) Received: by 10.142.203.18 with HTTP; Mon, 10 Sep 2007 21:32:00 -0700 (PDT) Message-ID: <626eb4530709102132t7f17ec37lf4ef1c11874fde0c@mail.gmail.com> Date: Tue, 11 Sep 2007 13:32:00 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Scott Long" In-Reply-To: <46E615C4.1010605@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E615C4.1010605@samsco.org> X-Google-Sender-Auth: 702738c47f804857 Cc: freebsd-scsi@freebsd.org, njl@freebsd.org, freebsd-current@freebsd.org Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 04:32:01 -0000 On 9/11/07, Scott Long wrote: > All, > > The attached patch should make CAM behave properly with regard to > probing device serial numbers only when the device advertises that > it supports it. It will hopefully eliminate the need for the > CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated > legacy problem that may or may not be possible to fix). This should > especially benefit USB-UMASS devices, where the console output should > be less noisy. It might even make more devices work out-of-the-box. > So please focus testing on USB, but I'd also ask that people test > the following devices as well as any firewire devices: > > * Western Digital My Book 250GB (USB) > * Maxtor Personal Storage 3000XT (Firewire) As far as I tested a few months ago, the quirk for Maxtor 3000XT is not necessary any more, though I don't know why. Please remove it. -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 04:53:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 832DF16A417; Tue, 11 Sep 2007 04:53:04 +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 41CDC13C458; Tue, 11 Sep 2007 04:53:03 +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 l8B4r05e036282; Mon, 10 Sep 2007 22:53:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E61F17.7050504@samsco.org> Date: Mon, 10 Sep 2007 22:52:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <46E615C4.1010605@samsco.org> <20070911042517.GA18197@nargothrond.kdm.org> In-Reply-To: <20070911042517.GA18197@nargothrond.kdm.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]); Mon, 10 Sep 2007 22:53:01 -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, njl@freebsd.org, freebsd-current@freebsd.org Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 04:53:04 -0000 Kenneth D. Merry wrote: > On Mon, Sep 10, 2007 at 22:12:52 -0600, Scott Long wrote: >> All, >> >> The attached patch should make CAM behave properly with regard to >> probing device serial numbers only when the device advertises that >> it supports it. It will hopefully eliminate the need for the >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated >> legacy problem that may or may not be possible to fix). This should >> especially benefit USB-UMASS devices, where the console output should >> be less noisy. It might even make more devices work out-of-the-box. >> So please focus testing on USB, but I'd also ask that people test >> the following devices as well as any firewire devices: >> >> * Western Digital My Book 250GB (USB) >> * Maxtor Personal Storage 3000XT (Firewire) > > Good idea. I wonder, though, whether devices that hang or otherwise blow > up on a serial number inquiry would also have trouble with the supported > pages VPD page. All the more reason we'll need people with the quirked > hardware to test it... > > Ken I'm pretty sure that VPD page 0x00 is part of WHQL, so there's a good chance that just about anything made in the last 10 years will support it sanely. Support should extend much further back since it was clearly defined in the SCSI-2 spec, though we both know how muddy that argument is. Scott From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 05:08:37 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CBA16A418; Tue, 11 Sep 2007 05:08:37 +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 94EE613C461; Tue, 11 Sep 2007 05:08:37 +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 l8B58YOJ036358; Mon, 10 Sep 2007 23:08:34 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E622BE.6050108@samsco.org> Date: Mon, 10 Sep 2007 23:08:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hidetoshi Shimokawa References: <46E615C4.1010605@samsco.org> <626eb4530709102132t7f17ec37lf4ef1c11874fde0c@mail.gmail.com> In-Reply-To: <626eb4530709102132t7f17ec37lf4ef1c11874fde0c@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]); Mon, 10 Sep 2007 23:08:34 -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, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 05:08:37 -0000 Hidetoshi Shimokawa wrote: > On 9/11/07, Scott Long wrote: >> All, >> >> The attached patch should make CAM behave properly with regard to >> probing device serial numbers only when the device advertises that >> it supports it. It will hopefully eliminate the need for the >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated >> legacy problem that may or may not be possible to fix). This should >> especially benefit USB-UMASS devices, where the console output should >> be less noisy. It might even make more devices work out-of-the-box. >> So please focus testing on USB, but I'd also ask that people test >> the following devices as well as any firewire devices: >> >> * Western Digital My Book 250GB (USB) >> * Maxtor Personal Storage 3000XT (Firewire) > > As far as I tested a few months ago, the quirk for Maxtor 3000XT is > not necessary > any more, though I don't know why. > > Please remove it. > It looks like a crude hack was added to the sbp firewire driver to short circuit exactly what my patch is trying to fix. Scott From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 08:55:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C6CE16A41A for ; Tue, 11 Sep 2007 08:55:55 +0000 (UTC) (envelope-from shiftyphil@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 533BD13C45A for ; Tue, 11 Sep 2007 08:55:55 +0000 (UTC) (envelope-from shiftyphil@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1183530rvb for ; Tue, 11 Sep 2007 01:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=nrTVzyRn7dx8XL4Oafu+s/9cobhS7JBlQPEe0z1f/dU=; b=H9noeHfpkpEaeRMNK9nAio6zonqxJDh5zQUwbrq/OCievahoSroElhCt5Lv7wlliiMcYkyn2MMDdoX+Xd1Bfw2gddljjOKzQq64/NBAgT5aUSioWM++Q058pFYzF9iq+EHHulP6JAVlgZKmLWEj0euZB/dr/OtcXMjrKCBefsdI= 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=oDKvE7C98xtU6ygJ4Bc85LbdgV+FHipJcutiUHE+K/g6C+qTRxIh5oq+fFaRUBQ/TW0VJ6M9BANrir6b7s6ELRJBZPp9sTs2SAh+0Mfbc9pVd0cI3ie58rT/p5vfJXV2/KujjTeznSEPkrKBlYDZbaVXhVyFJM+YrqF5fVTGOjQ= Received: by 10.141.74.17 with SMTP id b17mr2239182rvl.1189500954862; Tue, 11 Sep 2007 01:55:54 -0700 (PDT) Received: by 10.140.203.20 with HTTP; Tue, 11 Sep 2007 01:55:54 -0700 (PDT) Message-ID: <750ebd430709110155o436f12fas8c36143328900d2c@mail.gmail.com> Date: Tue, 11 Sep 2007 18:55:54 +1000 From: "Philip Higgins" To: "Mark Atkinson" In-Reply-To: MIME-Version: 1.0 References: <2a41acea0705101314s1e711b86rd0b5ac562e0de108@mail.gmail.com> <750ebd430709090513n55e56e71pc03b43fc3b117848@mail.gmail.com> <2a41acea0709091039v3b945ffdkfee7da7d56fac320@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: em0: Unable to locate IO BAR ( two 82542 cards ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 08:55:55 -0000 Fixed for my 82543 this morning. Still not working for an "82534", but since that's just a dyslexic typo and not a real card, it's not a surprise. Thanks Jack. -- Philip Higgins. On 9/11/07, Mark Atkinson wrote: > > Jack Vogel wrote: > > > On 9/9/07, Philip Higgins < shiftyphil@gmail.com> wrote: > >> I'm having this same issue (well, identical symptoms) with an 82534. > Did > >> you get the fix finished? > >> > >> Tryed with up to date current and two months old, same result. > > > > Hmmm, this is surprising, I thought this issue was resolved. I > > will have a look into this tomorrow morning when I get into work. > > My 82542's have been working well since you originally fixed this issue. > -- > Mark Atkinson > atkin901@yahoo.com > (!wired)?(coffee++):(wired); > > _______________________________________________ > 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 Sep 11 09:24:26 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C07816A417; Tue, 11 Sep 2007 09:24:26 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id A9DC813C47E; Tue, 11 Sep 2007 09:24:25 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.12] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IV1ym-0004s3-N4; Tue, 11 Sep 2007 11:24:20 +0200 Received: from x0221.x.pppool.de ([89.59.2.33]:55955 helo=peedub.jennejohn.org) by mx2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68-dev #12) id 1IV1ym-0006LE-Gg; Tue, 11 Sep 2007 11:24:20 +0200 Date: Tue, 11 Sep 2007 11:24:19 +0200 From: Gary Jennejohn To: "Hidetoshi Shimokawa" Message-ID: <20070911112419.68e8ec0d@peedub.jennejohn.org> In-Reply-To: <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> Organization: DENX Softwre Engineering GmbH X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.13; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.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, 11 Sep 2007 09:24:26 -0000 On Thu, 23 Aug 2007 11:37:20 +0900 "Hidetoshi Shimokawa" wrote: > It looks that the low level console is not locked though the high level console > is locked by Giant. > > Could you try the attached patch? > This patch solves the problem and should definitely be committed bfore 7.0. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 10:58:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE6216A418 for ; Tue, 11 Sep 2007 10:58:13 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (bns.tns.cz [213.194.214.115]) by mx1.freebsd.org (Postfix) with ESMTP id BBB5F13C459 for ; Tue, 11 Sep 2007 10:58:12 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (localhost [127.0.0.1]) by bns.tns.cz (Postfix) with ESMTP id 1090F55E401 for ; Tue, 11 Sep 2007 12:58:11 +0200 (CEST) Received: from belzebub.tns.cz (belzebub [192.168.144.3]) by bns.tns.cz with ESMTP id 4DPJKO8000197YQTC3H; Tue, 11 Sep 2007 12:58:10 +0200 (CEST) Received: by belzebub.tns.cz (Postfix, from userid 1001) id 5064C16ADB7; Tue, 11 Sep 2007 13:00:39 +0200 (CEST) Date: Tue, 11 Sep 2007 13:00:39 +0200 From: Roman Pavlik To: freebsd-current@freebsd.org Message-ID: <20070911110039.GA5518@belzebub.tns.cz> References: <20070910123451.GA2349@belzebub.tns.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070910123451.GA2349@belzebub.tns.cz> User-Agent: Mutt/1.5.12-2006-07-14 Subject: 7-current freeze on HP6710b with BroadCom (bge0) (was: Compaq HPCompaq HP 6710b freezes on 7-CURRENT-SNAP-200708) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 10:58:13 -0000 The problems was identified: first) 7-current freeze on HP6710b if acpi.ko is loaded. The workaround is to boot it without acpi. second) 7-current freeze on HP6710b (even without acpi) if BroadCom ethernet is enabled in BIOS. The workaround is to disable Ethernet in BIOS. pciconf -lv said: vendor = 'Broadcom Corporation' class = network subclass = ethernet cbb0@pci2:4:0: class=0x060700 card=0x30c0103c chip=0x04761180 rev=0xb6 hdr=0x02 Please note that support for the chip=0x04761180 was added to the FreeBSD 6.2-stable and is not included in the 6.2-release. Please note also that the FreeBSD 6-2 stable works on this machine without any problem (both chip=0x04761180 and acpi works fine). Regards, -- Roman On Mon, Sep 10, 2007 at 02:34:51PM +0200, Roman Pavlik wrote: > Hi, > I try to install 7-CURRENT on Compaq HP 6710b because of Intel 865GM support. > Unfortunatelly, machine freezes during boot (last message is > pci24: on pcib3). > > 6.2-STABLE works without problem. pciconf -lv attached. Than you for > your advice. > > -- > Roman Pavlík > > hostb0@pci0:0:0: class=0x060000 card=0x30c0103c chip=0x2a008086 rev=0x0c hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > none0@pci0:2:0: class=0x030000 card=0x30c0103c chip=0x2a028086 rev=0x0c hdr=0x00 > vendor = 'Intel Corporation' > class = display > subclass = VGA > none1@pci0:2:1: class=0x038000 card=0x30c0103c chip=0x2a038086 rev=0x0c hdr=0x00 > vendor = 'Intel Corporation' > class = display > uhci0@pci0:26:0: class=0x0c0300 card=0x30c0103c chip=0x28348086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci1@pci0:26:1: class=0x0c0300 card=0x30c0103c chip=0x28358086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci0@pci0:26:7: class=0x0c0320 card=0x30c0103c chip=0x283a8086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > none2@pci0:27:0: class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = multimedia > pcib1@pci0:28:0: class=0x060400 card=0x30c0103c chip=0x283f8086 rev=0x03 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib2@pci0:28:1: class=0x060400 card=0x30c0103c chip=0x28418086 rev=0x03 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib3@pci0:28:2: class=0x060400 card=0x30c0103c chip=0x28438086 rev=0x03 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uhci2@pci0:29:0: class=0x0c0300 card=0x30c0103c chip=0x28308086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci3@pci0:29:1: class=0x0c0300 card=0x30c0103c chip=0x28318086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci4@pci0:29:2: class=0x0c0300 card=0x30c0103c chip=0x28328086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci1@pci0:29:7: class=0x0c0320 card=0x30c0103c chip=0x28368086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pcib4@pci0:30:0: class=0x060401 card=0x30c0103c chip=0x24488086 rev=0xf3 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:31:0: class=0x060100 card=0x30c0103c chip=0x28158086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-ISA > atapci0@pci0:31:1: class=0x01018a card=0x30c0103c chip=0x28508086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = mass storage > subclass = ATA > atapci1@pci0:31:2: class=0x010601 card=0x30c0103c chip=0x28298086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = mass storage > none3@pci16:0:0: class=0x028000 card=0x135c103c chip=0x42228086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = network > bge0@pci24:0:0: class=0x020000 card=0x30c0103c chip=0x169314e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > cbb0@pci2:4:0: class=0x060700 card=0x30c0103c chip=0x04761180 rev=0xb6 hdr=0x02 > vendor = 'Ricoh Co Ltd' > device = 'RL5c476 CardBus Controller' > class = bridge > subclass = PCI-CardBus > -- Roman Pavlík CEO Trusted Network Solutions, a.s. mobil: +420 603 728 545 [ www.tns.cz ] From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 11:30:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7076E16A417 for ; Tue, 11 Sep 2007 11:30:56 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [89.185.226.22]) by mx1.freebsd.org (Postfix) with ESMTP id DF09713C45D for ; Tue, 11 Sep 2007 11:30:55 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [89.185.226.22]) by nxm.secservers.com (8.13.4/8.13.8) with ESMTP id l8BBUrKJ030310 for ; Tue, 11 Sep 2007 13:30:54 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current Content-Type: text/plain Date: Tue, 11 Sep 2007 13:30:44 +0200 Message-Id: <1189510244.1378.24.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: ath(4) apbridge does not work with PF and ALTQ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 11:30:56 -0000 Hello, I found out that "apbridge"ing with ath(4) does not work once I enable altq on the interface with pfctl on recent CURRENT. I can communicate between different hosts connected to ath(4) in hostap mode when altq is not configured and it does not work for any protocol (even for ARP) when it is enabled. Now that I found out why it sometimes worked and sometimes not I think it had not been working for some time - from 6.2 on at least. >From /etc/pf.conf: ------ int_if="ath0" altq on $int_if bandwidth 10Mb cbq queue { dflt, mini } queue dflt bandwidth 1Mb cbq(default, borrow, ecn) queue mini bandwidth 256Kb ------ Dmesg: ------ ath_rate: version 1.2 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0x80000000-0x8000ffff irq 12 at device 13.0 on pci0 ath0: mac 5.9 phy 4.3 radio 3.6 ------ ifconfig ath0: ------ ath0: flags=8843 metric 0 mtu 1500 ether 00:0b:6b:35:be:6f inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid mig_ap_xx channel 1 (2412 Mhz 11g) bssid 00:0b:6b:35:be:6f authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 39 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 14 roam:rate11g 5 protmode CTS burst -apbridge dtimperiod 1 bintval 100 ------ Michal From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 12:18:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF43116A418 for ; Tue, 11 Sep 2007 12:18:08 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFC013C467 for ; Tue, 11 Sep 2007 12:18:08 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8BCGrgj062063; Tue, 11 Sep 2007 05:16:53 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8BCGrWp062062; Tue, 11 Sep 2007 05:16:53 -0700 (PDT) (envelope-from rizzo) Date: Tue, 11 Sep 2007 05:16:53 -0700 From: Luigi Rizzo To: Yan Message-ID: <20070911051653.A62022@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com>; from rottled@gmail.com on Fri, Sep 07, 2007 at 09:54:35AM -0400 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 12:18:08 -0000 On Fri, Sep 07, 2007 at 09:54:35AM -0400, Yan wrote: > How about this: > > #define MY_MAGIC ((sizeof(intptr_t)==4) ? 0Xdeadbeef : 0xdeadbeefd00de123) gcc 3.4 on a 32bit machine complains because the second constant is too large. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 12:36:07 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F4A16A417 for ; Tue, 11 Sep 2007 12:36:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 53A1813C45E for ; Tue, 11 Sep 2007 12:36:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IV4yD-000Bgr-CI for current@freebsd.org; Tue, 11 Sep 2007 15:36:05 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8BCZuJ7092080; Tue, 11 Sep 2007 15:35:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8BCZucV092079; Tue, 11 Sep 2007 15:35:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Sep 2007 15:35:56 +0300 From: Kostik Belousov To: Luigi Rizzo Message-ID: <20070911123556.GF53667@deviant.kiev.zoral.com.ua> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> <20070911051653.A62022@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+GiWpZ/vZzfY9+ZQ" Content-Disposition: inline In-Reply-To: <20070911051653.A62022@xorpc.icir.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 5bcd58edb95cdacf596e852bfe0375ec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1455 [September 11 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Yan , current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 12:36:07 -0000 --+GiWpZ/vZzfY9+ZQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2007 at 05:16:53AM -0700, Luigi Rizzo wrote: > On Fri, Sep 07, 2007 at 09:54:35AM -0400, Yan wrote: > > How about this: > >=20 > > #define MY_MAGIC ((sizeof(intptr_t)=3D=3D4) ? 0Xdeadbeef : 0xdeadbeefd0= 0de123) >=20 > gcc 3.4 on a 32bit machine complains because the second constant > is too large. 0xdeadbeefd00de123LL ? --+GiWpZ/vZzfY9+ZQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5ousC3+MBN1Mb4gRAmJ8AJ99k+9eFQabNvLdOjB1bzwgznffqgCg4tAE wPJVoflu5ydRTZrYxlS6c5A= =6UYc -----END PGP SIGNATURE----- --+GiWpZ/vZzfY9+ZQ-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 12:53:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A97516A419 for ; Tue, 11 Sep 2007 12:53:45 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 529D813C491 for ; Tue, 11 Sep 2007 12:53:45 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8BCqRuE062792; Tue, 11 Sep 2007 05:52:27 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8BCqRvD062791; Tue, 11 Sep 2007 05:52:27 -0700 (PDT) (envelope-from rizzo) Date: Tue, 11 Sep 2007 05:52:27 -0700 From: Luigi Rizzo To: Andrew Milton Message-ID: <20070911055227.F62214@xorpc.icir.org> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> <20070911051653.A62022@xorpc.icir.org> <20070911123556.GF53667@deviant.kiev.zoral.com.ua> <20070911124857.GW4840@camelot.theinternet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070911124857.GW4840@camelot.theinternet.com.au>; from akm@theinternet.com.au on Tue, Sep 11, 2007 at 10:48:57PM +1000 Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 12:53:45 -0000 On Tue, Sep 11, 2007 at 10:48:57PM +1000, Andrew Milton wrote: > On Tue, Sep 11, 2007 at 05:16:53AM -0700, Luigi Rizzo wrote: > > > > gcc 3.4 on a 32bit machine complains because the second constant > > is too large. > > Can I ask why the 64 bit constant isn't 0xd00de123deadbeef , which would make > bits 0-31 the same for both architectures, which might simplify the problem. because i want to run with very strict compiler checks and implicit truncation is always flagged as a Bad Thing(TM). cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 13:25:01 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F2416A417 for ; Tue, 11 Sep 2007 13:25:01 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE1C13C46A for ; Tue, 11 Sep 2007 13:25:00 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from camelot.theinternet.com.au (c211-30-133-243.carlnfd4.nsw.optusnet.com.au [211.30.133.243]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8BDOvFr001695; Tue, 11 Sep 2007 23:24:58 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id AFE266113; Tue, 11 Sep 2007 23:24:57 +1000 (EST) Date: Tue, 11 Sep 2007 23:24:57 +1000 From: Andrew Milton To: Luigi Rizzo Message-ID: <20070911132457.GY4840@camelot.theinternet.com.au> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> <20070911051653.A62022@xorpc.icir.org> <20070911123556.GF53667@deviant.kiev.zoral.com.ua> <20070911124857.GW4840@camelot.theinternet.com.au> <20070911055227.F62214@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070911055227.F62214@xorpc.icir.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 13:25:01 -0000 +-------[ Luigi Rizzo ]---------------------- | On Tue, Sep 11, 2007 at 10:48:57PM +1000, Andrew Milton wrote: | > On Tue, Sep 11, 2007 at 05:16:53AM -0700, Luigi Rizzo wrote: | > > | > > gcc 3.4 on a 32bit machine complains because the second constant | > > is too large. | > | > Can I ask why the 64 bit constant isn't 0xd00de123deadbeef , which would make | > bits 0-31 the same for both architectures, which might simplify the problem. | | because i want to run with very strict compiler checks and implicit | truncation is always flagged as a Bad Thing(TM). But even if you don't do implicit truncation, filling in the 'new' bits with a constant rather than shifting and filling the bottom bits would give you more options, or a better class of options? -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 17:02:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2B2D16A419 for ; Tue, 11 Sep 2007 17:02:53 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id DC2A013C474 for ; Tue, 11 Sep 2007 17:02:53 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by rv-out-0910.google.com with SMTP id l15so1279393rvb for ; Tue, 11 Sep 2007 10:02:53 -0700 (PDT) Received: by 10.141.42.10 with SMTP id u10mr264850rvj.1189528641937; Tue, 11 Sep 2007 09:37:21 -0700 (PDT) Received: by 10.141.21.1 with HTTP; Tue, 11 Sep 2007 09:37:21 -0700 (PDT) Message-ID: Date: Tue, 11 Sep 2007 18:37:21 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11244_33392458.1189528641937" Subject: Problems updating from 6.2-STABLE to -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, 11 Sep 2007 17:02:54 -0000 ------=_Part_11244_33392458.1189528641937 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkhCgpBZnRlciBjdnN1cGVkIG15IC91c3Ivc3JjLCBhbmQgbG9va2VkIGZvciBhbnkgInRpcCIg aW50byBVUERBVElORwpmaWxlLCBJJ20gcnVubmluZyBhICJtYWtlIGJ1aWxkd29ybGQiIChhZnRl ciBhIG1ha2UgY2xlYW4gb2JqKSB0bwpvYnRhaW4gYSAtQ1VSUkVOVCBzeXN0ZW0uIEJ1dCBpdCdz IGhhbmdpbmcgd2l0aCB0aGlzIGVycm9yOgoKL3Vzci9sb2NhbC9saWJleGVjL2NjYWNoZS93b3Js ZC1jYyAtT3MgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUKLURJTl9HQ0MgLURIQVZFX0NPTkZJ R19IIC1EUFJFRklYPVwiL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyXCIKLUkvdXNyL29iai91c3Iv c3JjL3RtcC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX2ludC8uLi9jY190b29scwotSS91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX2ludC8uLi9jY190b29scwotSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX2ludC8uLi8uLi8uLi8uLi9jb250cmliL2djYwotSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX2ludC8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcKLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY19pbnQvLi4vLi4vLi4vLi4vY29udHJpYi9nY2NsaWJzL2luY2x1ZGUK LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY19pbnQvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Ns aWJzL2xpYmNwcC9pbmNsdWRlCi1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfaW50Ly4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjbGlicy9saWJkZWNudW1iZXIKIC1JL3Vzci9vYmovdXNyL3NyYy90 bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jCi4uL2NjX3Rvb2xzL2luc24tYXR0cnRhYi5jCgpjYzE6 IG91dCBvZiBtZW1vcnkgYWxsb2NhdGluZyAxMzY0NzUzOTIgYnl0ZXMKKioqIEVycm9yIGNvZGUg MQoKU3RvcCBpbiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY19pbnQuCioqKiBFcnJvciBjb2Rl IDEKClN0b3AgaW4gL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MuCioqKiBFcnJvciBjb2RlIDEKClN0 b3AgaW4gL3Vzci9zcmMuCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMuCioqKiBF cnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMuCgpXZWxsLCBJJ20gdXNpbmcgImNjYWNoZSIs IGFuZCBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBjb252ZW5pZW50IHRvCnRoaXMgdHlwZSBvZiB1 cGdyYWRlIG9yIG5vdC4KQWxzbywgYXR0YWNoZWQgdG8gdGhlIG1haWwgYXJlIHRoZSBmaWxlcyB3 aXRoIHRoZSAiZG1lc2ciLCAidW5hbWUgLWEiCmFuZCAicGNpY29uZiAtbCAtdiIgb2YgbXkgbGFw dG9wLgoKVGhhbmsgeW91IHZlcnkgbXVjaCBhbmQgcGxlYXNlLCBleGN1c2UgbWUgbXkgYmFkIGVu Z2xpc2guCgotLSAKSGF2ZSBhIG5pY2UgZGF5ICA7LSkKVG9vTWFueVNlY3JldHMKCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KRGlqbyBDb25mdWNpbzoKIkV4w61nZXRlIG11Y2hvIGEgdGkg bWlzbW8geSBlc3BlcmEgcG9jbyBkZSBsb3MgZGVtw6FzLiBBc8OtIHRlIGFob3JyYXLDoXMKZGlz Z3VzdG9zLiIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PQo= ------=_Part_11244_33392458.1189528641937 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.txt" X-Attachment-Id: f_f6gmqdij Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItU1RBQkxFICMxOiBNb24gSnVsICAyIDIwOjI5 OjMxIENFU1QgMjAwNwogICAgcm9vdEBsZW9uc2lvLnRvb21hbnkubmV0Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL0xFT05TSU8KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDAKQ1BVOiBNb2JpbGUgQU1EIEF0aGxvbih0bSkgNjQgUHJvY2Vzc29yIDMwMDArICgx ODA0LjEwLU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9 IDB4ZjRhICBTdGVwcGluZyA9IDEwCiAgRmVhdHVyZXM9MHg3OGJmYmZmPEZQVSxWTUUsREUsUFNF LFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2 LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTI+CiAgQU1EIEZlYXR1cmVzPTB4ZTA1MDA4MDA8U1lT Q0FMTCxOWCxNTVgrLExNLDNETm93KywzRE5vdz4KcmVhbCBtZW1vcnkgID0gNTM1NzU2ODAwICg1 MTAgTUIpCmF2YWlsIG1lbW9yeSA9IDUxMDY3Mjg5NiAoNDg3IE1CKQpBQ1BJIEFQSUMgVGFibGU6 IDxQVExURCAgCSBBUElDICA+Ck1BRFQ6IEZvcmNpbmcgYWN0aXZlLWxvdyBwb2xhcml0eSBhbmQg bGV2ZWwgdHJpZ2dlciBmb3IgU0NJCmlvYXBpYzAgPFZlcnNpb24gMC4zPiBpcnFzIDAtMjMgb24g bW90aGVyYm9hcmQKd2xhbjogbWFjIGFjbCBwb2xpY3kgcmVnaXN0ZXJlZAprYmQxIGF0IGtiZG11 eDAKYXRoX2hhbDogMC45LjIwLjMgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1 MTEyLCBSRjI0MTMsIFJGNTQxMykKYWNwaTA6IDxBcmltYSAxNjFGaD4gb24gbW90aGVyYm9hcmQK YWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBh dCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgtMHg0MDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1i ZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4MT4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKY3B1MDog PEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkw CmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJv bCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MAphZ3AwOiA8VklBIDgzODUgaG9zdCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhlMDAwMDAwMC0weGVm ZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kx OiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmNiYjA6 IDxFTkUgQ0IxNDEwIFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4ZmZlN2YwMDAtMHhmZmU3ZmZm ZiBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwCmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAK cGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBvbiBjYmIwCnJhbDA6IDxSYWxpbmsgVGVjaG5v bG9neSBSVDI1NjA+IG1lbSAweGQwMDAwMDAwLTB4ZDAwMDFmZmYgaXJxIDE4IGF0IGRldmljZSAx Mi4wIG9uIHBjaTAKcmFsMDogTUFDL0JCUCBSVDI1NjAgKHJldiAweDA0KSwgUkYgUlQyNTI1CnJh bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjExOjA5OjIyOjM0Ojc3CnVoY2kwOiA8VklBIDgzQzU3 MiBVU0IgY29udHJvbGxlcj4gcG9ydCAweDFjODAtMHgxYzlmIGF0IGRldmljZSAxNi4wIG9uIHBj aTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBWSUEgVUhDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxl cj4gcG9ydCAweDFjYTAtMHgxY2JmIGF0IGRldmljZSAxNi4xIG9uIHBjaTAKdWhjaTE6IFtHSUFO VC1MT0NLRURdCnVzYjE6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQp1c2Ix OiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiBWSUEgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVoY2kyOiA8VklBIDgzQzU3MiBVU0IgY29udHJvbGxlcj4gcG9ydCAweDFjYzAt MHgxY2RmIGF0IGRldmljZSAxNi4yIG9uIHBjaTAKdWhjaTI6IFtHSUFOVC1MT0NLRURdCnVzYjI6 IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgp1c2IyOiBVU0IgcmV2aXNpb24g MS4wCnVodWIyOiBWSUEgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDEKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kw OiA8VklBIFZUNjIwMiBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQwMDAyODAwLTB4ZDAwMDI4 ZmYgYXQgZGV2aWNlIDE2LjMgb24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMzogRUhD SSB2ZXJzaW9uIDEuMAp1c2IzOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDog dXNiMCB1c2IxIHVzYjIKdXNiMzogPFZJQSBWVDYyMDIgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBl aGNpMAp1c2IzOiBVU0IgcmV2aXNpb24gMi4wCnVodWIzOiBWSUEgRUhDSSByb290IGh1YiwgY2xh c3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDEKdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxNy4w IG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxWSUEgODIzNSBVRE1B MTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYs MHgxY2UwLTB4MWNlZiBhdCBkZXZpY2UgMTcuMSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAw PiBvbiBhdGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnBjbTA6IDxWSUEg VlQ4MjM1PiBwb3J0IDB4MTAwMC0weDEwZmYgaXJxIDIyIGF0IGRldmljZSAxNy41IG9uIHBjaTAK cGNtMDogPEF2YW5jZSBMb2dpYyBBTEMyNTAgQUM5NyBDb2RlYz4KcGNtMDogPFZJQSBEWFMgRW5h YmxlZDogRFhTIDQgLyBTR0QgMSAvIFJFQyAxPgpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZp Y2UgMTcuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQp2cjA6IDxWSUEgVlQ2MTAyIFJoaW5lIElJIDEw LzEwMEJhc2VUWD4gcG9ydCAweDE4MDAtMHgxOGZmIG1lbSAweGQwMDAyYzAwLTB4ZDAwMDJjZmYg aXJxIDIzIGF0IGRldmljZSAxOC4wIG9uIHBjaTAKbWlpYnVzMDogPE1JSSBidXM+IG9uIHZyMAp1 a3BoeTA6IDxHZW5lcmljIElFRUUgODAyLjN1IG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMAp1 a3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBh dXRvCnZyMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDM6MjU6MTM6OWU6NWQKZndvaGNpMDogPFZJ QSBGaXJlIElJIChWVDYzMDYpPiBwb3J0IDB4MWMwMC0weDFjN2YgbWVtIDB4ZDAwMDIwMDAtMHhk MDAwMjdmZiBpcnEgMTkgYXQgZGV2aWNlIDE5LjAgb24gcGNpMApmd29oY2kwOiBPSENJIHZlcnNp b24gMS4wIChST009MSkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDQu CmZ3b2hjaTA6IEVVSTY0IDAwOjAzOjI1OjIxOjM2OjAwOjg1Ojk3CmZ3b2hjaTA6IFBoeSAxMzk0 YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIw NDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAK ZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMAppZl9md2UwOiBGYWtl IEV0aGVybmV0IGFkZHJlc3M6IDAyOjAzOjI1OjAwOjg1Ojk3CmZ3ZTA6IEV0aGVybmV0IGFkZHJl c3M6IDAyOjAzOjI1OjAwOjg1Ojk3CmZ3ZTA6IGlmX3N0YXJ0IHJ1bm5pbmcgZGVmZXJyZWQgZm9y IEdpYW50CnNicDA6IDxTQlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd29o Y2kwOiBJbml0aWF0ZSBidXMgcmVzZXQKZndvaGNpMDogQlVTIHJlc2V0CmZ3b2hjaTA6IG5vZGVf aWQ9MHhjMDAwZmZjMCwgZ2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAxIG5vZGVz LCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIg MCAobWUpCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCww eDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMw CmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogPFBTLzIgTW91c2U+ IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEludGVs bGlNb3VzZSwgZGV2aWNlIElEIDMKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJh dHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMApwbXRpbWVyMCBv biBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjZmZmZiww eGRiMDAwLTB4ZGJmZmYsMHhkYzAwMC0weGRmZmZmIG9uIGlzYTAKcHBjMDogcGFyYWxsZWwgcG9y dCBub3QgZm91bmQuCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2Ew CnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMDogY29uZmln dXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkg bm90IGJlIGVuYWJsZWQKc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAg b24gaXNhMApzaW8wOiB0eXBlIDgyNTAgb3Igbm90IHJlc3BvbmRpbmcKc2lvMTogY29uZmlndXJl ZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90 IGJlIGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kg MTgwNDEwMTk5MiBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBt c2VjCmFkMDogNTcyNzdNQiA8U0FNU1VORyBNUDA2MDNIIFVEMTAwLTExPiBhdCBhdGEwLW1hc3Rl ciBVRE1BMTAwCmFjZDA6IERWRFIgPFRPU0hJQkEgT0RELURWRCBTRC1SNjM3Mi8xMDMyPiBhdCBh dGExLW1hc3RlciBVRE1BMzMKYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNU IGFzYz0weDI0IGFzY3E9MHgwMCBza3M9MHg0MCAweDAwIDB4MDEKY2QwIGF0IGF0YTEgYnVzIDAg dGFyZ2V0IDAgbHVuIDAKY2QwOiA8VE9TSElCQSBPREQtRFZEIFNELVI2MzcyIDEwMzI+IFJlbW92 YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QwOiAzMy4wMDBNQi9zIHRyYW5zZmVycwpjZDA6 IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBu b3QgcHJlc2VudApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMyYQo= ------=_Part_11244_33392458.1189528641937 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pciconf.txt" X-Attachment-Id: f_f6gmqmjc YWdwMEBwY2kwOjA6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDMxODgxMTA2IGNoaXA9MHgzMTg4 MTEwNiByZXY9MHgwMSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVz IEluYycKICAgIGRldmljZSAgICAgPSAnQXBvbGxvIEs4VDgwMCBDUFUgdG8gUENJIEJyaWRnZScK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpwY2liMUBw Y2kwOjE6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHhiMTg4MTEwNiBy ZXY9MHgwMCBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9naWVzIEluYycK ICAgIGRldmljZSAgICAgPSAnQXBvbGxvIEs4SFRCIENQVSB0byBBR1AgMi4wLzMuMCBCcmlkZ2Un CiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpjYmIwQHBj aTA6MTA6MDoJY2xhc3M9MHgwNjA3MDAgY2FyZD0weDIwMzIxNjFmIGNoaXA9MHgxNDEwMTUyNCBy ZXY9MHgwMSBoZHI9MHgwMgogICAgdmVuZG9yICAgICA9ICdFTkUgVGVjaG5vbG9neSBJbmMnCiAg ICBkZXZpY2UgICAgID0gJ0NCLTE0MjAgQ2FyZEJ1cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAg ICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1DYXJkQnVzCnJhbDBAcGNpMDoxMjowOglj bGFzcz0weDAyODAwMCBjYXJkPTB4NjgzMzE0NjIgY2hpcD0weDAyMDExODE0IHJldj0weDAxIGhk cj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1JhbGluayBUZWNobm9sb2d5LCBDb3JwJwogICAgZGV2 aWNlICAgICA9ICdSYWxpbmsgUlQyNTAwIDgwMi4xMSBDYXJkQnVzIFJlZmVyZW5jZSBDYXJkJwog ICAgY2xhc3MgICAgICA9IG5ldHdvcmsKdWhjaTBAcGNpMDoxNjowOgljbGFzcz0weDBjMDMwMCBj YXJkPTB4MjAzMjE2MWYgY2hpcD0weDMwMzgxMTA2IHJldj0weDgwIGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDgyeHh4 eHggVUhDSSBVU0IgMS4xIENvbnRyb2xsZXIgKEFsbCBWSUEgQ2hpcHNldHMpJwogICAgY2xhc3Mg ICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKdWhjaTFAcGNpMDoxNjoxOglj bGFzcz0weDBjMDMwMCBjYXJkPTB4MjAzMjE2MWYgY2hpcD0weDMwMzgxMTA2IHJldj0weDgwIGhk cj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNl ICAgICA9ICdWVDgyeHh4eHggVUhDSSBVU0IgMS4xIENvbnRyb2xsZXIgKEFsbCBWSUEgQ2hpcHNl dHMpJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKdWhj aTJAcGNpMDoxNjoyOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4MjAzMjE2MWYgY2hpcD0weDMwMzgx MTA2IHJldj0weDgwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMg SW5jJwogICAgZGV2aWNlICAgICA9ICdWVDgyeHh4eHggVUhDSSBVU0IgMS4xIENvbnRyb2xsZXIg KEFsbCBWSUEgQ2hpcHNldHMpJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNs YXNzICAgPSBVU0IKZWhjaTBAcGNpMDoxNjozOgljbGFzcz0weDBjMDMyMCBjYXJkPTB4MjAzMjE2 MWYgY2hpcD0weDMxMDQxMTA2IHJldj0weDgyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJ QSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDYyMDIgVVNCIDIuMCBFbmhh bmNlZCBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgppc2FiMEBwY2kwOjE3OjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHgzMTc3 MTEwNiBjaGlwPTB4MzE3NzExMDYgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAn VklBIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1ZUODIzNSBQQ0kgdG8gSVNB IEJyaWRnZScKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNB CmF0YXBjaTBAcGNpMDoxNzoxOgljbGFzcz0weDAxMDE4YSBjYXJkPTB4MjAzMjE2MWYgY2hpcD0w eDA1NzExMTA2IHJldj0weDA2IGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9s b2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDgyeHh4eCBFSURFIENvbnRyb2xsZXIgKEFs bCBWSUEgQ2hpcHNldHMpJwogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xh c3MgICA9IEFUQQpwY20wQHBjaTA6MTc6NToJY2xhc3M9MHgwNDAxMDAgY2FyZD0weDIwMzIxNjFm IGNoaXA9MHgzMDU5MTEwNiByZXY9MHg1MCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdWSUEg VGVjaG5vbG9naWVzIEluYycKICAgIGRldmljZSAgICAgPSAnVlQ4MjMzLzMzQS84MjM1LzgyMzcg QUM5NyBFbmhhbmNlZCBBdWRpbyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IG11bHRpbWVk aWEKICAgIHN1YmNsYXNzICAgPSBhdWRpbwpub25lMEBwY2kwOjE3OjY6CWNsYXNzPTB4MDc4MDAw IGNhcmQ9MHgyMDMyMTYxZiBjaGlwPTB4MzA2ODExMDYgcmV2PTB4ODAgaGRyPTB4MDAKICAgIHZl bmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAgID0gJ1ZUODJD Njg2L0EvQixWVDgyMzMvQSBNb2RlbSBDb2RlYycKICAgIGNsYXNzICAgICAgPSBzaW1wbGUgY29t bXMKdnIwQHBjaTA6MTg6MDoJY2xhc3M9MHgwMjAwMDAgY2FyZD0weDAxMDIxMTA2IGNoaXA9MHgz MDY1MTEwNiByZXY9MHg3NCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdWSUEgVGVjaG5vbG9n aWVzIEluYycKICAgIGRldmljZSAgICAgPSAnVlQ2MTAyIFJoaW5lIElJIFBDSSBGYXN0IEV0aGVy bmV0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbmV0d29yawogICAgc3ViY2xhc3MgICA9 IGV0aGVybmV0CmZ3b2hjaTBAcGNpMDoxOTowOgljbGFzcz0weDBjMDAxMCBjYXJkPTB4MzA0NDEx MDYgY2hpcD0weDMwNDQxMTA2IHJldj0weDgwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ1ZJ QSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdWVDYzMDYgVklBIEZpcmUgSUkg SUVFRS0xMzk0IE9IQ0kgTGluayBMYXllciBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNl cmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBGaXJlV2lyZQpob3N0YjBAcGNpMDoyNDowOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0weDAwIGhkcj0w eDAwCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBk ZXZpY2UgICAgID0gJ0F0aGxvbiA2NCAvIE9wdGVyb24gSHlwZXJUcmFuc3BvcnQgVGVjaG5vbG9n eSBDb25maWd1cmF0aW9uJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9 IEhPU1QtUENJCmhvc3RiMUBwY2kwOjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAw MCBjaGlwPTB4MTEwMTEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQWR2 YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgICAgPSAnQXRobG9uIDY0IC8g T3B0ZXJvbiBBZGRyZXNzIE1hcCcKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNz ICAgPSBIT1NULVBDSQpob3N0YjJAcGNpMDoyNDoyOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAw MDAwMDAgY2hpcD0weDExMDIxMDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICAgID0gJ0F0aGxvbiA2 NCAvIE9wdGVyb24gRFJBTSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiM0BwY2kwOjI0OjM6CWNsYXNzPTB4MDYwMDAwIGNh cmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRv ciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGRldmljZSAgICAgPSAn QXRobG9uIDY0IC8gT3B0ZXJvbiBNaXNjZWxsYW5lb3VzIENvbnRyb2wnCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKbm9uZTFAcGNpMTowOjA6CWNsYXNz PTB4MDMwMDAwIGNhcmQ9MHgyMDMyMTYxZiBjaGlwPTB4NGU1MDEwMDIgcmV2PTB4MDAgaGRyPTB4 MDAKICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnCiAgICBkZXZpY2UgICAg ID0gJ01vYmlsaXR5IFJhZGVvbiA5NzAwIChNMTAgTlApIChSVjM1MCknCiAgICBjbGFzcyAgICAg ID0gZGlzcGxheQogICAgc3ViY2xhc3MgICA9IFZHQQo= ------=_Part_11244_33392458.1189528641937 Content-Type: text/plain; name="uname.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="uname.txt" X-Attachment-Id: f_f6gmqqov RnJlZUJTRCBsZW9uc2lvLnRvb21hbnkubmV0IDYuMi1TVEFCTEUgRnJlZUJTRCA2LjItU1RBQkxF ICMxOiBNb24gSnVsICAyIDIwOjI5OjMxIENFU1QgMjAwNyAgICAgcm9vdEBsZW9uc2lvLnRvb21h bnkubmV0Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0xFT05TSU8gIGkzODYK ------=_Part_11244_33392458.1189528641937-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 18:07:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B1E616A47F for ; Tue, 11 Sep 2007 18:07:18 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9732513C483 for ; Tue, 11 Sep 2007 18:07:13 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by rv-out-0910.google.com with SMTP id l15so1292261rvb for ; Tue, 11 Sep 2007 11:07:12 -0700 (PDT) Received: by 10.141.20.7 with SMTP id x7mr840946rvi.1189534032551; Tue, 11 Sep 2007 11:07:12 -0700 (PDT) Received: by 10.141.21.1 with HTTP; Tue, 11 Sep 2007 11:07:12 -0700 (PDT) Message-ID: Date: Tue, 11 Sep 2007 20:07:12 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: Subject: Re: Problems updating from 6.2-STABLE to -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, 11 Sep 2007 18:07:18 -0000 MjAwNy85LzExLCBUb29NYW55IFNlY3JldHMgPHRvb21hbnlAdG9vbWFueS5uZXQ+Ogo+IEhpIQo+ Cj4gQWZ0ZXIgY3ZzdXBlZCBteSAvdXNyL3NyYywgYW5kIGxvb2tlZCBmb3IgYW55ICJ0aXAiIGlu dG8gVVBEQVRJTkcKPiBmaWxlLCBJJ20gcnVubmluZyBhICJtYWtlIGJ1aWxkd29ybGQiIChhZnRl ciBhIG1ha2UgY2xlYW4gb2JqKSB0bwo+IG9idGFpbiBhIC1DVVJSRU5UIHN5c3RlbS4gQnV0IGl0 J3MgaGFuZ2luZyB3aXRoIHRoaXMgZXJyb3I6Cj4KPiAvdXNyL2xvY2FsL2xpYmV4ZWMvY2NhY2hl L3dvcmxkLWNjIC1PcyAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZQo+IC1ESU5fR0NDIC1ESEFW RV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3Ivb2JqL3Vzci9zcmMvdG1wL3VzclwiCj4gLUkvdXNy L29iai91c3Ivc3JjL3RtcC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX2ludC8uLi9jY190b29s cwo+IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfaW50Ly4uL2NjX3Rvb2xzCj4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY19pbnQvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MKPiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX2ludC8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25m aWcKCk9rLCBub3cgSSdtIHRyeWluZyB0byBjb21waWxlIChtYWtlIGJ1aWxkd29ybGQpIHdpdGhv dXQgY2NhY2hlLiBJZiBJCndpbGwgaGF2ZSBhbnkgcHJvYmxlbSwgSSB3aWxsIHBvc3QgaXQgaGVy ZS4KClRoYW5rIHlvdSEKCi0tIApIYXZlIGEgbmljZSBkYXkgIDstKQpUb29NYW55U2VjcmV0cwoK PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpEaWpvIENvbmZ1Y2lvOgoiRXjDrWdldGUgbXVj aG8gYSB0aSBtaXNtbyB5IGVzcGVyYSBwb2NvIGRlIGxvcyBkZW3DoXMuIEFzw60gdGUgYWhvcnJh csOhcwpkaXNndXN0b3MuIgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09Cg== From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 18:32:35 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6168616A468 for ; Tue, 11 Sep 2007 18:32:35 +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 2B88D13C48A for ; Tue, 11 Sep 2007 18:32:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 79271 invoked from network); 11 Sep 2007 18:32:33 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 11 Sep 2007 18:32:33 -0000 Message-ID: <46E6DF34.1060304@root.org> Date: Tue, 11 Sep 2007 11:32:20 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: William Grzybowski References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> In-Reply-To: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------010202030307050802010105" Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 18:32:35 -0000 This is a multi-part message in MIME format. --------------010202030307050802010105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit William Grzybowski wrote: > On 9/6/07, *Nate Lawson* > wrote: > > Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please > test and > > let me know if you get any new errors on dmesg or if it fixes > things for > > you (especially HP/Compaq laptop owners). > > > > If you still have problems, try setting each of these tunables > > individually and then both together (i.e., in > /boot/loader.conf). Note > > that this will be four (4) test runs total, so don't just set both and > > say it doesn't work. > > > > debug.acpi.ec.burst= "1" > > debug.acpi.ec.polled="1" > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > > problems in either regular or burst mode. > > > > > > Commit message: > > Rewrite the EC driver event model. The main goal is to avoid > > polling/interrupt-driven fallback and instead use polling only during > > boot and pure interrupt-driven mode after boot. Polled mode could be > > relegated completely to a legacy role if we could enable interrupts > > during boot. Polled mode can be forced after boot by setting > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > One minor note -- power off shutdown (shutdown/halt -p) is turned into a > (safe) reboot with this patch. I have tested the fix, which is just to > force polled mode during shutdown as well. I don't have time to > re-roll > the patch today but will send tomorrow. > > Please test the patch as posted, ignoring that minor issue. The test > results during normal use are still valid. > > > Hi Nate, > > I tested this patch on my acer notebook (intel chipset) and i did not > notice any changes, unless some errors on dmesg, like: > acpi_ec0: EcCommand: no response to 0x84 > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcCommand: no response to 0x82 > acpi_ec0: EcCommand: no response to 0x80 > ACPI Error (psparse-0626): Method parse/execution failed > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE As I noted before, your system enters the poll loop with the status appearing to be already complete. Can you get back to me on my previous questions, especially whether forcing polled mode works for you? I didn't see any errors in that dmesg case. I've updated the patches to do one final check if the interrupt-driven mode gets a timeout. If the status is complete, it will force the system back into polled mode since interrupt mode doesn't work. It also has a case for polled mode during boot where the status appears to be already complete. It waits a short while before actually checking the status, just in case the EC is really slow and hasn't gotten to work on the new request yet. Give it a try also, with no tunables set. -Nate --------------010202030307050802010105 Content-Type: text/x-patch; name="ecng-6c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6c.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.65.2.3 diff -u -r1.65.2.3 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 11 Sep 2007 18:12:09 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,8 +149,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,46 +186,57 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, + EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); + +static ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -366,10 +274,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -601,7 +511,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -636,7 +546,7 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, @@ -688,100 +598,92 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +727,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -850,193 +764,264 @@ if (ACPI_FAILURE(Status)) break; } - EcUnlock(sc); + return_ACPI_STATUS (Status); } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { - EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; - if (count == 0) + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; - } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------010202030307050802010105 Content-Type: text/x-patch; name="ecng-7c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7c.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.75 diff -u -r1.75 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 11 Sep 2007 18:31:32 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -248,8 +139,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); -static __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,37 +206,27 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -387,10 +264,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -621,7 +499,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -656,12 +534,11 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,52 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +645,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +714,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +757,119 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. - */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { - EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. + */ + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); + } + + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); } - } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +877,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +897,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +913,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +923,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,32 +942,32 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +986,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------010202030307050802010105-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 19:12:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B84C16A418 for ; Tue, 11 Sep 2007 19:12:46 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id CE23913C45D for ; Tue, 11 Sep 2007 19:12:45 +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.14.1/8.14.1) with ESMTP id l8BJChPj003781; Wed, 12 Sep 2007 05:12:43 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l8BJChjO003780; Wed, 12 Sep 2007 05:12:43 +1000 (EST) (envelope-from peter) Date: Wed, 12 Sep 2007 05:12:43 +1000 From: Peter Jeremy To: TooMany Secrets Message-ID: <20070911191243.GJ3585@turion.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Problems updating from 6.2-STABLE to -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, 11 Sep 2007 19:12:46 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-11 18:37:21 +0200, TooMany Secrets wrote: >/usr/local/libexec/ccache/world-cc -Os -fno-strict-aliasing -pipe >-DIN_GCC -DHAVE_CONFIG_H -DPREFIX=3D\"/usr/obj/usr/src/tmp/usr\" =2E.. >../cc_tools/insn-attrtab.c > >cc1: out of memory allocating 136475392 bytes =2E.. >Well, I'm using "ccache", and I don't know if this is convenient to >this type of upgrade or not. As a general recommendation, if a buildworld fails when using a non- standard configuraton (-j N, -Ox or something like ccache), you should confirm that the failure still exists with the standard configuration (as I note you are doing). In this case I suspect you are running foul of gcc 4.2.1's larger memory footprint rather than ccache. What is the data segment size limit on your system (reported by ulimit)? Are you able to increase it (probably by several hundred MB)? --=20 Peter Jeremy --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG5uir/opHv/APuIcRAip6AKCtmbLXDUNU8MYC/ejBMUuK7bldDwCgicDF G3//JbDnWLJMWNTl1pACvMs= =1sVv -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 19:17:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F37C016A420 for ; Tue, 11 Sep 2007 19:17:41 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7F89613C474 for ; Tue, 11 Sep 2007 19:17:41 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8BJHYt7059164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Sep 2007 21:17:40 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l8BJHYTM000517 for ; Tue, 11 Sep 2007 21:17:34 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l8BJIhOB027723 for freebsd-current@freebsd.org; Tue, 11 Sep 2007 21:18:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Tue, 11 Sep 2007 21:18:13 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1906089.9gfh4rTbUE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709112118.43342.h.schmalzbauer@omnisec.de> Subject: padlock not mentioned in NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 19:17:42 -0000 --nextPart1906089.9gfh4rTbUE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, there is such a wonderful padlock(4) device but it's not mentioned in NOTES= =2E I=20 think it belongs to sys/i386/conf/NOTES. =46ortunately it has a man page and is corss referenced :) Thanks, =2DHarry --nextPart1906089.9gfh4rTbUE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG5uoTLDqVQ9VXb8gRAoEtAKDDzmw+ERazaMw0r1NDrelroHpu6wCggzft 2W1VjKGb2sipj+3b3UTx4k0= =DGR3 -----END PGP SIGNATURE----- --nextPart1906089.9gfh4rTbUE-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 19:25:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EE716A419 for ; Tue, 11 Sep 2007 19:25:08 +0000 (UTC) (envelope-from ntarmos@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 19FCC13C457 for ; Tue, 11 Sep 2007 19:25:07 +0000 (UTC) (envelope-from ntarmos@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id CFFF5EB47F9 for ; Tue, 11 Sep 2007 22:25:05 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 6D7FC159345 for ; Tue, 11 Sep 2007 22:25:05 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbxNGJOW9a3J for ; Tue, 11 Sep 2007 22:25:05 +0300 (EEST) Received: from ace.b020.ceid.upatras.gr (ppp190-086.dsl.hol.gr [89.210.190.86]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 2C457159340 for ; Tue, 11 Sep 2007 22:25:05 +0300 (EEST) Received: by ace.b020.ceid.upatras.gr (Postfix, from userid 1001) id 27D603F40B; Tue, 11 Sep 2007 22:25:08 +0300 (EEST) Date: Tue, 11 Sep 2007 22:25:07 +0300 From: Nikos Ntarmos To: freebsd-current@freebsd.org Message-ID: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> Mail-Followup-To: freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: NetCInS Lab., C.E.I.D., U. of Patras, Greece WWW-Homepage: http://ntarmos.dyndns.org/ X-PGP-Fingerprint: 9680 60A7 DE60 0298 B1F0 9B22 9BA2 7569 CF95 160A Office-Phone: +30-2610-996919 Office-Fax: +30-2610-969011 GPS-Info: 38.31N, 21.82E User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: Re: Problems updating from 6.2-STABLE to -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, 11 Sep 2007 19:25:08 -0000 Hi there. On Tue, Sep 11, 2007 at 06:37:21PM +0200, TooMany Secrets wrote: > /usr/local/libexec/ccache/world-cc -Os -fno-strict-aliasing -pipe The build error message looks more like a compiler bug (looks like it comes from contrib/gcclibs/libiberty/xmalloc.c). Could you try building world with some other optimization level (e.g. -O2, -O1)? \n\n From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 20:32:50 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C144116A46B for ; Tue, 11 Sep 2007 20:32:50 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7B613C480 for ; Tue, 11 Sep 2007 20:32:44 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1301304nfb for ; Tue, 11 Sep 2007 13:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=/yEXmimLtQO0gnx+yN66gA5SYdhSxBHYl1dalmrqVLc=; b=qRuUXZ4FYHGVVRRP6y1QAwfJ6U32BveoFQBkYHsX8IdbIyIywhjCDhxiC0iYz9wIlMVqmZ2KHJ2oZ0sUTBvxoew64yJO7i3cLog/4vFhjL/gk93BbjO54JEfs+DkwOciyqibmNy33kr6OHhJ/7IHTQOR9KqDdK6y0hjyG5s2XLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=IRt/HK52uevs5ZhNovffYbiNbFEAvCG3n9hq9NX3KVXIVi1pkDVjj0VDZQzpPlUQfB+2aRboGnzuMdwFrOzyz72RzN1bs1OUk0ufvYVNncXD3Cxtpb+44T7BNIHauSJ7TNzIpH+4hNx6o3cae+MiBSE3O6azVSEmgQC4vi7EaDM= Received: by 10.86.93.17 with SMTP id q17mr4852509fgb.1189542763789; Tue, 11 Sep 2007 13:32:43 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.137.211]) by mx.google.com with ESMTPS id m1sm11352343fke.2007.09.11.13.32.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2007 13:32:43 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l8BKWeLv034786; Tue, 11 Sep 2007 22:32:40 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l8BKWd7D034785; Tue, 11 Sep 2007 22:32:39 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 11 Sep 2007 22:32:39 +0200 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20070911203238.GA34761@roadrunner.spoerlein.net> Mail-Followup-To: Pawel Jakub Dawidek , current@freebsd.org References: <20070906184853.GB90021@roadrunner.spoerlein.net> <20070910195833.GE1103@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910195833.GE1103@garage.freebsd.pl> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@FreeBSD.org Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 20:32:50 -0000 On Mon, 10.09.2007 at 21:58:33 +0200, Pawel Jakub Dawidek wrote: > On Thu, Sep 06, 2007 at 08:48:53PM +0200, Ulrich Spoerlein wrote: > > ever since I switched my /usr and /home to ZFS, the system has become > > _very_ unresponsive under load. This is not because of CPU load, but I/O > > load. > Can you try recent HEAD? I committed a change that allows ZFS cache > (ARC) to use more memory. This should be safe after dfr@'s vnode leak > fix and should also help performance. Looks much better now, though I'd like to observe for a couple more days. I'll report back, if there's still an issue. Thanks for the quick fix! Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:13:33 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB7616A419 for ; Tue, 11 Sep 2007 21:13:33 +0000 (UTC) (envelope-from pphajek@lbl.gov) Received: from ironport2.lbl.gov (ironport2.lbl.gov [128.3.41.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA8F13C469 for ; Tue, 11 Sep 2007 21:13:33 +0000 (UTC) (envelope-from pphajek@lbl.gov) X-Ironport-SBRS: None X-Brightmail-Tracker: AAAAAA== X-BrightmailFiltered: true X-IronPort-AV: E=Sophos;i="4.20,240,1186383600"; d="scan'208";a="34597898" Received: from eniac.jgi-psf.org ([198.129.89.82]) by ironport2.lbl.gov with ESMTP; 11 Sep 2007 14:02:35 -0700 Received: from eniac.jgi-psf.org (localhost [127.0.0.1]) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9) with ESMTP id l8BL2Yb9016218; Tue, 11 Sep 2007 14:02:34 -0700 (PDT) Received: (from phajek@localhost) by eniac.jgi-psf.org (8.12.9+Sun/8.12.9/Submit) id l8BL2Yr0016217; Tue, 11 Sep 2007 14:02:34 -0700 (PDT) X-Authentication-Warning: eniac.jgi-psf.org: phajek set sender to pphajek@lbl.gov using -f Date: Tue, 11 Sep 2007 14:02:34 -0700 From: Patrick Hajek To: thomas@FreeBSD.ORG, current@FreeBSD.ORG Message-ID: <20070911210234.GC21433@lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:13:33 -0000 >> >> The upgrade was successful with one exception: >> >> ad0: 95205MB at ata0-master UDMA100 >> >> acd0: DVDR at ata1-master UDMA33 >> >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >> >> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >> > >atapicam is disabled in your kernel configuration, so I assume you >> >are >> >loading it as a module. Do you still get the errors above (on acd0) >> >if >> >you do *not* load the atapi-cam module? >> >> >Thomas. >> >> Correct. When I first encountered the error, the vaious components >> were >> compiled into the kernel. Taking a wild stab, I decided to see if >> loading it as a module would result the the same issue and yes, it >> did. >so can you confirm whether you still get the acd0 errors when you do NOT >load atapi-cam at all (nor have it precompiled in the kernel)? > >Thomas. Commenting out atapicam_load="YES" in loader.conf and not precompiled it in the kernel, the errors disappear. dmesg shows: d0: 95205MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 No sense errors. So, it appears to point to the atapi-cam module. Suggestions? Thanks, Patrick -- Patrick Hajek /"\ DOE Joint Genome Institute \ / ASCII RIBBON CAMPAIGN Desk: 925.296.5762 X HELP CURE HTML MAIL Cell: 925.997.4826 / \ PGP Fingerprint 688E B579 3449 28B1 DB14 E15A 76BB C1CA A745 9DAB From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:40:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAF716A420 for ; Tue, 11 Sep 2007 21:40:02 +0000 (UTC) (envelope-from skalla.raabjorn@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 42ED213C4A3 for ; Tue, 11 Sep 2007 21:39:59 +0000 (UTC) (envelope-from skalla.raabjorn@gmx.de) Received: (qmail invoked by alias); 11 Sep 2007 21:13:17 -0000 Received: from f048229159.adsl.alicedsl.de (EHLO sol.hackerzberg.local) [78.48.229.159] by mail.gmx.net (mp039) with SMTP; 11 Sep 2007 23:13:17 +0200 X-Authenticated: #8038066 X-Provags-ID: V01U2FsdGVkX1+xN7YCcK+xV6QqxIiGRXGxqKjx0tbv3oqyiT8vy0 PdDBYufV/tOgCR Date: Tue, 11 Sep 2007 23:13:27 +0200 From: Skalla Raabjorn To: freebsd-current@freebsd.org Message-ID: <20070911231327.689c85a8@sol.hackerzberg.local> In-Reply-To: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> References: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Problems building -current world: safe-ctype.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:40:02 -0000 On Fri, 31 Aug 2007 20:19:45 -0700 (PDT) "Nick Sayer" wrote: > Hi. > > I'm trying to build the world and it's failing during phase 2.3 trying to > build libiberty. > > cc -c -I /usr/src/gnu/usr.bin/cc/cc_tools/../libiberty -O2 > -fno-strict-aliasing > -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" > -I/usr/obj/usr/src/gnu/usr. > bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/us > r/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc > -I/usr/src/gnu/usr.bin/cc/ > cc_tools/../../../../contrib/gcc/config > -I/usr/src/gnu/usr.bin/cc/cc_tools/../.. > /../../contrib/gcclibs/include > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../co > ntrib/gcclibs/libcpp/include > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../cont > rib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H > -I/usr/obj/usr/src > /tmp/legacy/usr/include -o safe-ctype.o > /usr/src/gnu/usr.bin/cc/cc_tools/../../. > ./../contrib/gcclibs/libiberty/safe-ctype.c > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp > e.c:161: error: `_sch_isnvsp' undeclared here (not in a function) > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp > e.c:161: error: `_sch_iscntrl' undeclared here (not in a function) > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libiberty/safe-ctyp > e.c:161: error: initializer element is not constant > > > And so on and so on. > > Anybody have any idea what's going wrong? > > The system currently is 6.2-RELEASE. I guess I'm going to try taking it to > RELENG_6 before giving up for now, but I'm dubious that that's going to > change anything significant. Same problem here, tried 6.2-RELEASE and 6.2-STABLE as of today. Any ideas? From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:47:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002E116A419; Tue, 11 Sep 2007 21:47:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6155A13C457; Tue, 11 Sep 2007 21:47:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8BLkwNb060574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 23:47:03 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l8BLkwG4001549; Tue, 11 Sep 2007 23:46:58 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l8BLm7p5017163; Tue, 11 Sep 2007 23:48:07 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Tue, 11 Sep 2007 23:47:59 +0200 User-Agent: KMail/1.9.7 References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260054.42892.h.schmalzbauer@omnisec.de> <46D0BEEF.1020601@FreeBSD.org> In-Reply-To: <46D0BEEF.1020601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5278342.L8AoUd2DiV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709112348.07052.h.schmalzbauer@omnisec.de> Cc: Shteryana Shopova , "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:47:06 -0000 --nextPart5278342.L8AoUd2DiV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 26. August 2007 01:44:47 schrieb Constantine A. Murenin: [schnip] > P.S. BTW, please do report back how the tests went. Don't forget to > include the information on which exact chip you tested (for example, you > might have tried this code on Winbond W83627DHG and Core 2 Duo E4300). Hello, I had only tested some newer hardware with core2 CPU (E6750) and coretemp=20 doesn't report correct values for that CPU (25=B0C, this is at least 10=B0= =20 difference) and the boards doesn't neccessarily have a HW monitor chip, so = I=20 haven't reported anything yet. But, I'm about to test some VIA C7 boards and accidentaly found that if I disabl= e=20 ACPI (hint.acpi.0.disabled=3D1), dmesg shows a lm sensor: lm0: at port 0x290-0x297 on isa0 Also systat -sensors shows adaequat values corresponding to what the BIOS H= W=20 monitor reports. But as soon as I boot default with ACPI enabled, lm0 vanishes. Thanks for any hints. =2DHarry P.S. The patch doesn't apply cleanly for the sysctl man page, haven't had t= ime=20 to investigate yet. --nextPart5278342.L8AoUd2DiV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG5w0XLDqVQ9VXb8gRAszcAJ9RRNiyRA3PP7WUFcnqABaNxgPvRwCfcNfr qAJJERGd2xTl16kQio8Puw8= =AuxH -----END PGP SIGNATURE----- --nextPart5278342.L8AoUd2DiV-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:49:22 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90A4716A420 for ; Tue, 11 Sep 2007 21:49:22 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3FA13C480 for ; Tue, 11 Sep 2007 21:49:22 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1434rvb for ; Tue, 11 Sep 2007 14:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=mI6Q26WxmzN9GYHbYTI6HUXKgnbud09uR/N16yq6Fnw=; b=A3GI4si7iCuzcuiw2XmnLvsLQi9zMWGLuuYoGM48U8Z61kgknS/kN0gNPJOPSbgL1g4keQJabxtaU1C/Wboew2PQV3fJfHOlzGV8ZXncMyMKmxn2PruhUSYFuCK1U8BmmqynqwqSJIDClos8ybXWto6z093mgs9lTLr4/ZgSW/4= 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=dnU6eicpXGtC9TsrAN2y2drGOEeGvd2poLQr4VoYBXZsVpwLIbv5dx3QP59KSL7KOlGTmoNQiK6rWeplQaBTIK9MCmPKuVFMePjzrJKAcqhCGQORcRCRcEcWjEvw2PbNnF2nbfeNBR+QKWLSkM+UwLXZS7SkmVDLhtTyGOYp9fg= Received: by 10.140.133.10 with SMTP id g10mr2600351rvd.1189547361745; Tue, 11 Sep 2007 14:49:21 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Tue, 11 Sep 2007 14:49:21 -0700 (PDT) Message-ID: <632825b40709111449uf8e184cv2623b052d6013b82@mail.gmail.com> Date: Tue, 11 Sep 2007 18:49:21 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <46E6DF34.1060304@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> <46E6DF34.1060304@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:49:22 -0000 On 9/11/07, Nate Lawson wrote: > > William Grzybowski wrote: > > On 9/6/07, *Nate Lawson* > wrote: > > > > Nate Lawson wrote: > > > I've done some major rework on the EC driver. This should help > with > > > various problems, including timeouts while checking battery status > or > > > temperature. The attached patches are for 6.x and 7.x. Please > > test and > > > let me know if you get any new errors on dmesg or if it fixes > > things for > > > you (especially HP/Compaq laptop owners). > > > > > > If you still have problems, try setting each of these tunables > > > individually and then both together (i.e., in > > /boot/loader.conf). Note > > > that this will be four (4) test runs total, so don't just set both > and > > > say it doesn't work. > > > > > > debug.acpi.ec.burst= "1" > > > debug.acpi.ec.polled="1" > > > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, > no > > > problems in either regular or burst mode. > > > > > > > > > Commit message: > > > Rewrite the EC driver event model. The main goal is to avoid > > > polling/interrupt-driven fallback and instead use polling only > during > > > boot and pure interrupt-driven mode after boot. Polled mode could > be > > > relegated completely to a legacy role if we could enable > interrupts > > > during boot. Polled mode can be forced after boot by setting > > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > > > One minor note -- power off shutdown (shutdown/halt -p) is turned > into a > > (safe) reboot with this patch. I have tested the fix, which is just > to > > force polled mode during shutdown as well. I don't have time to > > re-roll > > the patch today but will send tomorrow. > > > > Please test the patch as posted, ignoring that minor issue. The > test > > results during normal use are still valid. > > > > > > Hi Nate, > > > > I tested this patch on my acer notebook (intel chipset) and i did not > > notice any changes, unless some errors on dmesg, like: > > acpi_ec0: EcCommand: no response to 0x84 > > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > > acpi_ec0: EcCommand: no response to 0x82 > > acpi_ec0: EcCommand: no response to 0x80 > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE > > As I noted before, your system enters the poll loop with the status > appearing to be already complete. Can you get back to me on my previous > questions, especially whether forcing polled mode works for you? I > didn't see any errors in that dmesg case. > > I've updated the patches to do one final check if the interrupt-driven > mode gets a timeout. If the status is complete, it will force the > system back into polled mode since interrupt mode doesn't work. It also > has a case for polled mode during boot where the status appears to be > already complete. It waits a short while before actually checking the > status, just in case the EC is really slow and hasn't gotten to work on > the new request yet. > > Give it a try also, with no tunables set. > Hi, Unfortunelly I don't had time to complete the tests which you asked to, i got a lot of work ;(. Tomorrow I will use my free time to do it all and the new ones. Thanks Nate. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:50:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32F5E16A418 for ; Tue, 11 Sep 2007 21:50:00 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6C913C45B for ; Tue, 11 Sep 2007 21:50:00 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 9571 invoked from network); 11 Sep 2007 21:49:59 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO asus.tddhome) ([64.81.173.150]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Sep 2007 21:49:59 -0000 Received: from asus.tddhome (localhost.tddhome [127.0.0.1]) by asus.tddhome (8.14.1/8.14.1) with ESMTP id l8BLnxos032300; Tue, 11 Sep 2007 14:49:59 -0700 (PDT) (envelope-from tomdean@asus.tddhome) Received: (from tomdean@localhost) by asus.tddhome (8.14.1/8.14.1/Submit) id l8BLnwpo032297; Tue, 11 Sep 2007 14:49:58 -0700 (PDT) (envelope-from tomdean) Date: Tue, 11 Sep 2007 14:49:58 -0700 (PDT) Message-Id: <200709112149.l8BLnwpo032297@asus.tddhome> From: "Thomas D. Dean" To: skalla.raabjorn@gmx.de In-reply-to: <20070911231327.689c85a8@sol.hackerzberg.local> (message from Skalla Raabjorn on Tue, 11 Sep 2007 23:13:27 +0200) References: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> <20070911231327.689c85a8@sol.hackerzberg.local> Cc: freebsd-current@freebsd.org Subject: Re: Problems building -current world: safe-ctype.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:50:00 -0000 I just built both -current and -stable with cvsup'd src just before: FreeBSD dv6000.tddhome 7.0-CURRENT FreeBSD 7.0-CURRENT #0: \ Mon Sep 10 08:30:35 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/GENERIC i386 FreeBSD dv6000.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #0: \ Mon Sep 10 11:12:02 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP i386 tomdean From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 21:53:00 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C4FC16A417 for ; Tue, 11 Sep 2007 21:53:00 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1CEED13C467 for ; Tue, 11 Sep 2007 21:53:00 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 115D141C76D for ; Tue, 11 Sep 2007 23:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id YPNWslm8l5GT for ; Tue, 11 Sep 2007 23:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B308241C75E; Tue, 11 Sep 2007 23:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E2AE9444885 for ; Tue, 11 Sep 2007 21:31:49 +0000 (UTC) Date: Tue, 11 Sep 2007 21:31:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20070911212720.K58095@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: mount -uw / does not work in boot -s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 21:53:00 -0000 Hi, if you boot -s on a HEAD and try to mount -uw / it will fail to update the mount if you do not have a /etc/fstab. The fstab part is the key to this. With an /etc/fstab everything seems to work just smoothly but how to touch the fstab if you cannot mount the fs rw? Neither mount -uw / mount -u -o rw / mount -uw /dev/... / mount -u -o rw /dev/... / work. The versions with the /dev/... / do not seem to give an error message but a mount afterwards shows that / is still read-only. The filesystem was clean upon boot and no fsck was run (I know there is another problem after fsck I think). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 22:08:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6918B16A46C for ; Tue, 11 Sep 2007 22:08:54 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 557DF13C4D1 for ; Tue, 11 Sep 2007 22:08:53 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by rv-out-0910.google.com with SMTP id l15so4812rvb for ; Tue, 11 Sep 2007 15:08:53 -0700 (PDT) Received: by 10.141.172.6 with SMTP id z6mr2617424rvo.1189548532795; Tue, 11 Sep 2007 15:08:52 -0700 (PDT) Received: by 10.141.21.1 with HTTP; Tue, 11 Sep 2007 15:08:52 -0700 (PDT) Message-ID: Date: Wed, 12 Sep 2007 00:08:52 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org In-Reply-To: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> Subject: Re: Problems updating from 6.2-STABLE to -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, 11 Sep 2007 22:08:54 -0000 MjAwNy85LzExLCBOaWtvcyBOdGFybW9zIDxudGFybW9zQGNlaWQudXBhdHJhcy5ncj46Cj4gSGkg dGhlcmUuCj4KPiBPbiBUdWUsIFNlcCAxMSwgMjAwNyBhdCAwNjozNzoyMVBNICswMjAwLCBUb29N YW55IFNlY3JldHMgd3JvdGU6Cj4gPiAvdXNyL2xvY2FsL2xpYmV4ZWMvY2NhY2hlL3dvcmxkLWNj IC1PcyAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZQo+Cj4gVGhlIGJ1aWxkIGVycm9yIG1lc3Nh Z2UgbG9va3MgbW9yZSBsaWtlIGEgY29tcGlsZXIgYnVnIChsb29rcyBsaWtlIGl0Cj4gY29tZXMg ZnJvbSBjb250cmliL2djY2xpYnMvbGliaWJlcnR5L3htYWxsb2MuYykuIENvdWxkIHlvdSB0cnkg YnVpbGRpbmcKPiB3b3JsZCB3aXRoIHNvbWUgb3RoZXIgb3B0aW1pemF0aW9uIGxldmVsIChlLmcu IC1PMiwgLU8xKT8KCk15IGFjdHVhbCBtYWtlLmNvbmYgZmxhZ3M6CgpDUFVUWVBFPz1wZW50aXVt NApDRkxBR1M9IC1PcyAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZQpDWFhGTEFHUys9IC1PMyAt RE5PX01BTExPQ19FWFRSQVMKQ09QVEZMQUdTPSAtTyAtcGlwZQoKTWF5YmUgSSB3aWxsIHRyeSBm aXJzdCB3aXRoIGEgLU8xIG9wdGltaXRhdGlvbi4gQWxzbywgSSBoYXZlIGEgY3VycmVudApzbmFw c2hvdCByZWFkeSB0byBtYWtlIGEgYmluYXJ5IHVwZ3JhZGUuLi4KClRoYW5rJ3MhIQoKLS0gCkhh dmUgYSBuaWNlIGRheSAgOy0pClRvb01hbnlTZWNyZXRzCgo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09CkRpam8gQ29uZnVjaW86CiJFeMOtZ2V0ZSBtdWNobyBhIHRpIG1pc21vIHkgZXNwZXJh IHBvY28gZGUgbG9zIGRlbcOhcy4gQXPDrSB0ZSBhaG9ycmFyw6FzCmRpc2d1c3Rvcy4iCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT0K From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 22:24:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6A916A418 for ; Tue, 11 Sep 2007 22:24:38 +0000 (UTC) (envelope-from skalla.raabjorn@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D1A7413C48D for ; Tue, 11 Sep 2007 22:24:37 +0000 (UTC) (envelope-from skalla.raabjorn@gmx.de) Received: (qmail invoked by alias); 11 Sep 2007 22:24:36 -0000 Received: from e179100121.adsl.alicedsl.de (EHLO sol.hackerzberg.local) [85.179.100.121] by mail.gmx.net (mp040) with SMTP; 12 Sep 2007 00:24:36 +0200 X-Authenticated: #8038066 X-Provags-ID: V01U2FsdGVkX19ewUUd0+ReDQFv3tK5IYsf5U2jBhnx19VxW1p/nv bzGO4gP1NEsdjL Date: Wed, 12 Sep 2007 00:24:41 +0200 From: Skalla Raabjorn To: freebsd-current@freebsd.org Message-ID: <20070912002441.2e23658e@sol.hackerzberg.local> In-Reply-To: <200709112149.l8BLnwpo032297@asus.tddhome> References: <60538.76.220.106.108.1188616785.squirrel@www.kfu.com> <20070911231327.689c85a8@sol.hackerzberg.local> <200709112149.l8BLnwpo032297@asus.tddhome> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Problems building -current world: safe-ctype.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 22:24:38 -0000 On Tue, 11 Sep 2007 14:49:58 -0700 (PDT) "Thomas D. Dean" wrote: > I just built both -current and -stable with cvsup'd src just before: > > FreeBSD dv6000.tddhome 7.0-CURRENT FreeBSD 7.0-CURRENT #0: \ > Mon Sep 10 08:30:35 PDT 2007 \ > root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/GENERIC i386 > > FreeBSD dv6000.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #0: \ > Mon Sep 10 11:12:02 PDT 2007 \ > root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP i386 > Maybe that wasn't clear enough. I tried to buildworld -current (cvsup 00:21 CEST from cvsup.de.freebsd.org) on a newly installed 6.2-RELEASE machine and it failed. Then updated to -stable as of today and it failed with the same error. From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 22:29:39 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7887216A419 for ; Tue, 11 Sep 2007 22:29:39 +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 00ACB13C48D for ; Tue, 11 Sep 2007 22:29:38 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup105.ach.sch.gr [81.186.70.105]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8BMTE5S015596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Sep 2007 01:29:24 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8BMT9NO003330; Wed, 12 Sep 2007 01:29:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8BMT8rH003329; Wed, 12 Sep 2007 01:29:08 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 12 Sep 2007 01:29:07 +0300 From: Giorgos Keramidas To: Peter Schuller Message-ID: <20070911222907.GA3289@kobe.laptop> References: <20070910204045.GA89544@hyperion.scode.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910204045.GA89544@hyperion.scode.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.09, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.31, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@freebsd.org Subject: Re: Memory accounting discrepancy in top (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 22:29:39 -0000 On 2007-09-10 22:40, Peter Schuller wrote: > I have a machine (Dell 2950) where I orignally thought there was a > memory visibility problem. It has 4 GB in total which seemed to be > detected on boot based on dmesg, yet top showed a total of slightly > above 2 GB. I posted to -questions about this in the belief that this > was the case from boot onwards. This is a bug in top. Please file a PR and optionally assign it to me. I'll try to fix it with the patch attached at the end of this message. > However, I discovered that after boot memory adds up in top, but then > goes down. Observe the following progression of top memory and their > totals over the course of about a day, on amd64 with CURRENT from > 2007-09-09: > > 10M Active, 1388K Inact, 84M Wired, 268K Cache, 800K Buf, 3822M Free Total: 3918 > 272M Active, 31M Inact, 650M Wired, 42M Cache, 992K Buf, 1391M Free Total: 2386.9 > 274M Active, 32M Inact, 655M Wired, 52M Cache, 992K Buf, 1372M Free Total: 2385.9 > 282M Active, 31M Inact, 646M Wired, 53M Cache, 992K Buf, 1372M Free Total: 2384.9 > 332M Active, 146M Inact, 719M Wired, 52M Cache, 214M Buf, 1071M Free Total: 2534 Slightly edited the text below to align text better and add a few observations based on the columns up to 'Free' above. * All units converted to KB (using 1 MB = 1024 KB as the utils.c implementation of the current format_k() function). * Added an 'in-use' column; the sum of the previous ones * Added a 'use^2' column; it is log2(in-use * 1024) * Kept the 'free' that top(1) reports. * Added a 'total' column with sum(in-use, free) active inact wired cache buf | in-use | use^2 | free | total 10240 1388 86016 268 800 | 98712 | 26.590 | 3913728 | 4012440 278528 31744 665600 43008 992 | 1019872 | 29.959 | 1424384 | 2444256 280576 32768 670720 53248 992 | 1038304 | 29.985 | 1404928 | 2443232 288768 31744 661504 54272 992 | 1037280 | 29.984 | 1404928 | 2442208 339968 149504 736256 53248 219136 | 1498112 | 30.514 | 1096704 | 2594816 The values of in-use and free add up to the value of 'total' you listed above, but somehow this seems wrong. If this is repeatable, can you also run in a second terminal something like: while true ; do date for sysctlname in \ vm.stats.vm.v_active_count \ vm.stats.vm.v_inactive_count \ vm.stats.vm.v_wire_count \ vm.stats.vm.v_cache_count \ vm.stats.vm.v_free_count do sysctl "$sysctlname" done sleep 3 done Another terminal can run: while true ; do date -u top | cat sleep 3 done Then I will try to see if I can make sense of what triggers the weird numbers you are seeing. The tricky part is that top(1) uses `int' as the data type for storing these results, and this is probably a mildly wrong idea on amd64 or systems with *lots* of memory. The size of `int' may not be large enough to hold the byte-size of large page counts. I tried something like: http://people.freebsd.org/~keramida/diff/top-uint64.diff but there are _many_ places where sizeof(int) limits what top uses, and this is not really a good fix (yet). - Giorgos From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 22:38:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C1A416A419 for ; Tue, 11 Sep 2007 22:38:27 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 5F29913C47E for ; Tue, 11 Sep 2007 22:38:25 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 18:26:15 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id E177311706; Tue, 11 Sep 2007 18:26:14 -0400 (EDT) Date: Tue, 11 Sep 2007 18:26:14 -0400 From: Ed Maste To: Jack Vogel Message-ID: <20070911222614.GA36962@sandvine.com> References: <200707130848.01101.jhb@freebsd.org> <2a41acea0707130921x38d35d3br62842ef118c93261@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0707130921x38d35d3br62842ef118c93261@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Sep 2007 22:26:15.0134 (UTC) FILETIME=[C3EE0FE0:01C7F4C2] Cc: freebsd-current@freebsd.org Subject: Re: em0 hijacking traffic to port 623 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 22:38:27 -0000 On Fri, Jul 13, 2007 at 09:21:53AM -0700, Jack Vogel wrote: > >> > > On Mon, 21 May 2007, Ian FREISLICH wrote: > >> > > > >> > > > Hi > >> > > > > >> > > > We've noticed an issue on our firewalls where the first em device > >> > > > in the system hijacks inbound port 623 tcp and udp. The OS never > >> > > > sees this traffic. [patch omitted] > Hardcoding this change into shared code is not the right place > to do it, however I'll take a look at that and figure out a more > appropriate approach. > > Jack Jack, do you have any update on adding a sysctl etc. to configure the management port hijacking? I was just bitten by the same problem and am going to just hardcode ~(E1000_MANC_RMCP_EN | E1000_MANC_0298_EN) for now but would like to switch to the fix that will actually end up in the driver. - Ed From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 01:18:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE6616A418 for ; Wed, 12 Sep 2007 01:18:52 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id 54C5813C480 for ; Wed, 12 Sep 2007 01:18:52 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id C2DFB16C86E0 for ; Tue, 11 Sep 2007 18:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.002, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CNKSFwv0lzl for ; Tue, 11 Sep 2007 18:18:39 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id 9E5D116C86DE for ; Tue, 11 Sep 2007 18:18:39 -0700 (PDT) Date: Tue, 11 Sep 2007 18:18:39 -0700 (PDT) From: Brooks Talley To: freebsd-current Message-ID: <7248470.49881189559919625.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.168.65.79] Subject: Compiling with gcc42 / reverting to CC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 01:18:52 -0000 Hi, everyone. A bit of a newb question here. I have a 7.0-current box that's been updated to the latest HEAD, and I need to rebuild the kernel. However, someone has helpfully configured the box to use GCC42 for make, and that's failing because 1) kern.mk has a CWARNFLAGS definition that GCC42 hates (-fformat-extensions), and 2) __FreeBSD_cc_version is not defined. Can someone(s) please tell me how to either get 7.0-current compiled on GCC42, or get make buildkernel to use good old CC? Thanks -Brooks From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 01:44:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A6D16A417 for ; Wed, 12 Sep 2007 01:44:08 +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 B7D1A13C459 for ; Wed, 12 Sep 2007 01:44:08 +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 l8C1i4iL020249; Tue, 11 Sep 2007 18:44:04 -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 l8C1i3gt020248; Tue, 11 Sep 2007 18:44:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 11 Sep 2007 18:44:03 -0700 From: Steve Kargl To: Brooks Talley Message-ID: <20070912014403.GA20208@troutmask.apl.washington.edu> References: <7248470.49881189559919625.JavaMail.root@zmail.illuminati.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7248470.49881189559919625.JavaMail.root@zmail.illuminati.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current Subject: Re: Compiling with gcc42 / reverting to CC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 01:44:09 -0000 On Tue, Sep 11, 2007 at 06:18:39PM -0700, Brooks Talley wrote: > > I have a 7.0-current box that's been updated to the latest HEAD, > and I need to rebuild the kernel. However, someone has helpfully > configured the box to use GCC42 for make, and that's failing because > 1) kern.mk has a CWARNFLAGS definition that GCC42 hates > (-fformat-extensions), and 2) __FreeBSD_cc_version is not defined. > > Can someone(s) please tell me how to either get 7.0-current > compiled on GCC42, or get make buildkernel to use good old CC? > Check /etc/make.conf for a CC variable. Try "make CC=cc buildkernel" or "setenv CC cc ; make buildkernel" or Ask "someone" for helpfully unconfigure GCC42. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 02:16:39 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EE016A417 for ; Wed, 12 Sep 2007 02:16:39 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id C711C13C428 for ; Wed, 12 Sep 2007 02:16:38 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by nz-out-0506.google.com with SMTP id l8so38651nzf for ; Tue, 11 Sep 2007 19:16:38 -0700 (PDT) Received: by 10.142.158.17 with SMTP id g17mr350776wfe.1189563397584; Tue, 11 Sep 2007 19:16:37 -0700 (PDT) Received: by 10.142.44.20 with HTTP; Tue, 11 Sep 2007 19:16:37 -0700 (PDT) Message-ID: <626eb4530709111916w55e04bcbp9da576bf6e60d171@mail.gmail.com> Date: Wed, 12 Sep 2007 11:16:37 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: gary.jennejohn@freenet.de In-Reply-To: <20070911112419.68e8ec0d@peedub.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> <626eb4530708221937h31c8f37fu9527e941ed4000b6@mail.gmail.com> <20070911112419.68e8ec0d@peedub.jennejohn.org> X-Google-Sender-Auth: b2d8f944fc874c01 Cc: attilio@freebsd.org, bruce@cran.org.uk, current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 02:16:39 -0000 On 9/11/07, Gary Jennejohn wrote: > On Thu, 23 Aug 2007 11:37:20 +0900 > "Hidetoshi Shimokawa" wrote: > > > It looks that the low level console is not locked though the high level console > > is locked by Giant. > > > > Could you try the attached patch? > > > > This patch solves the problem and should definitely be committed bfore 7.0. > > -- > Gary Jennejohn > > Yes, it should be committed. I sent a request for approval to re@ last week and waiting for approval. I also have a plan to MFC. Here is a detailed description of the patch. Serialize output routine of terminal emulator (te_puts()) by a lock. - The output routine of low level console is not protected by any lock by default. - Increment and decrement of sc->write_in_progress are not atomic and this may cause console hang. - We also have many other states used by emulator that should be protected by the lock. - This change does not fix interspersed messages which PRINTF_BUFR_SIZE kernel option should fix. MFC after: 1 week -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 02:55:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F7C16A418 for ; Wed, 12 Sep 2007 02:55:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id A893613C4A5 for ; Wed, 12 Sep 2007 02:55:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 04CEEEB5B6C; Wed, 12 Sep 2007 10:55:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id SHm63Ab5fEoY; Wed, 12 Sep 2007 10:55:22 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 63C13EB9950; Wed, 12 Sep 2007 10:55:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=qP3GbYWGso/kZ1TbBx0qGi8Zujx3TuttrI2urm8pLuVgl0IkCD4olcv8D+OROhDiV g6g865i7zNChmcbr3yL/w== Message-ID: <46E75502.50803@delphij.net> Date: Wed, 12 Sep 2007 10:54:58 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigECD2F4CEC49117670D73874B" Subject: [PATCH] wakeup keg if zone_max is altered X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 02:55:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECD2F4CEC49117670D73874B Content-Type: multipart/mixed; boundary="------------060100000105060302050304" This is a multi-part message in MIME format. --------------060100000105060302050304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Here is a patch that wakes up keg if zone_max is altered when necessay. Objections? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------060100000105060302050304 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="uma_core.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="uma_core.c.diff" Index: uma_core.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.147 diff -u -p -r1.147 uma_core.c --- uma_core.c 31 May 2007 22:52:14 -0000 1.147 +++ uma_core.c 12 Sep 2007 02:53:43 -0000 @@ -2514,6 +2514,18 @@ uma_zone_set_max(uma_zone_t zone, int ni if (keg->uk_maxpages * keg->uk_ipers < nitems) keg->uk_maxpages++; =20 + if (keg->uk_flags & UMA_ZFLAG_FULL) { + if (keg->uk_pages < keg->uk_maxpages) + keg->uk_flags &=3D ~UMA_ZFLAG_FULL; + + /*=20 + * We can handle one more allocation. Since we're clearing ZFLAG_FULL,= + * wake up all procs blocked on pages. This should be uncommon, so=20 + * keeping this simple for now (rather than adding count of blocked=20 + * threads etc). + */ + wakeup(keg); + } ZONE_UNLOCK(zone); } =20 --------------060100000105060302050304-- --------------enigECD2F4CEC49117670D73874B 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 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG51UCOfuToMruuMARClGBAJ9WjBxNWv7YGAiAIqs7+AZcNSNkGgCbBPsx DKzniFMRBOxoXXB4WGdBZSk= =aUP7 -----END PGP SIGNATURE----- --------------enigECD2F4CEC49117670D73874B-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 06:39:23 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00FE416A41A for ; Wed, 12 Sep 2007 06:39:23 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3724B13C458 for ; Wed, 12 Sep 2007 06:39:21 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l8BCnAW9020969 for ; Tue, 11 Sep 2007 22:49:14 +1000 Received: from camelot.theinternet.com.au (c211-30-133-243.carlnfd4.nsw.optusnet.com.au [211.30.133.243]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8BCmvrj016895; Tue, 11 Sep 2007 22:49:08 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 302496113; Tue, 11 Sep 2007 22:48:57 +1000 (EST) Date: Tue, 11 Sep 2007 22:48:57 +1000 From: Andrew Milton To: Luigi Rizzo Message-ID: <20070911124857.GW4840@camelot.theinternet.com.au> References: <20070906111028.A83649@xorpc.icir.org> <20070906222647.GB2737@kobe.laptop> <20070907000950.A91211@xorpc.icir.org> <20070907115021.GA2718@kobe.laptop> <20070907050310.A94579@xorpc.icir.org> <54b90fdf0709070654h103316f3sa3d423f4ff75fee3@mail.gmail.com> <20070911051653.A62022@xorpc.icir.org> <20070911123556.GF53667@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070911123556.GF53667@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: current@freebsd.org Subject: Re: how to tell 64 vs 32 bit architecture ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 06:39:23 -0000 On Tue, Sep 11, 2007 at 05:16:53AM -0700, Luigi Rizzo wrote: > > gcc 3.4 on a 32bit machine complains because the second constant > is too large. Can I ask why the 64 bit constant isn't 0xd00de123deadbeef , which would make bits 0-31 the same for both architectures, which might simplify the problem. #define MY_MAGIC 0xd00de123deadbeefLL int main(int argc, char **argv) { printf("0x%08x\n", MY_MAGIC); } outputs 0xdeadbeef on 32 bit architectures, so it IS truncating the top 32 bits. I know this doesn't solve the broader problem of detecting word length, but, it might solve your immediate problem. -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 08:27:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 411BC16A418 for ; Wed, 12 Sep 2007 08:27:53 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2006713C457 for ; Wed, 12 Sep 2007 08:27:52 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so164111waf for ; Wed, 12 Sep 2007 01:27:52 -0700 (PDT) Received: by 10.114.151.13 with SMTP id y13mr5747644wad.1189585672422; Wed, 12 Sep 2007 01:27:52 -0700 (PDT) Received: by 10.115.33.7 with HTTP; Wed, 12 Sep 2007 01:27:52 -0700 (PDT) Message-ID: Date: Wed, 12 Sep 2007 10:27:52 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> Subject: Re: Problems updating from 6.2-STABLE to -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: Wed, 12 Sep 2007 08:27:53 -0000 MjAwNy85LzEyLCBUb29NYW55IFNlY3JldHMgPHRvb21hbnlAdG9vbWFueS5uZXQ+Ogo+IE15IGFj dHVhbCBtYWtlLmNvbmYgZmxhZ3M6Cj4KPiBDUFVUWVBFPz1wZW50aXVtNAo+IENGTEFHUz0gLU9z IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlCgpPaywgd2l0aCBhIENGTEFHUyAtTyBvbmx5LCB0 aGUgImJ1aWxkd29ybGQgaXMgcnVuIGZpbmUuIElmIEkgd2lsbCBoYXZlCmFueSBwcm9ibGVtIHJl bGF0ZWQgdG8gdGhpcyBzdWJqZWN0LCBJIHdpbGwgb3BlbiBvdGhlciB0aHJlYWQuCgpUaGFuayB5 b3UgdmVyeSBtdWNoIQoKLS0gCkhhdmUgYSBuaWNlIGRheSAgOy0pClRvb01hbnlTZWNyZXRzCgo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09CkRpam8gQ29uZnVjaW86CiJFeMOtZ2V0ZSBtdWNo byBhIHRpIG1pc21vIHkgZXNwZXJhIHBvY28gZGUgbG9zIGRlbcOhcy4gQXPDrSB0ZSBhaG9ycmFy w6FzCmRpc2d1c3Rvcy4iCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0K From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 08:49:46 2007 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6291816A46C for ; Wed, 12 Sep 2007 08:49:46 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (goat.gigo.com [216.218.228.114]) by mx1.freebsd.org (Postfix) with ESMTP id 48C1A13C4B3 for ; Wed, 12 Sep 2007 08:49:46 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from 201.24.13.31 (201-24-13-31.bsace703.dsl.brasiltelecom.net.br [201.24.13.31]) by goat.gigo.com (Postfix) with ESMTP id 3C25FB8EC for ; Wed, 12 Sep 2007 01:49:45 -0700 (PDT) Received: (qmail 10068 invoked by uid 1001); 12 Sep 2007 05:49:14 -0300 Message-ID: <20070912084914.9985.qmail@exxodus.fedaykin.here> Date: Wed, 12 Sep 2007 05:49:14 -0259 From: Mario Sergio Fujikawa Ferreira To: FreeBSD-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 08:49:46 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I had 3 panics today. All seem to be related to ipf code. I have disabled ipf for the time being. I am attaching the kgdb backtraces. I am saving the cores. Let me know if there is anything I can do to help. FreeBSD exxodus.home.home 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep 10 15:01:49 BRT 2007 root@exxodus.home.home:/usr/obj/usr/src/sys/LIOUX i386 -current as of Sep 10 2007. Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vmcore.1.log" Script started on Tue Sep 11 23:20:45 2007 [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: panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: enter: panic Uptime: 3h53m15s Physical memory: 2030 MB Dumping 260 MB: 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x805a1f9f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x805a226b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x805d2e82 in sleepq_add (wchan=0x8086cc20, lock=0x0, wmesg=0x807dbf57 "ipf IP state rwlock", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #4 0x805a9e66 in _sx_xlock_hard (sx=0x8086cc20, tid=2236636352, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at /usr/src/sys/kern/kern_sx.c:548 #5 0x805a9f1e in _sx_xlock (sx=0x8086cc20, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at sx.h:153 #6 0x8047591c in fr_timeoutstate () at /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:3013 #7 0x80462059 in fr_slowtimer (ptr=0x0) at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:859 #8 0x805b3d99 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:281 #9 0x80585eb5 in ithread_loop (arg=0x85503310) at /usr/src/sys/kern/kern_intr.c:1036 #10 0x80583338 in fork_exit (callout=0x80585d00 , arg=0x85503310, frame=0xd6318d38) at /usr/src/sys/kern/kern_fork.c:797 #11 0x8078a840 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) quit Script done on Tue Sep 11 23:23:24 2007 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vmcore.2.log" Script started on Tue Sep 11 23:23:30 2007 [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: panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: enter: panic Uptime: 17m22s Physical memory: 2030 MB Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x805a1f9f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x805a226b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x805d2e82 in sleepq_add (wchan=0x8086cc20, lock=0x0, wmesg=0x807dbf57 "ipf IP state rwlock", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #4 0x805a9e66 in _sx_xlock_hard (sx=0x8086cc20, tid=2236636352, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at /usr/src/sys/kern/kern_sx.c:548 #5 0x805a9f1e in _sx_xlock (sx=0x8086cc20, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at sx.h:153 #6 0x8047591c in fr_timeoutstate () at /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:3013 #7 0x80462059 in fr_slowtimer (ptr=0x0) at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:859 #8 0x805b3d99 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:281 #9 0x80585eb5 in ithread_loop (arg=0x85503310) at /usr/src/sys/kern/kern_intr.c:1036 #10 0x80583338 in fork_exit (callout=0x80585d00 , arg=0x85503310, frame=0xd6318d38) at /usr/src/sys/kern/kern_fork.c:797 #11 0x8078a840 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) quit Script done on Tue Sep 11 23:23:49 2007 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vmcore.3.log" Script started on Tue Sep 11 23:36:45 2007 [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: panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 0 KDB: enter: panic Uptime: 48m49s Physical memory: 2030 MB Dumping 249 MB: 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x805a1f9f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x805a226b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x805d2e82 in sleepq_add (wchan=0x8086cc20, lock=0x0, wmesg=0x807dbf57 "ipf IP state rwlock", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #4 0x805a9e66 in _sx_xlock_hard (sx=0x8086cc20, tid=2236636352, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at /usr/src/sys/kern/kern_sx.c:548 #5 0x805a9f1e in _sx_xlock (sx=0x8086cc20, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at sx.h:153 #6 0x8047591c in fr_timeoutstate () at /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:3013 #7 0x80462059 in fr_slowtimer (ptr=0x0) at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:859 #8 0x805b3d99 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:281 #9 0x80585eb5 in ithread_loop (arg=0x85503310) at /usr/src/sys/kern/kern_intr.c:1036 #10 0x80583338 in fork_exit (callout=0x80585d00 , arg=0x85503310, frame=0xd6318d38) at /usr/src/sys/kern/kern_fork.c:797 #11 0x8078a840 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) list 205 call fork_exit 206 addl $12,%esp 207 /* cut from syscall */ 208 209 /* 210 * Return via doreti to handle ASTs. 211 */ 212 MEXITCOUNT 213 jmp doreti 214 (kgdb) up #1 0x805a1f9f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 409 doadump(); (kgdb) list 404 405 /* XXX This doesn't disable interrupts any more. Reconsider? */ 406 splhigh(); 407 408 if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold && !dumping) 409 doadump(); 410 411 /* Now that we're going to really halt the system... */ 412 EVENTHANDLER_INVOKE(shutdown_final, howto); 413 (kgdb) up #2 0x805a226b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 563 boot(bootopt); (kgdb) list 558 /*thread_lock(td); */ 559 td->td_flags |= TDF_INPANIC; 560 /* thread_unlock(td); */ 561 if (!sync_on_panic) 562 bootopt |= RB_NOSYNC; 563 boot(bootopt); 564 } 565 566 /* 567 * Support for poweroff delay. (kgdb) up #3 0x805d2e82 in sleepq_add (wchan=0x8086cc20, lock=0x0, wmesg=0x807dbf57 "ipf IP state rwlock", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 289 KASSERT(!(td->td_pflags & TDP_NOSLEEPING), (kgdb) list 284 MPASS(td->td_sleepqueue != NULL); 285 MPASS(wchan != NULL); 286 MPASS((queue >= 0) && (queue < NR_SLEEPQS)); 287 288 /* If this thread is not allowed to sleep, die a horrible death. */ 289 KASSERT(!(td->td_pflags & TDP_NOSLEEPING), 290 ("Trying sleep, but thread marked as sleeping prohibited")); 291 292 /* Look up the sleep queue associated with the wait channel 'wchan'. */ 293 sq = sleepq_lookup(wchan); (kgdb) up #4 0x805a9e66 in _sx_xlock_hard (sx=0x8086cc20, tid=2236636352, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at /usr/src/sys/kern/kern_sx.c:548 548 sleepq_add(&sx->lock_object, NULL, sx->lock_object.lo_name, (kgdb) list 543 __func__, sx); 544 545 GIANT_SAVE(); 546 lock_profile_obtain_lock_failed(&sx->lock_object, &contested, 547 &waittime); 548 sleepq_add(&sx->lock_object, NULL, sx->lock_object.lo_name, 549 SLEEPQ_SX | ((opts & SX_INTERRUPTIBLE) ? 550 SLEEPQ_INTERRUPTIBLE : 0), SQ_EXCLUSIVE_QUEUE); 551 if (!(opts & SX_INTERRUPTIBLE)) 552 sleepq_wait(&sx->lock_object); (kgdb) up #5 0x805a9f1e in _sx_xlock (sx=0x8086cc20, opts=0, file=0x807dbe72 "/usr/src/sys/contrib/ipfilter/netinet/ip_state.c", line=3013) at sx.h:153 153 error = _sx_xlock_hard(sx, tid, opts, file, line); (kgdb) list 148 { 149 uintptr_t tid = (uintptr_t)td; 150 int error = 0; 151 152 if (!atomic_cmpset_acq_ptr(&sx->sx_lock, SX_LOCK_UNLOCKED, tid)) 153 error = _sx_xlock_hard(sx, tid, opts, file, line); 154 else 155 lock_profile_obtain_lock_success(&sx->lock_object, 0, 0, file, 156 line); 157 (kgdb) up #6 0x8047591c in fr_timeoutstate () at /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:3013 3013 WRITE_ENTER(&ipf_state); (kgdb) list 3008 ipftqent_t *tqe, *tqn; 3009 ipstate_t *is; 3010 SPL_INT(s); 3011 3012 SPL_NET(s); 3013 WRITE_ENTER(&ipf_state); 3014 for (ifq = ips_tqtqb; ifq != NULL; ifq = ifq->ifq_next) 3015 for (tqn = ifq->ifq_head; ((tqe = tqn) != NULL); ) { 3016 if (tqe->tqe_die > fr_ticks) 3017 break; (kgdb) up #7 0x80462059 in fr_slowtimer (ptr=0x0) at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:859 859 fr_timeoutstate(); (kgdb) list 854 { 855 READ_ENTER(&ipf_global); 856 857 ipf_expiretokens(); 858 fr_fragexpire(); 859 fr_timeoutstate(); 860 fr_natexpire(); 861 fr_authexpire(); 862 fr_ticks++; 863 if (fr_running <= 0) (kgdb) up #8 0x805b3d99 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:281 281 c_func(c_arg); (kgdb) list 276 } 277 #ifdef DIAGNOSTIC 278 binuptime(&bt1); 279 #endif 280 THREAD_NO_SLEEPING(); 281 c_func(c_arg); 282 THREAD_SLEEPING_OK(); 283 #ifdef DIAGNOSTIC 284 binuptime(&bt2); 285 bintime_sub(&bt2, &bt1); (kgdb) up #9 0x80585eb5 in ithread_loop (arg=0x85503310) at /usr/src/sys/kern/kern_intr.c:1036 1036 ih->ih_handler(ih->ih_argument); (kgdb) list 1031 __func__, p->p_pid, (void *)ih->ih_handler, 1032 ih->ih_argument, ih->ih_name, ih->ih_flags); 1033 1034 if (!(ih->ih_flags & IH_MPSAFE)) 1035 mtx_lock(&Giant); 1036 ih->ih_handler(ih->ih_argument); 1037 if (!(ih->ih_flags & IH_MPSAFE)) 1038 mtx_unlock(&Giant); 1039 } 1040 if (!(ie->ie_flags & IE_SOFT)) (kgdb) up #10 0x80583338 in fork_exit (callout=0x80585d00 , arg=0x85503310, frame=0xd6318d38) at /usr/src/sys/kern/kern_fork.c:797 797 callout(arg, frame); (kgdb) list 792 * cpu_set_fork_handler intercepts this function call to 793 * have this call a non-return function to stay in kernel mode. 794 * initproc has its own fork handler, but it does return. 795 */ 796 KASSERT(callout != NULL, ("NULL callout in fork_exit")); 797 callout(arg, frame); 798 799 /* 800 * Check if a kernel thread misbehaved and returned from its main 801 * function. (kgdb) up #11 0x8078a840 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 205 call fork_exit Current language: auto; currently asm (kgdb) list 200 201 ENTRY(fork_trampoline) 202 pushl %esp /* trapframe pointer */ 203 pushl %ebx /* arg1 */ 204 pushl %esi /* function */ 205 call fork_exit 206 addl $12,%esp 207 /* cut from syscall */ 208 209 /* (kgdb) quit Script done on Tue Sep 11 23:37:21 2007 --zhXaljGHf11kAtnf-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 08:56:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AE5816A420 for ; Wed, 12 Sep 2007 08:56:10 +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 898A813C442 for ; Wed, 12 Sep 2007 08:56:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IVO09-0001S8-Ok for freebsd-current@freebsd.org; Wed, 12 Sep 2007 10:55:13 +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 ; Wed, 12 Sep 2007 10:55:13 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Sep 2007 10:55:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 12 Sep 2007 10:53:36 +0200 Lines: 72 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigB64D28F9CEE8277E946D6B37" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) X-Enigmail-Version: 0.94.4.0 Sender: news Subject: Panic in arpresolve->rt_check? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 08:56:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB64D28F9CEE8277E946D6B37 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I've got several crash dumps caused by the following: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 01 fault virtual address =3D 0x188 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0654e25 stack pointer =3D 0x28:0xe38b6924 frame pointer =3D 0x28:0xe38b693c code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 15 (swi1: net) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c09322d0,e38b6800,c0661841,c094d6f1,0,...) at=20 db_trace_self_wrapper+0x26 kdb_backtrace(c094d6f1,0,c0903950,e38b680c,0,...) at kdb_backtrace+0x29 panic(c0903950,c094e9ad,c4d5677c,1,1,...) at panic+0x111 trap_fatal(c094e8af,c,0,11000000,c4d56558,...) at trap_fatal+0x383 trap(e38b68e4) at trap+0x12b calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc0654e25, esp =3D 0xe38b6924, ebp =3D 0xe38b693c = --- _mtx_lock_sleep(c5e10c90,c4d10aa0,0,0,0,...) at _mtx_lock_sleep+0x85 rt_check(e38b6984,e38b69a0,c57963f0,0,0,...) at rt_check+0x120 arpresolve(c4e27000,c5e0fbb8,c5f20e00,c57963f0,e38b69ba,...) at=20 arpresolve+0xb4 ether_output(c4e27000,c5f20e00,c57963f0,c5e0fbb8,c8a6a3f0,...) at=20 ether_output+0x7e ip_output(c5f20e00,0,e38b6a28,0,0,...) at ip_output+0xa59 tcp_output(c89e2168,8,36ee80,0,0,...) at tcp_output+0x1493 tcp_do_segment(c89e2168,28,0,6b4835a1,901f,...) at tcp_do_segment+0x1c55 tcp_input(c60e1700,14,c4ea3c00,1,0,...) at tcp_input+0xd2e ip_input(c60e1700,0,c08b0028,e38b0028,0,...) at ip_input+0x6b0 netisr_processqueue(c4d10aa0,0,1,1000000,c4d10aa0,...) at=20 netisr_processqueue+0xdb swi_net(0,0,c092df73,46b,0,...) at swi_net+0x12b ithread_loop(c4d0c270,e38b6d38,0,0,0,...) at ithread_loop+0x1cb fork_exit(c0643a60,c4d0c270,e38b6d38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 This is on a recent -CURRENT, i386, SMP. NIC is fxp. If anyone needs=20 more data, please let me know - this is a critical problem for me. The=20 same machine worked ok with 6-STABLE. --------------enigB64D28F9CEE8277E946D6B37 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 iD8DBQFG56kXldnAQVacBcgRA7luAKCCoWCy9QM+7BoTUWyA2U2K3bovMwCeOfH0 DnjRK61HUxuGNzA5Sg3VlSY= =1e0B -----END PGP SIGNATURE----- --------------enigB64D28F9CEE8277E946D6B37-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 09:03:20 2007 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EAA316A46E; Wed, 12 Sep 2007 09:03:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 7442413C46A; Wed, 12 Sep 2007 09:03:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46E7AB54.9060103@FreeBSD.org> Date: Wed, 12 Sep 2007 11:03:16 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20070912084914.9985.qmail@exxodus.fedaykin.here> In-Reply-To: <20070912084914.9985.qmail@exxodus.fedaykin.here> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-current@FreeBSD.org, re@FreeBSD.org Subject: Re: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 09:03:20 -0000 Mario Sergio Fujikawa Ferreira wrote: > Hi, > > I had 3 panics today. All seem to be related to ipf code. > I have disabled ipf for the time being. > > I am attaching the kgdb backtraces. I am saving the cores. > Let me know if there is anything I can do to help. > > FreeBSD exxodus.home.home 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep 10 15:01:49 BRT 2007 root@exxodus.home.home:/usr/obj/usr/src/sys/LIOUX i386 > > -current as of Sep 10 2007. > > Regards, Yes, known issue. The lack of response by the ipf maintainer so far suggests it probably will not be fixed in 7.0. This should be documented in the relnotes. Kris From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 09:12:40 2007 Return-Path: Delivered-To: FreeBSD-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6727116A417 for ; Wed, 12 Sep 2007 09:12:40 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id E973B13C45E for ; Wed, 12 Sep 2007 09:12:39 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so121368nfb for ; Wed, 12 Sep 2007 02:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=vD9D4cIaltNFlwtD+2wias7pQ9MGublELC5fsN8wxOE=; b=MvF5AWdi6L+9Pdx0zvOHoh6uuhpxMngjuw0/iAaNd+EG+M+NdRNr5A7dYAS2N6sCb92mv+YKHq2A7B4wD8Ha0BHOHUE7wJPrxtc7SbgWpXeFwnHnbChbNg5vJXaQ6xkjrTgN9K1kVEvPWI1mG19RLMErGZikKuhopkIbUio2qr0= 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=uH3fSOxmsCEqaiejfje6fC27ojmcR3fyEc+77fx1kkK5LhsEvovkyT0n8blpC0Z2zIC9J8R+tiM/L+SnsFuOTqzXOH9nw5GFzE2b02iUOEhBldo/0D/puwsx7N1P1oOZEfnJwRym6Imftwr6CGfDXid5/MhHATS5eXldpPiUZgo= Received: by 10.86.81.8 with SMTP id e8mr5268755fgb.1189588358469; Wed, 12 Sep 2007 02:12:38 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Wed, 12 Sep 2007 02:12:38 -0700 (PDT) Message-ID: <499c70c0709120212x364a4ff4s1a3130e532d48c14@mail.gmail.com> Date: Wed, 12 Sep 2007 12:12:38 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Kris Kennaway" In-Reply-To: <46E7AB54.9060103@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070912084914.9985.qmail@exxodus.fedaykin.here> <46E7AB54.9060103@FreeBSD.org> Cc: FreeBSD-current@freebsd.org Subject: Re: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 09:12:40 -0000 On 9/12/07, Kris Kennaway wrote: > Mario Sergio Fujikawa Ferreira wrote: > > Hi, > > > > I had 3 panics today. All seem to be related to ipf code. > > I have disabled ipf for the time being. > > > > I am attaching the kgdb backtraces. I am saving the cores. > > Let me know if there is anything I can do to help. > > > > FreeBSD exxodus.home.home 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep 10 15:01:49 BRT 2007 root@exxodus.home.home:/usr/obj/usr/src/sys/LIOUX i386 > > > > -current as of Sep 10 2007. > > > > Regards, > > Yes, known issue. The lack of response by the ipf maintainer so far > suggests it probably will not be fixed in 7.0. This should be > documented in the relnotes. > > Kris pf will do great job since ipf has major issues. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 09:25:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7978716A420 for ; Wed, 12 Sep 2007 09:25:43 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA3513C461 for ; Wed, 12 Sep 2007 09:25:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54B86.dip.t-dialin.net [84.165.75.134]) by redbull.bpaserver.net (Postfix) with ESMTP id 518B22E1BC; Wed, 12 Sep 2007 11:25:10 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 1DBD55B4926; Wed, 12 Sep 2007 11:24:52 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l8C9OpRR005239; Wed, 12 Sep 2007 11:24:51 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 12 Sep 2007 11:24:51 +0200 Message-ID: <20070912112451.gqrz00we8000kook@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 12 Sep 2007 11:24:51 +0200 From: Alexander Leidinger To: TooMany Secrets References: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Problems updating from 6.2-STABLE to -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: Wed, 12 Sep 2007 09:25:43 -0000 Quoting TooMany Secrets (from Wed, 12 Sep 2007 10:27:52 +0200): > 2007/9/12, TooMany Secrets : >> My actual make.conf flags: >> >> CPUTYPE?=pentium4 >> CFLAGS= -Os -fno-strict-aliasing -pipe > > Ok, with a CFLAGS -O only, the "buildworld is run fine. If I will have > any problem related to this subject, I will open other thread. BTW: we noticed that the output of -Os compiled programs seems to be larger than compiled with -O2 (with gcc 4.2). Bye, Alexander. -- QOTD: "It wouldn't have been anything, even if it were gonna be a thing." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 09:45:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7E616A41A for ; Wed, 12 Sep 2007 09:45:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 519F413C45B for ; Wed, 12 Sep 2007 09:45:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54B86.dip.t-dialin.net [84.165.75.134]) by redbull.bpaserver.net (Postfix) with ESMTP id 403582E0BA; Wed, 12 Sep 2007 11:45:39 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BEAA35B4926; Wed, 12 Sep 2007 11:45:20 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l8C9jKDC008671; Wed, 12 Sep 2007 11:45:20 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 12 Sep 2007 11:45:20 +0200 Message-ID: <20070912114520.yvkfkufh8g0o8gko@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 12 Sep 2007 11:45:20 +0200 From: Alexander Leidinger To: Alexander Leidinger References: <20070911192507.GB59290@ace.b020.ceid.upatras.gr> <20070912112451.gqrz00we8000kook@webmail.leidinger.net> In-Reply-To: <20070912112451.gqrz00we8000kook@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org, TooMany Secrets Subject: Re: Problems updating from 6.2-STABLE to -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: Wed, 12 Sep 2007 09:45:47 -0000 Quoting Alexander Leidinger (from Wed, 12 =20 Sep 2007 11:24:51 +0200): > Quoting TooMany Secrets (from Wed, 12 Sep 2007 > 10:27:52 +0200): > >> 2007/9/12, TooMany Secrets : >>> My actual make.conf flags: >>> >>> CPUTYPE?=3Dpentium4 >>> CFLAGS=3D -Os -fno-strict-aliasing -pipe >> >> Ok, with a CFLAGS -O only, the "buildworld is run fine. If I will have >> any problem related to this subject, I will open other thread. > > BTW: we noticed that the output of -Os compiled programs seems to be > larger than compiled with -O2 (with gcc 4.2). Ooops... sorry, I wanted to write that the output of gcc 4.2 (the =20 compiled programs) when using the -Os option, is larger than with -O2. Bye, Alexander. Bye, Alexander. --=20 When smashing monuments, save the pedestals -- they always come in handy. =09=09-- Stanislaw J. Lem, "Unkempt Thoughts" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 11:13:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9A8B16A421 for ; Wed, 12 Sep 2007 11:13:45 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 46BE113C4D1 for ; Wed, 12 Sep 2007 11:13:44 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8CBDcQx070225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 13:13:43 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l8CBDcQa007842 for ; Wed, 12 Sep 2007 13:13:38 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from localhost (localhost [[UNIX: localhost]]) by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l8CBEmIU012416 for freebsd-current@freebsd.org; Wed, 12 Sep 2007 13:14:48 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Wed, 12 Sep 2007 13:14:48 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2909796.1kqLfVZrLN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709121314.48299.h.schmalzbauer@omnisec.de> Subject: ACPI question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 11:13:45 -0000 --nextPart2909796.1kqLfVZrLN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I have some, for me, strange issue with HW probing. If I enable ACPI the lm device isn't detected, if I disable ACPI it is=20 recognized (and works) When ACPI enbled I get the following lines, what do they mean: acpacpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1ede0000 (3) failei0: reservation of 0, a0000= =20 (3) failed Thanks, =2DHarry --nextPart2909796.1kqLfVZrLN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG58ooLDqVQ9VXb8gRAgTHAJ9gOoaDZKW9iiTgd6mZKos2GatMnACfaEIz Hh1PJVWGO/X1REcz65J7L74= =2KuI -----END PGP SIGNATURE----- --nextPart2909796.1kqLfVZrLN-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 11:35:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF7C16A41A for ; Wed, 12 Sep 2007 11:35:35 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mta02.xtra.co.nz (mta02.xtra.co.nz [210.54.141.253]) by mx1.freebsd.org (Postfix) with ESMTP id 17A4E13C45D for ; Wed, 12 Sep 2007 11:35:34 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fep03.xtra.co.nz ([172.23.12.31]) by mta02.xtra.co.nz with ESMTP id <20070912113529.QSYB2671.mta02.xtra.co.nz@fep03.xtra.co.nz> for ; Wed, 12 Sep 2007 23:35:29 +1200 Received: from serv.int.fubar.geek.nz ([219.89.91.5]) by fep03.xtra.co.nz with ESMTP id <20070912113528.YSMD27104.fep03.xtra.co.nz@serv.int.fubar.geek.nz> for ; Wed, 12 Sep 2007 23:35:28 +1200 Date: Wed, 12 Sep 2007 23:35:27 +1200 From: Andrew Turner To: freebsd-current@freebsd.org Message-ID: <20070912233527.63f97084@hermies.int.fubar.geek.nz> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Tracking down problems with vm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 11:35:35 -0000 I'm working on tracking down the problems I've found running FreeBSD on XEN's full virtualization. I'm looking at fixing a page fault in kernel when INVARIANTS is enabled. The problem is in uma_dbg_alloc slab->us_data is NULL. This means freei is set to a value that is too large for the slabref->us_freelist array. I've placed extra debugging code in the uma functions to try to find where us_data is set to NULL. The point I found is in the call to uma_dbg_getslab from uma_dbg_alloc. I've not managed to track down where it was set to NULL however. Can anyone give me a hint as to where to look to track down why the us_data is NULL? Andrew -- Andrew Turner http://fubar.geek.nz/blog/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 11:47:59 2007 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E49516A421; Wed, 12 Sep 2007 11:47:59 +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 3E29513C494; Wed, 12 Sep 2007 11:47:59 +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 F2EAB48CBD; Wed, 12 Sep 2007 07:47:58 -0400 (EDT) Date: Wed, 12 Sep 2007 12:47:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <46E7AB54.9060103@FreeBSD.org> Message-ID: <20070912124704.C79170@fledge.watson.org> References: <20070912084914.9985.qmail@exxodus.fedaykin.here> <46E7AB54.9060103@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: re@FreeBSD.org, FreeBSD-current@FreeBSD.org, Mario Sergio Fujikawa Ferreira Subject: Re: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 11:47:59 -0000 On Wed, 12 Sep 2007, Kris Kennaway wrote: > Mario Sergio Fujikawa Ferreira wrote: >> I had 3 panics today. All seem to be related to ipf code. I have >> disabled ipf for the time being. >> >> I am attaching the kgdb backtraces. I am saving the cores. Let me know >> if there is anything I can do to help. >> >> FreeBSD exxodus.home.home 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep 10 >> 15:01:49 BRT 2007 root@exxodus.home.home:/usr/obj/usr/src/sys/LIOUX i386 >> >> -current as of Sep 10 2007. > > Yes, known issue. The lack of response by the ipf maintainer so far > suggests it probably will not be fixed in 7.0. This should be documented in > the relnotes. The quick, and probably correct, fix is to replace all use of sx(9) with rw(9) in ipf. There might be places where a copying/copyout is being performed with the lock held, in which case this will trigger new warnings. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 11:54:38 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53BB216A46D for ; Wed, 12 Sep 2007 11:54:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id BCEF413C491 for ; Wed, 12 Sep 2007 11:54:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l8CBrFWj078559; Wed, 12 Sep 2007 13:53:20 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l8CBrFvG078558; Wed, 12 Sep 2007 13:53:15 +0200 (CEST) (envelope-from olli) Date: Wed, 12 Sep 2007 13:53:15 +0200 (CEST) Message-Id: <200709121153.l8CBrFvG078558@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, h.schmalzbauer@omnisec.de In-Reply-To: <200709112118.43342.h.schmalzbauer@omnisec.de> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 12 Sep 2007 13:53:20 +0200 (CEST) Cc: Subject: Re: padlock not mentioned in NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, h.schmalzbauer@omnisec.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 11:54:38 -0000 Harald Schmalzbauer wrote: > there is such a wonderful padlock(4) device but it's not mentioned in > NOTES. I think it belongs to sys/i386/conf/NOTES. To whomever is taking care of that: Please also add an entry to /boot/defaults/loader.conf in the "Other modules" section, like this: padlock_load="NO" # Crypto + RNG in VIA C3, C7 and Eden CPUs (I do have padlock_load="YES" in my /boot/loader.conf for ages. It's working perfectly fine.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 11:57:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9E016A41A for ; Wed, 12 Sep 2007 11:57:31 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD2D13C467 for ; Wed, 12 Sep 2007 11:57:30 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.1/8.14.1) with ESMTP id l8CBTbgg088742; Wed, 12 Sep 2007 13:29:37 +0200 (CEST) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.1/8.14.1/Submit) id l8CBTbJR088741; Wed, 12 Sep 2007 07:29:37 -0400 (EDT) (envelope-from cracauer) Date: Wed, 12 Sep 2007 07:29:37 -0400 From: Martin Cracauer To: "Bjoern A. Zeeb" Message-ID: <20070912112937.GA88680@cons.org> References: <20070911212720.K58095@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070911212720.K58095@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD current mailing list Subject: Re: mount -uw / does not work in boot -s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 11:57:31 -0000 Bjoern A. Zeeb wrote on Tue, Sep 11, 2007 at 09:31:49PM +0000: > Hi, > > if you boot -s on a HEAD and try to mount -uw / it will fail to update > the mount if you do not have a /etc/fstab. The fstab part is the key > to this. With an /etc/fstab everything seems to work just smoothly but > how to touch the fstab if you cannot mount the fs rw? > > Neither > mount -uw / > mount -u -o rw / > mount -uw /dev/... / > mount -u -o rw /dev/... / I had the same problem recently. For me, just mount -u / worked, and even if the fstab entry was having the wrong device. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 13:08:35 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2CA416A417 for ; Wed, 12 Sep 2007 13:08:35 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 681BA13C45A for ; Wed, 12 Sep 2007 13:08:33 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d96.q.ppp-pool.de [89.53.125.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 4E7AF12883F; Wed, 12 Sep 2007 14:43:54 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) (Authenticated sender: vwerth@bellona.sz.vwsoft.com) by mail.vtec.ipme.de (Postfix) with ESMTP id 466223F43E; Wed, 12 Sep 2007 14:41:25 +0200 (CEST) Message-ID: <46E7DF04.2000803@vwsoft.com> Date: Wed, 12 Sep 2007 14:43:48 +0200 From: Volker User-Agent: Thunderbird 2.0.0.6 (X11/20070807) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20070911212720.K58095@maildrop.int.zabbadoz.net> In-Reply-To: <20070911212720.K58095@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1190205692.53316@LC5EoMY9PPNYleE4MucxPQ X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: FreeBSD current mailing list Subject: Re: mount -uw / does not work in boot -s X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 13:08:35 -0000 On 12/23/-58 20:59, Bjoern A. Zeeb wrote: > Neither > mount -uw / > mount -u -o rw / > mount -uw /dev/... / > mount -u -o rw /dev/... / > > work. The versions with the /dev/... / do not seem to give an error > message but a mount afterwards shows that / is still read-only. > > The filesystem was clean upon boot and no fsck was run (I know there > is another problem after fsck I think). I think I remember I've had the same (or something similar) on a 6.2-RELEASE box recently (so not just a -CURRENT problem). I had a typo in fstab and was unable to mount root writeable as the root fs entry was wrong in fstab. I'm quite unsure how I solved that problem (can't remember). From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 14:33:20 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AB0B16A419 for ; Wed, 12 Sep 2007 14:33:20 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1972813C48D for ; Wed, 12 Sep 2007 14:33:20 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IVTHK-000EAo-DT for freebsd-current@FreeBSD.org; Wed, 12 Sep 2007 18:33:18 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IVTIV-0001MZ-RY for freebsd-current@FreeBSD.org; Wed, 12 Sep 2007 18:34:31 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Wed, 12 Sep 2007 18:34:31 +0400 Message-ID: <89849832@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: sshd and a "command" option at ~/.ssh/authorized_keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 14:33:20 -0000 Hi! With 'command="/bin/echo You are $USER!"' at ~/.ssh/authorized_keys: $ ssh You are duser! <-- is'a real username But with 'command="/bin/echo You invoked $SSH_ORIGINAL_COMMAND!"': $ ssh You invoked ! ^^^^^^^^^^^^^ Is this a bug? (Yes, I know about security issues etc.) If I use a script at the "command", the invoked command is shown. The man page says: ----- The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environ- ment variable. Note that this option applies to shell, command or subsystem execution. ----- The system is (from Sep 02): $ uname -srm FreeBSD 7.0-CURRENT amd64 Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 14:39:37 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B419816A417 for ; Wed, 12 Sep 2007 14:39:37 +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 25B4713C469 for ; Wed, 12 Sep 2007 14:39:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A70E217104; Wed, 12 Sep 2007 14:39:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l8CEdZfn018074; Wed, 12 Sep 2007 14:39:35 GMT (envelope-from phk@critter.freebsd.dk) To: Boris Samorodov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 12 Sep 2007 18:34:31 +0400." <89849832@srv.sem.ipt.ru> Date: Wed, 12 Sep 2007 14:39:35 +0000 Message-ID: <18073.1189607975@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.org Subject: Re: sshd and a "command" option at ~/.ssh/authorized_keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 14:39:37 -0000 In message <89849832@srv.sem.ipt.ru>, Boris Samorodov writes: >Hi! > > >With 'command="/bin/echo You are $USER!"' at ~/.ssh/authorized_keys: >$ ssh >You are duser! <-- is'a real username > >But with 'command="/bin/echo You invoked $SSH_ORIGINAL_COMMAND!"': >$ ssh >You invoked ! >^^^^^^^^^^^^^ >Is this a bug? (Yes, I know about security issues etc.) Try: ssh you_need_to_give_a_command_to_actually_see_it -- 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 Wed Sep 12 14:48:46 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D620816A41A for ; Wed, 12 Sep 2007 14:48:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8065F13C45D for ; Wed, 12 Sep 2007 14:48:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IVTWH-000ECJ-7w; Wed, 12 Sep 2007 18:48:45 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IVTXS-0001N4-N3; Wed, 12 Sep 2007 18:49:58 +0400 To: "Poul-Henning Kamp" References: <18073.1189607975@critter.freebsd.dk> From: Boris Samorodov Date: Wed, 12 Sep 2007 18:49:58 +0400 In-Reply-To: <18073.1189607975@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed\, 12 Sep 2007 14\:39\:35 +0000") Message-ID: <07763369@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: sshd and a "command" option at ~/.ssh/authorized_keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 14:48:46 -0000 On Wed, 12 Sep 2007 14:39:35 +0000 Poul-Henning Kamp wrote: > In message <89849832@srv.sem.ipt.ru>, Boris Samorodov writes: > >With 'command="/bin/echo You are $USER!"' at ~/.ssh/authorized_keys: > >$ ssh > >You are duser! <-- is'a real username > > > >But with 'command="/bin/echo You invoked $SSH_ORIGINAL_COMMAND!"': > >$ ssh > >You invoked ! > >^^^^^^^^^^^^^ > >Is this a bug? (Yes, I know about security issues etc.) > Try: > ssh you_need_to_give_a_command_to_actually_see_it Well, I see I'm a moron. :-( Poul-Henning, thank you for you kind answer. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 16:29:46 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9857216A421; Wed, 12 Sep 2007 16:29:46 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0573313C457; Wed, 12 Sep 2007 16:29:45 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l8CGTiOQ010109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 20:29:53 +0400 Message-ID: <46E813EA.4020908@FreeBSD.org> Date: Wed, 12 Sep 2007 12:29:30 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Harald Schmalzbauer , freebsd-current@FreeBSD.org References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260054.42892.h.schmalzbauer@omnisec.de> <46D0BEEF.1020601@FreeBSD.org> <200709112348.07052.h.schmalzbauer@omnisec.de> In-Reply-To: <200709112348.07052.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Shteryana Shopova , "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 16:29:46 -0000 On 11/09/2007 17:47, Harald Schmalzbauer wrote: > Am Sonntag, 26. August 2007 01:44:47 schrieb Constantine A. Murenin: > [schnip] > >>P.S. BTW, please do report back how the tests went. Don't forget to >>include the information on which exact chip you tested (for example, you >>might have tried this code on Winbond W83627DHG and Core 2 Duo E4300). > > > Hello, > > I had only tested some newer hardware with core2 CPU (E6750) and coretemp > doesn't report correct values for that CPU (25œC, this is at least 10œ Thanks, but this must be a bug in the default coretemp(4), not really related to the framework, so you might want to report to rpaulo@, cc'ing des@ and cnst@. > difference) and the boards doesn't neccessarily have a HW monitor chip, so I > haven't reported anything yet. > > But, > I'm about to test some VIA C7 boards and accidentaly found that if I disable > ACPI (hint.acpi.0.disabled=1), dmesg shows a lm sensor: > lm0: at port 0x290-0x297 on isa0 > > Also systat -sensors shows adaequat values corresponding to what the BIOS HW > monitor reports. > > But as soon as I boot default with ACPI enabled, lm0 vanishes. It's probably something to do with ACPI (duh!), I'm not certain what it is or why it happens. I have the following chip: lm0: at port 0x290-0x297 on isa0 And it works fine with acpi turned on, so I tend to think that you're experiencing a bug that is somewhere else in the tree. > Thanks for any hints. > > -Harry > > P.S. The patch doesn't apply cleanly for the sysctl man page, haven't had time > to investigate yet. That's a good thing, because it means that some fixes were already integrated into CVS. ;) P.S. I'll have a new patch soon, which will improve sysctl(3) support and compatibility with OpenBSD, will feature sysctl(8) support, and will include a new driver for ITE Tech Super I/O Hardware Monitors, too. ;) C. From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 17:03:26 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1704116A417 for ; Wed, 12 Sep 2007 17:03:26 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.freebsd.org (Postfix) with ESMTP id B796113C459 for ; Wed, 12 Sep 2007 17:03:25 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id 5EF745C50D; Wed, 12 Sep 2007 18:45:35 +0200 (CEST) Date: Wed, 12 Sep 2007 18:45:35 +0200 From: Thomas Quinot To: Patrick Hajek Message-ID: <20070912164535.GA84727@melamine.cuivre.fr.eu.org> References: <20070911210234.GC21433@lbl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070911210234.GC21433@lbl.gov> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.16 (2007-06-09) Cc: claus@endresconsulting.com, current@FreeBSD.ORG, bug-followup@freebsd.org Subject: Re: kern/115614: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 17:03:26 -0000 * Patrick Hajek, 2007-09-11 : > Commenting out atapicam_load="YES" in loader.conf and not precompiled it in > the kernel, the errors disappear. > > dmesg shows: > > d0: 95205MB at ata0-master UDMA100 > acd0: DVDR at ata1-master UDMA33 > > No sense errors. So, it appears to point to the atapi-cam module. Don't jump to conclusions hastily. Just because an error shows up only when ATAPI/CAM is loaded doesn't mean it's necessarily a bug there. > Suggestions? It looks to me like this is similar to the issue described in kern/115614. In general, it's a good habit to first check for an already open PR when you encounter a problem, and to open one if there isn't an existing one. This ensure that the issue and its resolution are properly tracked and do not fall into the cracks. It is all to easy to miss or lose track of an untracked discussion on -current. To help investigate this issue, it would be useful to identify as precisely as possible at what point of 6.2-STABLE it appeared. Also, boot -v output and CAM debugging traces (see "man 4 cam") will be useful. Please preserve subject line and include bug-followup@freebsd.org in all correspondence to ensure a proper audit trail. Thanks! Thomas. From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 17:27:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA7016A41A for ; Wed, 12 Sep 2007 17:27:57 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7F68413C46E for ; Wed, 12 Sep 2007 17:27:57 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan@localhost [127.0.0.1]) by dan.emsphone.com (8.14.1/8.14.1) with ESMTP id l8CHRqgd047425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 12:27:52 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1/Submit) id l8CHRqoS047424; Wed, 12 Sep 2007 12:27:52 -0500 (CDT) (envelope-from dan) Date: Wed, 12 Sep 2007 12:27:52 -0500 From: Dan Nelson To: Ivan Voras Message-ID: <20070912172752.GA13960@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Panic in arpresolve->rt_check? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 17:27:57 -0000 In the last episode (Sep 12), Ivan Voras said: > I've got several crash dumps caused by the following: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0x188 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0654e25 > stack pointer = 0x28:0xe38b6924 > frame pointer = 0x28:0xe38b693c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 15 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c09322d0,e38b6800,c0661841,c094d6f1,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c094d6f1,0,c0903950,e38b680c,0,...) at kdb_backtrace+0x29 > panic(c0903950,c094e9ad,c4d5677c,1,1,...) at panic+0x111 > trap_fatal(c094e8af,c,0,11000000,c4d56558,...) at trap_fatal+0x383 > trap(e38b68e4) at trap+0x12b > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0654e25, esp = 0xe38b6924, ebp = 0xe38b693c --- > _mtx_lock_sleep(c5e10c90,c4d10aa0,0,0,0,...) at _mtx_lock_sleep+0x85 > rt_check(e38b6984,e38b69a0,c57963f0,0,0,...) at rt_check+0x120 > arpresolve(c4e27000,c5e0fbb8,c5f20e00,c57963f0,e38b69ba,...) at > arpresolve+0xb4 > ether_output(c4e27000,c5f20e00,c57963f0,c5e0fbb8,c8a6a3f0,...) at > ether_output+0x7e > ip_output(c5f20e00,0,e38b6a28,0,0,...) at ip_output+0xa59 > tcp_output(c89e2168,8,36ee80,0,0,...) at tcp_output+0x1493 > tcp_do_segment(c89e2168,28,0,6b4835a1,901f,...) at tcp_do_segment+0x1c55 > tcp_input(c60e1700,14,c4ea3c00,1,0,...) at tcp_input+0xd2e > ip_input(c60e1700,0,c08b0028,e38b0028,0,...) at ip_input+0x6b0 > netisr_processqueue(c4d10aa0,0,1,1000000,c4d10aa0,...) at > netisr_processqueue+0xdb > swi_net(0,0,c092df73,46b,0,...) at swi_net+0x12b > ithread_loop(c4d0c270,e38b6d38,0,0,0,...) at ithread_loop+0x1cb > fork_exit(c0643a60,c4d0c270,e38b6d38) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > > This is on a recent -CURRENT, i386, SMP. NIC is fxp. If anyone needs more > data, please let me know - this is a critical problem for me. The same > machine worked ok with 6-STABLE. Quite a few people have reported similar issues, either a trap 12 or a "mtx_lock() of destroyed mutex", all with a stack ending in rt_check. http://lists.freebsd.org/pipermail/freebsd-current/2007-March/070231.html http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014092.html http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074643.html http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076041.html http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076242.html The same panic was also reported for 6.2 via PR 107865 and PR 112490. 112490 included a workaround patch (I haven't tried it; just found it). -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 17:28:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E4716A418; Wed, 12 Sep 2007 17:28:58 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 749B213C4B4; Wed, 12 Sep 2007 17:28:57 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 39392691094; Wed, 12 Sep 2007 18:32:44 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 05AD9691120; Wed, 12 Sep 2007 18:32:44 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_XBL autolearn=no version=3.1.7 Received: from epsilon.local (unknown [62.169.80.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 0EF1A69111E; Wed, 12 Sep 2007 18:32:38 +0100 (WEST) Message-ID: <46E821C2.5090505@fnop.net> Date: Wed, 12 Sep 2007 18:28:34 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Harald Schmalzbauer References: <200708210339.l7L3dUX0038042@repoman.freebsd.org> <200708260054.42892.h.schmalzbauer@omnisec.de> <46D0BEEF.1020601@FreeBSD.org> <200709112348.07052.h.schmalzbauer@omnisec.de> In-Reply-To: <200709112348.07052.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Shteryana Shopova , freebsd-current@freebsd.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-08-20.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 17:28:58 -0000 Harald Schmalzbauer wrote: > I had only tested some newer hardware with core2 CPU (E6750) and coretemp > doesn't report correct values for that CPU (25°C, this is at least 10° > difference) and the boards doesn't neccessarily have a HW monitor chip, so I > haven't reported anything yet. Well, at that time, your CPU was at 25 or 40 degC (the register value was 60). The problem relies on detecting the junction temperature. Temperature = Register Value - Junction Temperature. Junction Temperature = 100 or 85. If you think the correct temperature is 40 degC, you might want to change the if clause for detecting the junction temperature. Could you please show the contents of the cpu_model and cpu_mask variable? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 18:51:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B585416A418 for ; Wed, 12 Sep 2007 18:51:13 +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 644CD13C45A for ; Wed, 12 Sep 2007 18:51:13 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IVXIc-0005A5-2n for freebsd-current@freebsd.org; Wed, 12 Sep 2007 20:50:54 +0200 Received: from 78-1-121-170.adsl.net.t-com.hr ([78.1.121.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Sep 2007 20:50:54 +0200 Received: from ivoras by 78-1-121-170.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Sep 2007 20:50:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 12 Sep 2007 20:50:37 +0200 Lines: 34 Message-ID: References: <20070912172752.GA13960@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65D314A043F9A429399E5C4D" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-121-170.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <20070912172752.GA13960@dan.emsphone.com> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Panic in arpresolve->rt_check? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 18:51:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65D314A043F9A429399E5C4D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan Nelson wrote: > The same panic was also reported for 6.2 via PR 107865 and PR 112490.=20 > 112490 included a workaround patch (I haven't tried it; just found it).= The proposed patch in kern/112490 looks trivial but someone who knows more about net locking should check it out. Unfortunately it lacks context and I don't know the code in question to apply it safely on a production machine :( --------------enig65D314A043F9A429399E5C4D 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.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6DUDldnAQVacBcgRAp+sAKDNpEucPrj+R4YCbF/4LvJAaDG/wgCgg20i s3Opr+85lIz1XPRCbnG2bMs= =b8oV -----END PGP SIGNATURE----- --------------enig65D314A043F9A429399E5C4D-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 19:08:10 2007 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36E816A418; Wed, 12 Sep 2007 19:08:09 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id DAED613C45A; Wed, 12 Sep 2007 19:08:08 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46E83917.3070705@FreeBSD.org> Date: Wed, 12 Sep 2007 21:08:07 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Robert Watson References: <20070912084914.9985.qmail@exxodus.fedaykin.here> <46E7AB54.9060103@FreeBSD.org> <20070912124704.C79170@fledge.watson.org> In-Reply-To: <20070912124704.C79170@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re@FreeBSD.org, FreeBSD-current@FreeBSD.org, Mario Sergio Fujikawa Ferreira Subject: Re: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 19:08:10 -0000 Robert Watson wrote: > > On Wed, 12 Sep 2007, Kris Kennaway wrote: > >> Mario Sergio Fujikawa Ferreira wrote: >>> I had 3 panics today. All seem to be related to ipf code. I have >>> disabled ipf for the time being. >>> >>> I am attaching the kgdb backtraces. I am saving the cores. Let me >>> know if there is anything I can do to help. >>> >>> FreeBSD exxodus.home.home 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep >>> 10 15:01:49 BRT 2007 >>> root@exxodus.home.home:/usr/obj/usr/src/sys/LIOUX i386 >>> >>> -current as of Sep 10 2007. >> >> Yes, known issue. The lack of response by the ipf maintainer so far >> suggests it probably will not be fixed in 7.0. This should be >> documented in the relnotes. > > The quick, and probably correct, fix is to replace all use of sx(9) with > rw(9) in ipf. There might be places where a copying/copyout is being > performed with the lock held, in which case this will trigger new warnings. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > Worth a shot I guess. Kris From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 19:15:22 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3567916A41B; Wed, 12 Sep 2007 19:15: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 BFE5713C458; Wed, 12 Sep 2007 19:15: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 l8CIiabe047349; Wed, 12 Sep 2007 12:44:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46E83392.6050704@samsco.org> Date: Wed, 12 Sep 2007 12:44:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Patrick Hajek References: <20070911210234.GC21433@lbl.gov> In-Reply-To: <20070911210234.GC21433@lbl.gov> 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]); Wed, 12 Sep 2007 12:44: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: current@freebsd.org, thomas@freebsd.org Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 19:15:22 -0000 Patrick Hajek wrote: >>>>> The upgrade was successful with one exception: >>>>> ad0: 95205MB at ata0-master UDMA100 >>>>> acd0: DVDR at ata1-master UDMA33 >>>>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >>>>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >>>>> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >>>>> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 >>> atapicam is disabled in your kernel configuration, so I assume you >>>> are >>>> loading it as a module. Do you still get the errors above (on acd0) >>>> if >>>> you do *not* load the atapi-cam module? >>>> Thomas. >>> Correct. When I first encountered the error, the vaious components >>> were >>> compiled into the kernel. Taking a wild stab, I decided to see if >>> loading it as a module would result the the same issue and yes, it >>> did. > >> so can you confirm whether you still get the acd0 errors when you do NOT >> load atapi-cam at all (nor have it precompiled in the kernel)? >> >> Thomas. > > Commenting out atapicam_load="YES" in loader.conf and not precompiled it in > the kernel, the errors disappear. > > dmesg shows: > > d0: 95205MB at ata0-master UDMA100 > acd0: DVDR at ata1-master UDMA33 > > No sense errors. So, it appears to point to the atapi-cam module. > > Suggestions? Please try the patch I posted to this list 2 days ago. Scott From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 21:44:41 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2797B16A46B; Wed, 12 Sep 2007 21:44:41 +0000 (UTC) (envelope-from SRS0=b6c6888a821bb94eda098e81e36241beaa98dcbf=456=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id E1CD813C4B6; Wed, 12 Sep 2007 21:44:38 +0000 (UTC) (envelope-from SRS0=b6c6888a821bb94eda098e81e36241beaa98dcbf=456=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id REE43536; Wed, 12 Sep 2007 14:44:36 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DA8874500E; Wed, 12 Sep 2007 14:44:35 -0700 (PDT) To: Scott Long In-Reply-To: Your message of "Wed, 12 Sep 2007 12:44:34 MDT." <46E83392.6050704@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189633475_92331P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 12 Sep 2007 14:44:35 -0700 From: "Kevin Oberman" Message-Id: <20070912214435.DA8874500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: Scott Long X-To_Domain: samsco.org X-To: Scott Long X-To_Email: scottl@samsco.org X-To_Alias: scottl Cc: Patrick Hajek , current@freebsd.org, thomas@freebsd.org Subject: Re: Recent changes in atapi-cam? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 21:44:41 -0000 --==_Exmh_1189633475_92331P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 12 Sep 2007 12:44:34 -0600 > From: Scott Long > Sender: owner-freebsd-current@freebsd.org > > Patrick Hajek wrote: > >>>>> The upgrade was successful with one exception: > >>>>> ad0: 95205MB at ata0-master UDMA100 > >>>>> acd0: DVDR at ata1-master UDMA33 > >>>>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > >>>>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > >>>>> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > >>>>> acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 > >>> atapicam is disabled in your kernel configuration, so I assume you > >>>> are > >>>> loading it as a module. Do you still get the errors above (on acd0) > >>>> if > >>>> you do *not* load the atapi-cam module? > >>>> Thomas. > >>> Correct. When I first encountered the error, the vaious components > >>> were > >>> compiled into the kernel. Taking a wild stab, I decided to see if > >>> loading it as a module would result the the same issue and yes, it > >>> did. > > > >> so can you confirm whether you still get the acd0 errors when you do NOT > >> load atapi-cam at all (nor have it precompiled in the kernel)? > >> > >> Thomas. > > > > Commenting out atapicam_load="YES" in loader.conf and not precompiled it in > > the kernel, the errors disappear. > > > > dmesg shows: > > > > d0: 95205MB at ata0-master UDMA100 > > acd0: DVDR at ata1-master UDMA33 > > > > No sense errors. So, it appears to point to the atapi-cam module. > > > > Suggestions? > > > Please try the patch I posted to this list 2 days ago. Are you referring to the CAM_QUIRK_NOSERIAL patch? That's the only one I could find. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1189633475_92331P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG6F3Dkn3rs5h7N1ERAhfAAJ0b5XTQlLHxqE8e66wrlgBWsdLffgCdEGUt d1FdwRQs04KvhaYAKHimJrA= =pcTz -----END PGP SIGNATURE----- --==_Exmh_1189633475_92331P-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 21:58:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F8E816A417 for ; Wed, 12 Sep 2007 21:58:06 +0000 (UTC) (envelope-from drumslayer2@yahoo.com) Received: from web63412.mail.re1.yahoo.com (web63412.mail.re1.yahoo.com [69.147.97.52]) by mx1.freebsd.org (Postfix) with SMTP id AC66C13C494 for ; Wed, 12 Sep 2007 21:58:05 +0000 (UTC) (envelope-from drumslayer2@yahoo.com) Received: (qmail 93064 invoked by uid 60001); 12 Sep 2007 21:30:03 -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=zUrGnIozMhslKxj1WB4ik8LAHaPZXKtgIXSgR37ZDN/5ydf9foFxcoP8Rp3yqkwhuFqNy/kCElP+ORqOu/JkDv5QNpa7uJ1Mc0qvi/+MGY1knAutSiSmGdHzaGrjqEFQy3fD66LUgB0BR4NUkg8+ec/gZeoPG/XfrV33H8LN9yk=; X-YMail-OSG: KHbabPwVM1ktTZcWNUrZ7GeBO1hea.of1qWCHGX9PgIpdVYqyXRfGMjYOUJcZLjceDpadEcLGA-- Received: from [67.112.21.27] by web63412.mail.re1.yahoo.com via HTTP; Wed, 12 Sep 2007 14:30:01 PDT Date: Wed, 12 Sep 2007 14:30:01 -0700 (PDT) From: "N. Harrington" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <493256.92532.qm@web63412.mail.re1.yahoo.com> Subject: Cannot install last two 7.0-snapshots via USB attached CD rom. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 21:58:06 -0000 Hello I am using both a Tyan S2881 and S2882 motherboard with Opteron Processor. I have been trying to install the 7.X snapshots for some time now via A USB attached CD rom, (same as I always have for 5 or 6) but so far it still seems broken. I can install the snapshots just fine via ATA interface to the cd unit, but I cannot do so via the CD unit connected via USB. I can, and always have, however installed 5 and 6 this way. It always fails in the same place. F1 Write failure transfer! (wrote -1 bytes of 1425408 bytes) F2 .... /stand/gunzip : : too many length or distance symbols /stand/cpio: premature end of file Retry: Write Failure On Transfer Wrote -1 bytes of 1425408 bytes /stand/gunzip : invalid code length set Being able to install via USB is very important to me. Might anyone know what could be happening? I can swap the disk with a 6.X disk and it ill install fine. I also cannot install To a USB attached drive using 7, but I can with 6. Thanks! Nicole From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 23:22:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E5E16A418 for ; Wed, 12 Sep 2007 23:22:18 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id B485213C45A for ; Wed, 12 Sep 2007 23:22:17 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.13] (helo=[10.29.62.13]) by fish.ish.com.au with esmtpa (Exim 4.43) id 1IVbU0-0006lF-91 for freebsd-current@freebsd.org; Thu, 13 Sep 2007 09:18:59 +1000 Mime-Version: 1.0 (Apple Message framework v752.2) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> Content-Transfer-Encoding: 7bit From: Aristedes Maniatis Date: Thu, 13 Sep 2007 09:22:10 +1000 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Sep 2007 23:22:18 -0000 I don't want this to sound like a "is it ready yet?" email, but as we are rolling out some new servers in the next months I'd like to get some idea of whether it is time for us to start testing hardware and configurations against current, ready for deployment in the not distant future. In particular I am very interested in the excellent improvements for SMP and mysql performance. I understand that response 'version 7 will be released when it is ready', but looking at recent cvs commit messages I can't quite see the pattern of what new features are still going in and what is now bug fixes for release. I have some questions: * The bug reports at http://www.freebsd.org/cgi/query-pr-summary.cgi don't seem to correlate with activity on current. Is there a separate bug tracker so that users like myself can see what known bugs remain prior to release? Other open source projects I am affiliated with (for example those at Apache) use bug tracking databases in this way. Or is FreeBSD a little more organic with each developer keeping their own todo list. * Is there a set release schedule and known bugs notes for snapshots? I'd like to try a snapshot but I don't know whether to wait a day/ week/month for the next one. Or are they released just when someone thinks the source is in a good overall state? Thank you Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 23:43:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1413C16A417 for ; Wed, 12 Sep 2007 23:43:21 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id CFEED13C467 for ; Wed, 12 Sep 2007 23:43:20 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l8CNCngY084569; Wed, 12 Sep 2007 16:12:49 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l8CNCnEf084568; Wed, 12 Sep 2007 16:12:49 -0700 (PDT) (envelope-from obrien) Date: Wed, 12 Sep 2007 16:12:49 -0700 From: "David O'Brien" To: Brooks Talley Message-ID: <20070912231249.GC75569@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Brooks Talley References: <7248470.49881189559919625.JavaMail.root@zmail.illuminati.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7248470.49881189559919625.JavaMail.root@zmail.illuminati.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current Subject: Re: Compiling with gcc42 / reverting to CC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Wed, 12 Sep 2007 23:43:21 -0000 On Tue, Sep 11, 2007 at 06:18:39PM -0700, Brooks Talley wrote: > I have a 7.0-current box that's been updated to the latest HEAD, and I > need to rebuild the kernel. However, someone has helpfully configured > the box to use GCC42 for make, and that's failing because 1) kern.mk > has a CWARNFLAGS definition that GCC42 hates (-fformat-extensions), and > 2) __FreeBSD_cc_version is not defined. Now sure what you mean by "configured the box to use GCC42". What does '/usr/bin/cc -v' say? If 3.4.*, you can build with 'make -DWITH_GCC3'. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 00:17:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 708E116A46E for ; Thu, 13 Sep 2007 00:17:13 +0000 (UTC) (envelope-from root@arpanet.ru) Received: from mail.arpanet.ru (mail.arpanet.ru [81.176.67.164]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8B113C458 for ; Thu, 13 Sep 2007 00:17:13 +0000 (UTC) (envelope-from root@arpanet.ru) Received: from MONO (ppp85-141-173-155.pppoe.mtu-net.ru [85.141.173.155]) by mail.arpanet.ru (Postfix) with ESMTP id BECAFA014F40 for ; Thu, 13 Sep 2007 04:17:08 +0400 (MSD) Date: Thu, 13 Sep 2007 04:17:09 +0400 From: Alexander Sizov X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1091994189.20070913041709@arpanet.ru> To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: portsnap fetch bug or quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 00:17:13 -0000 Hello! I have a problem, that happens very often when I try to do portsnap fetch. Its looks like: Looking up portsnap3.FreeBSD.org mirrors... none found. Fetching snapshot tag from portsnap3.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Wed Aug 29 23:00:50 MSD 2007 to Thu Sep 13 02:02:56 MSD 2007. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Fetching 1980 patches.....10....20....30....40 ... 1420....1430.... done. The number of fetching patches (1980) != number of fetched patches (143[8-9]). Why it happens? pS. FreeBSD6.2 -- TBR, Alexander V. Sizov mailto:root@arpanet.ru From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 01:15:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7007316A417 for ; Thu, 13 Sep 2007 01:15:26 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7A413C467 for ; Thu, 13 Sep 2007 01:15:26 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IVdIe-0007Vl-N5 for ; Thu, 13 Sep 2007 10:15:21 +0900 Message-ID: <46E88F28.7050108@fusiongol.com> Date: Thu, 13 Sep 2007 10:15:20 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Re: Xorg detaches one of my hard drives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 01:15:26 -0000 I've updated the BIOS on my GA-G33-DS3R to F5, and rebuilt world to the latest CURRENT. Xorg is no longer detaching my hard drive. Instead, now it is acting randomly. Sometimes X won't start up properly, and leaves me with a solid cursor in the top left of the screen, crashing my system. Othertimes, I've had X start up properly, except that I get the kernal message :- interrupt storm detected on "irq 19"; throttling interrupt source ...flow all the way down the screen on the first console. Xorg is configured to use the VESA driver for the G33, as I believe there is no support for this chipset in this version of Xorg. From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 07:02:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E9A16A418 for ; Thu, 13 Sep 2007 07:02:15 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id EEBDE13C428 for ; Thu, 13 Sep 2007 07:02:14 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A57AF7.dip.t-dialin.net [84.165.122.247]) by redbull.bpaserver.net (Postfix) with ESMTP id ED8E42E1DD; Thu, 13 Sep 2007 09:02:04 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AD2845B4926; Thu, 13 Sep 2007 09:01:46 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l8D71kLe024815; Thu, 13 Sep 2007 09:01:46 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 13 Sep 2007 09:01:46 +0200 Message-ID: <20070913090146.ueiy855n2808w4ss@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 13 Sep 2007 09:01:46 +0200 From: Alexander Leidinger To: Aristedes Maniatis References: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> In-Reply-To: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 07:02:15 -0000 Quoting Aristedes Maniatis (from Thu, 13 Sep 2007 =20 09:22:10 +1000): > I don't want this to sound like a "is it ready yet?" email, but as we > are rolling out some new servers in the next months I'd like to get > some idea of whether it is time for us to start testing hardware and > configurations against current, ready for deployment in the not distant > future. In particular I am very interested in the excellent > improvements for SMP and mysql performance. The source of 7-current is frozen. This means all changes have to be =20 approved by our release engineering team. If you test _now_ and report =20 problems you may see, the chance is high that those problems get fixed =20 before 7.0 is released. Some people already use 7-current in =20 production (but this is not recommended by the developers of FreeBSD). > * The bug reports at http://www.freebsd.org/cgi/query-pr-summary.cgi > don't seem to correlate with activity on current. Is there a separate > bug tracker so that users like myself can see what known bugs remain > prior to release? Other open source projects I am affiliated with (for > example those at Apache) use bug tracking databases in this way. Or is > FreeBSD a little more organic with each developer keeping their own > todo list. There's no separate bug tracker. Typically bugs for -current are =20 reported on this mailinglist and people either directly have a look at =20 it, or request that people open up a bug report in our bug tracker. =20 The critical bugs are currently tracked by the release engineering =20 team. There was even a commit to the webpages which contains an =20 initial list of known problems prior to beta1, but this list didn't =20 contain all bugs which where reported to current@. I don't know if the =20 list of known defects the release engineering team has is the same as =20 what is available in CVS. > * Is there a set release schedule and known bugs notes for snapshots? No, there's nothing like this for snapshots. This would be too much =20 work. We only have this for releases. > I'd like to try a snapshot but I don't know whether to wait a > day/week/month for the next one. Or are they released just when someone > thinks the source is in a good overall state? They are released periodically. AFAIK there's no runability check =20 before a snapshot goes out, the only requirement is that it builds =20 correctly. Bye, Alexander. --=20 The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. =09=09-- Justice Louis D. Brandeis http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 08:38:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E87AB16A418 for ; Thu, 13 Sep 2007 08:38:00 +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 A021313C458 for ; Thu, 13 Sep 2007 08:38:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3131D45E9D; Thu, 13 Sep 2007 10:37:59 +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 2ADC245E90; Thu, 13 Sep 2007 10:37:55 +0200 (CEST) Date: Thu, 13 Sep 2007 10:36:35 +0200 From: Pawel Jakub Dawidek To: Kenneth Vestergaard Schmidt Message-ID: <20070913083635.GB1155@garage.freebsd.pl> References: <20070905141759.GJ12013@garage.freebsd.pl> <20070905171741.GA15709@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 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: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 08:38:01 -0000 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2007 at 08:31:09AM +0200, Kenneth Vestergaard Schmidt wrote: > Pawel Jakub Dawidek writes: >=20 > > On Wed, Sep 05, 2007 at 05:25:09PM +0200, Kenneth Vestergaard Schmidt w= rote: > >> Pawel Jakub Dawidek writes: > >> >> I could use some pointers on what to do - is there some way I can d= ebug > >> >> this better, maybe give some better info? > >> > > >> > Try disabling ZIL. This looks like a bug was already reported by Kri= s. > >> > This was already reported to OpenSolaris. > >>=20 > >> We disabled ZIL, but the bug crept up again. I've just now rebooted the > >> machine with DDB-support, so I can get some more info, per Kris's mail. >=20 > That would be Kip's mail. >=20 > >> The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv= )' > >> - it cycles between RUN, CPUx and this one. > > > > Hmm, this means it didn't deadlock... >=20 > Here's some debugging output. PIDs 14870, 14933 and 12458 are just > spinning and being useless. Funnily, all three have rename() in their > backtrace. >=20 > db> ps [...] > 360 0 0 0 SL zfs:(&tq 0xd151877c [zil_clean] > 359 0 0 0 SL zfs:(&tq 0xd1518848 [zil_clean] [...] Are you sure you disabled ZIL? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --yEPQxsgoJgBvi8ip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG6PaTForvXbEpPzQRAsKFAJwLVmn2Ib72EIfzzLJXiTVqoYl7HQCfW1MR Anxx40GGkaNINbELmHvNNOg= =rrC1 -----END PGP SIGNATURE----- --yEPQxsgoJgBvi8ip-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 11:57:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3120316A417 for ; Thu, 13 Sep 2007 11:57:51 +0000 (UTC) (envelope-from piratepockets@adam.com.au) Received: from smtp1.mail.adnap.net.au (smtp1.mail.adnap.net.au [203.6.132.75]) by mx1.freebsd.org (Postfix) with ESMTP id F221D13C459 for ; Thu, 13 Sep 2007 11:57:50 +0000 (UTC) (envelope-from piratepockets@adam.com.au) Received: from 219-90-201-134.static.adam.com.au ([219.90.201.134] helo=[172.20.4.1]) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IVn3X-0006uy-6h for freebsd-current@freebsd.org; Thu, 13 Sep 2007 21:10:23 +0930 Message-ID: <46E92139.1030508@adam.com.au> Date: Thu, 13 Sep 2007 21:08:33 +0930 From: Pete User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 6.x and HP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 11:57:51 -0000 Hey there, I've been having a rather unusual, but very annoying issue with HP DL140 G3 Servers and FreeBSD. I thought I might give the mailing list a try to see what I can find and whether anyone else has had similar issues. When trying to install FreeBSD 6.x AMD64, as these boxes look to have the Woodcrest core Xeon CPUs (5100-series), which support EMT64T, I have encountered the following issues. When using FreeBSD 6.1, I can't even get as far as sysinstall. The server tends to hang when initializing the drives just before it enters into the usual setup utility. When using FreeBSD 6.2, I can get into sysinstall, however, I get as far as configuring the slices and starting the install. After this has been done it begins extracting the data into the root directory, the machine then hangs. I don't believe it to be a hardware fault within a single machine as I have tried with a total of 3 of these machines with the same configuration. My original thoughts were with the LSI RAID controller I have in the machine. However, If I use the i386 FreeBSD 6.2 CD to install, the installation completes fine, the server reboots and comes up normally. No issues with drives, etc. I've also run a BIOS update to the latest version, which is "1.13 (2007.05.18) A (23 May 07)" for anyone with the machines, with no avail. I have been unable to find any information on-line relating to this specific issue, the only similar issues I have encountered are kernel panics caused by an on-board SATA controller, which we aren't using here. The suggested solution to this issue was to update the BIOS as well, which as above, has already been tried. If anyone could shed some light on the situation or has any ideas, it would be greatly appreciated. -- Peter From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 12:58:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB2CC16A417 for ; Thu, 13 Sep 2007 12:58:51 +0000 (UTC) (envelope-from piratepockets@adam.com.au) Received: from smtp1.mail.adnap.net.au (smtp1.mail.adnap.net.au [203.6.132.75]) by mx1.freebsd.org (Postfix) with ESMTP id A718913C45D for ; Thu, 13 Sep 2007 12:58:51 +0000 (UTC) (envelope-from piratepockets@adam.com.au) Received: from 219-90-201-134.static.adam.com.au ([219.90.201.134] helo=[172.20.4.1]) by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IVoHS-000Cho-GR for freebsd-current@freebsd.org; Thu, 13 Sep 2007 22:28:50 +0930 Message-ID: <46E9339C.7090806@adam.com.au> Date: Thu, 13 Sep 2007 22:27:00 +0930 From: Pete User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46E92139.1030508@adam.com.au> <46E92E42.7080208@steelerubber.com> In-Reply-To: <46E92E42.7080208@steelerubber.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 6.x and HP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 12:58:52 -0000 Thanks for the quick response Walter. Previously, I have tried with CentOS 5.0 as a 64-bit install, and I have managed to get that installed fine. I have a few machines in production running with that configuration. As for RAM, in this case, it was with only 2 gig in a 2x1024MB DIMM kit. I'm not sure as to the status of EIST however, I beleive it is enabled. I will check this out tomorrow when I have a chance as the machines themselves aren't at my home. I'll also give 7.0 a whirl and see what the outcome of that is. Cheers again for the response. Walter Vaughan wrote: > Pete wrote: >> Hey there, >> >> I've been having a rather unusual, but very annoying issue with HP >> DL140 G3 Servers and FreeBSD. I thought I might give the mailing list >> a try to see what I can find and whether anyone else has had similar >> issues. When trying to install FreeBSD 6.x AMD64, as these boxes look >> to have the Woodcrest core Xeon CPUs (5100-series), which support >> EMT64T, I have encountered the following issues. >> >> When using FreeBSD 6.1, I can't even get as far as sysinstall. The >> server tends to hang when initializing the drives just before it >> enters into the usual setup utility. When using FreeBSD 6.2, I can >> get into sysinstall, however, I get as far as configuring the slices >> and starting the install. After this has been done it begins >> extracting the data into the root directory, the machine then hangs. >> I don't believe it to be a hardware fault within a single machine as >> I have tried with a total of 3 of these machines with the same >> configuration. >> >> My original thoughts were with the LSI RAID controller I have in the >> machine. However, If I use the i386 FreeBSD 6.2 CD to install, the >> installation completes fine, the server reboots and comes up >> normally. No issues with drives, etc. > > So you are trying to install FreeBSD-AMD64? Hum. FreeBSD was first OS > to support the AMD64 AFAIK. This has been working for a long time. > > Does your bios have a setting to enable/disable 64 bit mode? > > Did you check this setting in your bios? > http://lists.freebsd.org/mailman/htdig/freebsd-amd64/2006-July/008613.html > > > You don't want 4 gigs of memory it that is what you have. Pull out a > stick or add a stick. Download/burn/Pop in a Ubuntu AMD64 CD. See if > that comes up fine. If that works, try a snapshot release of > "current", but I don't think there is magic in 7.0 that 6.2 does not > possess in this case. > > Its going to be something simple. > From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 13:01:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76C6616A417 for ; Thu, 13 Sep 2007 13:01:57 +0000 (UTC) (envelope-from wvaughan@steelerubber.com) Received: from toaster.steelerubber.com (toaster.steelerubber.com [166.82.96.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1541913C461 for ; Thu, 13 Sep 2007 13:01:54 +0000 (UTC) (envelope-from wvaughan@steelerubber.com) Received: (qmail 41737 invoked by uid 89); 13 Sep 2007 12:35:12 -0000 Received: from unknown (HELO ?166.82.96.28?) (166.82.96.28) by toaster.steelerubber.com with SMTP; 13 Sep 2007 12:35:12 -0000 Message-ID: <46E92E42.7080208@steelerubber.com> Date: Thu, 13 Sep 2007 08:34:10 -0400 From: Walter Vaughan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete , freebsd-current@freebsd.org References: <46E92139.1030508@adam.com.au> In-Reply-To: <46E92139.1030508@adam.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD 6.x and HP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 13:01:57 -0000 Pete wrote: > Hey there, > > I've been having a rather unusual, but very annoying issue with HP DL140 > G3 Servers and FreeBSD. I thought I might give the mailing list a try to > see what I can find and whether anyone else has had similar issues. When > trying to install FreeBSD 6.x AMD64, as these boxes look to have the > Woodcrest core Xeon CPUs (5100-series), which support EMT64T, I have > encountered the following issues. > > When using FreeBSD 6.1, I can't even get as far as sysinstall. The > server tends to hang when initializing the drives just before it enters > into the usual setup utility. When using FreeBSD 6.2, I can get into > sysinstall, however, I get as far as configuring the slices and starting > the install. After this has been done it begins extracting the data into > the root directory, the machine then hangs. I don't believe it to be a > hardware fault within a single machine as I have tried with a total of 3 > of these machines with the same configuration. > > My original thoughts were with the LSI RAID controller I have in the > machine. However, If I use the i386 FreeBSD 6.2 CD to install, the > installation completes fine, the server reboots and comes up normally. > No issues with drives, etc. So you are trying to install FreeBSD-AMD64? Hum. FreeBSD was first OS to support the AMD64 AFAIK. This has been working for a long time. Does your bios have a setting to enable/disable 64 bit mode? Did you check this setting in your bios? http://lists.freebsd.org/mailman/htdig/freebsd-amd64/2006-July/008613.html You don't want 4 gigs of memory it that is what you have. Pull out a stick or add a stick. Download/burn/Pop in a Ubuntu AMD64 CD. See if that comes up fine. If that works, try a snapshot release of "current", but I don't think there is magic in 7.0 that 6.2 does not possess in this case. Its going to be something simple. From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 14:24:19 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24BE16A419 for ; Thu, 13 Sep 2007 14:24:19 +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 8346A13C458 for ; Thu, 13 Sep 2007 14:24:18 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 56198 invoked from network); 13 Sep 2007 13:57:36 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 13 Sep 2007 13:57:36 -0000 Message-ID: <46E941D0.5020204@FreeBSD.org> Date: Thu, 13 Sep 2007 15:57:36 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.6 (X11/20070827) MIME-Version: 1.0 To: Alexander Sizov References: <1091994189.20070913041709@arpanet.ru> In-Reply-To: <1091994189.20070913041709@arpanet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: portsnap fetch bug or quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 14:24:19 -0000 Alexander Sizov ha scritto: > Looking up portsnap3.FreeBSD.org mirrors... none found. > Fetching snapshot tag from portsnap3.FreeBSD.org... done. > Fetching 1980 patches.....10....20....30....40 ... 1420....1430.... done. > > The number of fetching patches (1980) != number of fetched patches > (143[8-9]). Why it happens? Does it happen only on portsnap3, right? -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 15:33:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A214116A417 for ; Thu, 13 Sep 2007 15:33:57 +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 275ED13C461 for ; Thu, 13 Sep 2007 15:33:56 +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:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=DpZolhRzhr2hfRMbkWPyj03LAJxqOU9HyH1mbsyJKb7fRxPGk5/maZgXp9Bqs4V+fJ45dc9ixZXg0hfg8p2NOiCLsz3qcVL8Ol7qADo8+u8by9WgKZytg7lHg+dVTvET+eWFBk5pwhTS98UhOnCvmVBWjFmxbPrwVqR/S6KfU+8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IVqhP-000KCG-Ah; Thu, 13 Sep 2007 19:33:47 +0400 Date: Thu, 13 Sep 2007 19:33:43 +0400 From: Eygene Ryabinkin To: Pete Message-ID: <20070913153342.GJ945@void.codelabs.ru> References: <46E92139.1030508@adam.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46E92139.1030508@adam.com.au> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.x and HP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 15:33:57 -0000 Pete, good day. Thu, Sep 13, 2007 at 09:08:33PM +0930, Pete wrote: > I've been having a rather unusual, but very annoying issue with HP DL140 G3 > Servers and FreeBSD. I thought I might give the mailing list a try to see what > I can find and whether anyone else has had similar issues. When trying to > install FreeBSD 6.x AMD64, as these boxes look to have the Woodcrest core Xeon > CPUs (5100-series), which support EMT64T, I have encountered the following > issues. I didn't tried FreeBSD on these servers, but for Linux 64-bit systems demand that "8042 Emulation Support" must be disabled (BIOS, menu "Advanced"). Try this, may be it will help, especially if you have no problems with FreeBSD/i386 and 8042 emulation is currently enabled on your machine. Drop me a letter if things will fail for you, I might be able to check FreeBSD/amd64 on the DL140 G3 I have at hand. -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 15:47:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF08316A418 for ; Thu, 13 Sep 2007 15:47:29 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBFB13C45D for ; Thu, 13 Sep 2007 15:47:29 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from dhcp-2-119.packetdesign.com (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l8DFlRTm015246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 08:47:28 -0700 Message-ID: <46E95B7D.8010604@freebsd.org> Date: Thu, 13 Sep 2007 08:47:09 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexander Leidinger References: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> <20070913090146.ueiy855n2808w4ss@webmail.leidinger.net> In-Reply-To: <20070913090146.ueiy855n2808w4ss@webmail.leidinger.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig33F4C1ACD04097466B2EAA5A" Cc: freebsd-current@freebsd.org, Aristedes Maniatis Subject: Re: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 15:47:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33F4C1ACD04097466B2EAA5A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If memory serves me right, Alexander Leidinger wrote: > Quoting Aristedes Maniatis (from Thu, 13 Sep 2007 =20 > 09:22:10 +1000): >=20 >> I don't want this to sound like a "is it ready yet?" email, but as we >> are rolling out some new servers in the next months I'd like to get >> some idea of whether it is time for us to start testing hardware and >> configurations against current, ready for deployment in the not distan= t >> future. In particular I am very interested in the excellent >> improvements for SMP and mysql performance. >=20 > The source of 7-current is frozen. This means all changes have to be =20 > approved by our release engineering team. If you test _now_ and report = =20 > problems you may see, the chance is high that those problems get fixed = =20 > before 7.0 is released. Some people already use 7-current in =20 > production (but this is not recommended by the developers of FreeBSD). (Speaking for myself, not for re@ as a whole.) I think that if the OP is interested in *testing* against hardware he might deploy later this year, then yes, starting to play with CURRENT is a good idea. The basic feature set is complete for the most part, and ABI/API changes are pretty much done (with a couple of outstanding items). Do watch out for (and report) bugs, although realize that there's ongoing bugfixing work still in progress. >> * The bug reports at http://www.freebsd.org/cgi/query-pr-summary.cgi >> don't seem to correlate with activity on current. Is there a separate >> bug tracker so that users like myself can see what known bugs remain >> prior to release? Other open source projects I am affiliated with (for= >> example those at Apache) use bug tracking databases in this way. Or is= >> FreeBSD a little more organic with each developer keeping their own >> todo list. >=20 > There's no separate bug tracker. Typically bugs for -current are =20 > reported on this mailinglist and people either directly have a look at = =20 > it, or request that people open up a bug report in our bug tracker. =20 > The critical bugs are currently tracked by the release engineering =20 > team. There was even a commit to the webpages which contains an =20 > initial list of known problems prior to beta1, but this list didn't =20 > contain all bugs which where reported to current@. I don't know if the = =20 > list of known defects the release engineering team has is the same as = > what is available in CVS. The recent commit to the Web pages was a result of an email conversation amongst re@ where we tried to list the biggest outstanding items. I am not a big fan of listing every little bug on status pages because long experience has shown that these tend to get out of date. I usually keep an eye on messages to the freebsd-current@ (or freebsd-stable@, as appropriate) list to see what issues people run into. At this point, the two classes of fixes that are at the forefront of my brain are: TCP and locking. Both of these have ongoing work that's being tested and evaluated prior to being committed. >> * Is there a set release schedule and known bugs notes for snapshots? >=20 > No, there's nothing like this for snapshots. This would be too much =20 > work. We only have this for releases. Well, we try to do snapshots about once a month, at the start of the month. The September snapshot builds for CURRENT and 6-STABLE are being built now. We usually don't do much, if anything, in terms of listing known bugs for snapshots. RELENG_7 branching is dependent on a few ABI-changing patches and maybe some TCP work...after that we should be able to do the first of the 7.0-BETA builds. >> I'd like to try a snapshot but I don't know whether to wait a >> day/week/month for the next one. Or are they released just when someon= e >> thinks the source is in a good overall state? >=20 > They are released periodically. AFAIK there's no runability check =20 > before a snapshot goes out, the only requirement is that it builds =20 > correctly. Well, we do a *little* more than that...our standard procedure is to do at least a smoke test to make sure that a snapshot at least boots and installs, although beyond that there's not a lot of functional testing. BETA builds (when they start) will get a little more attention, as will the RC builds leading up to the actual 7.0 release. Bruce. --------------enig33F4C1ACD04097466B2EAA5A 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 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6Vt92MoxcVugUsMRAuaCAJ9iNqIac2hJD+iV9c/h7vpWlm7qHgCeNJqU JwurURBu3EplAVl8XBhLbqU= =+jeY -----END PGP SIGNATURE----- --------------enig33F4C1ACD04097466B2EAA5A-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 19:50:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC6516A417 for ; Thu, 13 Sep 2007 19:50:31 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-04.prod.mesa1.secureserver.net [64.202.165.12]) by mx1.freebsd.org (Postfix) with SMTP id ACCAB13C45E for ; Thu, 13 Sep 2007 19:50:31 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: (qmail 1818 invoked from network); 13 Sep 2007 19:23:50 -0000 Received: from unknown (208.206.151.55) by smtpout08-04.prod.mesa1.secureserver.net (64.202.165.12) with ESMTP; 13 Sep 2007 19:23:50 -0000 Message-ID: <46E98E44.2070808@computer.org> Date: Thu, 13 Sep 2007 14:23:48 -0500 From: Eric Schuele User-Agent: Thunderbird 2.0.0.6 (X11/20070912) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.ravenlock.us/files/pub_schuele.pgp Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig21E24AC0D6B41443C71CDFDC" Subject: Perl_mallloc() segfault (v5.8.8).... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 19:50:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21E24AC0D6B41443C71CDFDC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I seem to have a perl problem. Not much of a perl person so not sure if the problem is me or not. I'm not even sure I should be posting to freebsd-current@, but since it worked in 6.2... I'm assuming its perl+7.0= =2E Running current i386, and using perl 5.8.8, I get the following back trace on an app that attempts to use perl for an add-on script. #0 0x2972726c in Perl_malloc () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #1 0x297d75dc in PerlIO_allocate () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #2 0x297dc257 in PerlIO_stdstreams () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #3 0x297dc2c2 in Perl_PerlIO_stderr () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #4 0x297280b0 in Perl_malloc () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #5 0x297d75dc in PerlIO_allocate () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #6 0x297dc257 in PerlIO_stdstreams () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #7 0x297dc2c2 in Perl_PerlIO_stderr () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so #8 0x297280b0 in Perl_malloc () Note that this app was working, as well as its add-on script a few days back when I was running 6.2-STABLE. I backed-up everything, formatted my disk, installed 7.0 (snapshot), cvsup'd to most recent (sunday evening)... reinstalled the app in question from package, then from ports. It however always results in the above bt. If I remove the script from the add-ons (its the only script I have) the app runs fine. Wondering if a bug report is warranted? Should it be filed under xchat, perl, or what? Any thoughts? Thanks. --=20 Regards, Eric --------------enig21E24AC0D6B41443C71CDFDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG6Y5EngSDRM3IXUoRAl1vAJ4u6MaTQ5umbFa1G1WpnVmOQeWgJgCdGN4b fKB49NV3dTbWcEYanEBq9nU= =UuwK -----END PGP SIGNATURE----- --------------enig21E24AC0D6B41443C71CDFDC-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 20:09:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F8916A417 for ; Thu, 13 Sep 2007 20:09:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 4633613C442 for ; Thu, 13 Sep 2007 20:09:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from [192.168.1.126] (unknown [64.119.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mbutler-d620.vericept.com", Issuer "Protected Networks Certificate Authority" (verified OK)) by sarah.protected-networks.net (Postfix) with ESMTP id 5D2156185 for ; Thu, 13 Sep 2007 15:49:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1189712976; bh=c4pwUoN0lRZ8VF 0tGdE4Y6wkQtb08wifEiwxey1Dk+A=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=COwrQRraYw2/HcsK8Jrw/OHzmjl+bZryh5od7 F4jmS9yv7zqBDxf3D64hsmntAlTYYOMTO7uu82wQgE35/lXz3RhyxuEHo3Xck15i5ob ThqLRxoPZ9il3x77aHjcooUw DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=NyfozcKvWuCyLGIP50A0kvgnIO3+0Wi8FOBH14oUTFn7vw5tBIvEHelwPkC9AGVUr RxSs3tUnqTUN8O7hTtqXavwmD9UpyFtS9V+SIcFpw+EuPXxV1I8t2ndgdhsGffK Message-ID: <46E993C2.7020700@protected-networks.net> Date: Thu, 13 Sep 2007 15:47:14 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: apache start-up issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 20:09:02 -0000 This is weird .. any ideas? imb@mail:/home/imb> sudo /usr/local/etc/rc.d/apache.sh restart apache not running? (check /var/run/httpd.pid). Starting apache. Syntax error on line 205 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local/libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" .. yet .. imb@mail:/home/imb> nm /usr/local/sbin/httpd | grep ap_null_cleanup 0804b290 T ap_null_cleanup Michael From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 21:02:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF4116A46B for ; Thu, 13 Sep 2007 21:02:16 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id 9180E13C442 for ; Thu, 13 Sep 2007 21:02:16 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id 2C7EB16C86E0 for ; Thu, 13 Sep 2007 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.002, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMAVGj3VzU1l for ; Thu, 13 Sep 2007 14:02:04 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id A0E4616C86DE for ; Thu, 13 Sep 2007 14:02:04 -0700 (PDT) Date: Thu, 13 Sep 2007 14:02:04 -0700 (PDT) From: Brooks Talley To: freebsd-current Message-ID: <22187550.52511189717324600.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.168.65.79] Subject: Building a 32 bit chroot on 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, 13 Sep 2007 21:02:16 -0000 Hi, everyone. I'm trying to build a 32 bit chroot on a 7.0-CURRENT amd64 installation. The sources are up to date. "make TARGET_ARCH=i386 buildworld" fails partway through with the message: ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='/usr/bin/cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/bin/cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c {standard input}: Assembler messages: {standard input}:27: Error: suffix or operands invalid for `mov' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. ...And ideas? Thanks -Brooks From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 21:07:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D45D16A419 for ; Thu, 13 Sep 2007 21:07:28 +0000 (UTC) (envelope-from lists@groll.co.za) Received: from mail.groll.co.za (mail.groll.co.za [67.18.176.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0D213C461 for ; Thu, 13 Sep 2007 21:07:28 +0000 (UTC) (envelope-from lists@groll.co.za) Received: by mail.groll.co.za (Postfix, from userid 1004) id CB60E8D591; Thu, 13 Sep 2007 22:35:20 +0200 (SAST) Date: Thu, 13 Sep 2007 22:35:20 +0200 From: Jonathan Groll To: freebsd-current@freebsd.org Message-ID: <20070913203518.GP12985@groll.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (Linux mail 2.6.21.1-linode32 i686) Subject: zfs kernel module on sparc64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 21:07:28 -0000 Is there some obvious trick that I'm missing for building the (-current) zfs module on sparc64? Building a GENERIC kernel with `make buildkernel` does not build zfs.ko on sparc64. Is there something in the kernel config that needs to be set that I am perhaps foolishly overlooking? I've also tried building the module directly in /usr/src/sys/modules/zfs/, but trying to kldload the module just resulted in link_elf: symbol undefined appearing on the root console. What have I missed? Many thanks, Jonathan. From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 21:53:52 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5315616A417 for ; Thu, 13 Sep 2007 21:53:52 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by mx1.freebsd.org (Postfix) with ESMTP id 08F9A13C45A for ; Thu, 13 Sep 2007 21:53:51 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so177984ele for ; Thu, 13 Sep 2007 14:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=vNWuU3MOtixs/FUeROYZh+/livgm6Vhxu5LS2Xwy/z4=; b=fz40gw8WHh420865jGrJbsvf1DrKOlmbjmlHYgAyjWzImpa4Q5ck/EARn4kyg52K12eL3dkE2Jk0xuYYkS4nI36SEvelJb7Vn9k/HaLJIAP63NqbIxZgCzHmeUwqS+3iLK6JoPi7bQC/NZiJbupqqlA2wIV/YGdhAhRezprDmhY= 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=aX0FtK83NGz7zikkpf0XmN/7SUN3jLc7aMYE+ua3UaX9bDsfL9/rIq0y2LJ9AUY0Dmpl41aTiOEuI3B7mXF0DgW1xpykW8QOKutMA6GGbn21JPmQHWRxocUHWow4uwOi5oyPnJPZ2ZtSsl+7g9eW38Ch8xnIM62IejPUftP6IiA= Received: by 10.78.159.7 with SMTP id h7mr656113hue.1189718732461; Thu, 13 Sep 2007 14:25:32 -0700 (PDT) Received: by 10.78.187.16 with HTTP; Thu, 13 Sep 2007 14:25:32 -0700 (PDT) Message-ID: <70e8236f0709131425h2f651c32j5e23d7901ce6e1f7@mail.gmail.com> Date: Thu, 13 Sep 2007 22:25:32 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <20070910195833.GE1103@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070906184853.GB90021@roadrunner.spoerlein.net> <20070910195833.GE1103@garage.freebsd.pl> Cc: current@freebsd.org Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 21:53:52 -0000 On 9/10/07, Pawel Jakub Dawidek wrote: > On Thu, Sep 06, 2007 at 08:48:53PM +0200, Ulrich Spoerlein wrote: > > Hi, it's me again with another stupid question, > > > > ever since I switched my /usr and /home to ZFS, the system has become > > _very_ unresponsive under load. This is not because of CPU load, but I/O > > load. > > Can you try recent HEAD? I committed a change that allows ZFS cache > (ARC) to use more memory. This should be safe after dfr@'s vnode leak > fix and should also help performance. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > This happened 1 day after compiling new sources: panic: kmem_malloc(90112): kmem_map too small: 329805824 total allocated when writing through NFS. On FreeBSD xeon.bsdtech.org 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Tue Sep 11 00:08:39 WEST 2007 root@xeon.bsdtech.org:/usr/obj/usr/src/sys/GENERIC i386 Machine has 1GB of ram and: vfs.zfs.arc_min: 16777216 vfs.zfs.arc_max: 251658240 vfs.zfs.mdcomp_disable: 0 vfs.zfs.prefetch_disable: 1 vfs.zfs.zio.taskq_threads: 0 vfs.zfs.recover: 0 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.debug: 0 I hadn't had any panics with sources from August 16 but before your recent changes vfs.zfs.arc_max was 167772160 kern.maxvnodes is not set to 50000 as recomended ( on purpose ) and is currently at 52242 set by the system. Is 50000 still recomended after your changes? -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 21:57:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8F316A41A for ; Thu, 13 Sep 2007 21:57:31 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53912.mail.re2.yahoo.com (web53912.mail.re2.yahoo.com [206.190.38.161]) by mx1.freebsd.org (Postfix) with SMTP id 31C6A13C468 for ; Thu, 13 Sep 2007 21:57:31 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 7676 invoked by uid 60001); 13 Sep 2007 21:30:50 -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=MXuWytozNM/zw8DVc4Ms+R9nvTCXBCYgW7Q77NkcdV1y4+DYA2HTy/kFP6tI78S8qssKa6nQL/ErEEYDLwNgGuzqk6mhSd7RS9Hlw9RBUTYcQGFA7ZN+pebQ3LKaxtjnXvg97shtJiwUsIQYiXJzdF1exJW9UFT6mLqY1LJcqWc=; X-YMail-OSG: RBMqBcwVM1k0vNLd2yyiwmri.X.3ZqsxdJHwnAMhotLgKT.t.DLiGhRmoUN5YVEK9UbviOBUSXkemQzj6sYLsZxxaAOAHZWr9mtZLhVX8cMJXcwSp4kir_TEi3.Jbg-- Received: from [209.166.103.197] by web53912.mail.re2.yahoo.com via HTTP; Thu, 13 Sep 2007 14:30:50 PDT Date: Thu, 13 Sep 2007 14:30:50 -0700 (PDT) From: Dave Frantz To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <813483.4697.qm@web53912.mail.re2.yahoo.com> Subject: Kernel Locks During Device Probe on 7.0 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, 13 Sep 2007 21:57:31 -0000 I've been tracking 7.0 for several weeks now using cvsup. Unfortunately, in this time, I haven't been able to build a working kernel, even using GENERIC. When I try to use a 7.0 current kernel, the system gets about 6/8ths through the device probe, then simply stops. It does not visibly panic; it just stops the device probe and does nothing. (It acts like the kernel goes into a loop someplace and never gets out.) This occurs whether ACPI is enabled or not. Unfortunately, the hang occurs before the system can enter even single user mode, making a post of the full device probe impossible. I've tried to reproduce the five lines proceeding the hang to give an idea of where it's stopping. Using the stock GENERIC kernel configuration with verbose logging and ACPI enabled, it stops boot right after printing: lo0: bpf attached rr232x: nfirewire 0: 1 nodes, maxhop <=0, cable IRM = 0 (me) firewire 0: bus manager0 (me) o controller detected. Compiling GENERIC without Firewire (but with ACPI enabled) gives: rr232x: no controller detected acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery0: battery initialization done, tried 1 times When ACPI is disabled, the GENERIC kernel hangs right after printing: lo0: bpf attached rr232x: nfirewire 0: 1 nodes, maxhop <=0, cable IRM = 0 (me) firewire 0: bus manager0 (me) o controller detected. When I try to run GENERIC without ACPI and without Firewire compiled in, I get: lo0: bpf attached rr232x: no controller detected followed by the kernel hanging. FreeBSD 6.2 runs very well on this machine, and the output of pciconf -vl is: agp0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x1a308086 rev=0x11 hdr=0x00 vendor = 'Intel Corporation' device = '82845/E/MP/MZ Brookdale CPU to I/O Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x1a318086 rev=0x11 hdr=0x01 vendor = 'Intel Corporation' device = '82845/E/MP/MZ Brookdale CPU to AGP Bridge' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0x00000000 chip=0x24828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) USB Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x00000000 chip=0x24848086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) USB Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x00000000 chip=0x24878086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) USB Controller' class = serial bus subclass = USB pcib2@pci0:30:0: class=0x060400 card=0x00000000 chip=0x24488086 rev=0x42 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x248c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM LPC Interface or ISA bridge: see Notes' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x00000000 chip=0x248a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM (ICH3-M) UltraATA/100 EIDE Controller' class = mass storage subclass = ATA pcm0@pci0:31:5: class=0x040100 card=0x88801558 chip=0x24858086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 Audio Controller' class = multimedia subclass = audio none0@pci0:31:6: class=0x070300 card=0x18001558 chip=0x24868086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 Modem Controller' class = simple comms subclass = generic modem drm0@pci1:0:0: class=0x030000 card=0x88801558 chip=0x4c661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Mobility Radeon 9000' class = display subclass = VGA rl0@pci2:0:0: class=0x020000 card=0x88801558 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet fwohci0@pci2:2:0: class=0x0c0010 card=0x88801558 chip=0x8026104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB21 1394a-2000 OHCI PHY/link-layer Controller' class = serial bus subclass = FireWire bktr0@pci2:4:0: class=0x040000 card=0x00041461 chip=0x036e109e rev=0x11 hdr=0x00 vendor = 'Conexant (Was: Brooktree Corp)' device = 'Bt878/Fusion 878A Mediastream Controller' class = multimedia subclass = video none1@pci2:4:1: class=0x048000 card=0x00041461 chip=0x0878109e rev=0x11 hdr=0x00 vendor = 'Conexant (Was: Brooktree Corp)' device = 'Bt878/Fusion878A Video Capture (Audio Section)' class = multimedia uhci3@pci2:5:0: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x50 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB uhci4@pci2:5:1: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x50 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB ehci0@pci2:5:2: class=0x0c0320 card=0x12340925 chip=0x31041106 rev=0x51 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6202 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB cbb0@pci2:9:0: class=0x060700 card=0x88801558 chip=0xac55104c rev=0x01 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI1520 PC Card CardBus Controller' class = bridge subclass = PCI-CardBus cbb1@pci2:9:1: class=0x060700 card=0x88801558 chip=0xac55104c rev=0x01 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI1520 PC Card CardBus Controller' class = bridge subclass = PCI-CardBus and my make options are -O -pipe. Posted below is the device probe of my FreeBSD 6.2 system. 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 6.2-STABLE #3: Tue Jun 26 16:28:09 CDT 2007 root@Maxwell.local.bsd:/usr/obj/usr/src/sys/SAGER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3066.79-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Features2=0x400 Logical CPUs per core: 2 real memory = 1073676288 (1023 MB) avail memory = 1041166336 (992 MB) ACPI APIC Table: 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 kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) 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 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 pcib0: port 0xcf8-0xcff iomem 0xfff80000-0xffffffff on acpi0 pci0: on pcib0 agp0: mem 0xa0000000-0xa3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: port 0xc000-0xc0ff mem 0x90000000-0x97ffffff,0xe0000000-0xe000ffff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xa0000000 64MB info: [drm] Initialized radeon 1.25.0 20060524 uhci0: port 0xe000-0xe01f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe120-0xe13f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe240-0xe25f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0xa400-0xa4ff mem 0xd0008000-0xd00080ff irq 18 at device 0.0 on pci2 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:90:f5:20:01:eb fwohci0: mem 0xd0000800-0xd0000fff,0xd0004000-0xd0007fff irq 17 at device 2.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:f5:01:00:20:01:eb fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:f5:20:01:eb fwe0: Ethernet address: 02:90:f5:20:01:eb fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc1, gen=1, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) bktr0: mem 0x80000000-0x80000fff irq 17 at device 4.0 on pci2 bktr0: [GIANT-LOCKED] bktr0: AVer Media TV/FM, Philips NTSC tuner. pci2: at device 4.1 (no driver attached) uhci3: port 0xa000-0xa01f irq 16 at device 5.0 on pci2 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhci4: port 0xa120-0xa13f irq 19 at device 5.1 on pci2 uhci4: [GIANT-LOCKED] usb4: on uhci4 usb4: USB revision 1.0 uhub4: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0000000-0xd00000ff irq 18 at device 5.2 on pci2 ehci0: [GIANT-LOCKED] usb5: EHCI version 0.95 usb5: companion controllers, 2 ports each: usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub5: 4 ports with 4 removable, self powered cbb0: at device 9.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 9.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1100-0x110f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xe400-0xe4ff,0xe600-0xe63f irq 17 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) 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 Generic PS/2 mouse, device ID 0 speaker0: port 0x61 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 1/0/0 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PJL,PCL,IBMPPR,EPSONFX,PCLXL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xe3000-0xe3fff,0xe4000-0xe5fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 firewire0: New S400 device ID:0030e0f4e020d4f8 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 SMP: AP CPU #1 Launched! da0 at sbp0 bus 0 target 0 lun 0 da0: Fixed Simplified Direct Access SCSI-4 device da0: 50.000MB/s transfers da0: 58644MB (120103200 512 byte sectors: 255H 63S/T 7476C) cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s2a Loading configuration files. If there is any further system configuration data you need, just let me know. FreeBSD is my main OS, and I'd love to be able to start using FreeBSD 7 on it. Thanks in advance. ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 21:59:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B029816A417 for ; Thu, 13 Sep 2007 21:59:56 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFB313C45A for ; Thu, 13 Sep 2007 21:59:56 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so463425rvb for ; Thu, 13 Sep 2007 14:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=shboRQAEO2Yi/uIo7nNjSdkfxpZqSE+vKR9BQD456us=; b=KXEZIIAYgCDJ/tad7FhQNLkJGs7LrjH0YgfRZztAPTZLIQ5X9r0a2AM0vPvN3HiOn9fr/0SjM8LXmlMMEOpF3GafkFt/Ziazm4s+OJUmxvNJZIxPP4plKJJQtpntbtmKpd+EKkav6JEJkx9DjhAOg1ifBHRKjzLde5gA5eKWPD0= 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=BMcrbEsHhCbZc4KJC8Ck7ldWCtsiFCENkNNbamJbynNcF2VM7V9u7pq2qXoREkoniRqwpUxZldursoTrkfMYw+QNvQHn+S6sCibktnLxbgOLH4U07yLWuY2QNhEID17LUfh3BiAjybr5FQxtngl+TJLdXw4E/ovFjcykv4dNDzM= Received: by 10.114.192.1 with SMTP id p1mr903844waf.1189720795835; Thu, 13 Sep 2007 14:59:55 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Thu, 13 Sep 2007 14:59:55 -0700 (PDT) Message-ID: Date: Thu, 13 Sep 2007 14:59:55 -0700 From: "Kip Macy" To: "Dave Frantz" In-Reply-To: <813483.4697.qm@web53912.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <813483.4697.qm@web53912.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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, 13 Sep 2007 21:59:56 -0000 Turn on VERBOSE_SYSINIT and ddb (although clock interrupts might not be running at that point). -Kip On 9/13/07, Dave Frantz wrote: > I've been tracking 7.0 for several weeks now using > cvsup. Unfortunately, in this time, I haven't been > able to build a working kernel, even using GENERIC. > > When I try to use a 7.0 current kernel, the system > gets about 6/8ths through the device probe, then > simply stops. It does not visibly panic; it just stops > the device probe and does nothing. (It acts like the > kernel goes into a loop someplace and never gets out.) > This occurs whether ACPI is enabled or not. > > Unfortunately, the hang occurs before the system can > enter even single user mode, making a post of the full > device probe impossible. I've tried to reproduce the > five lines proceeding the hang to give an idea of > where it's stopping. > > Using the stock GENERIC kernel configuration with > verbose logging and ACPI enabled, it stops boot right > after printing: > > lo0: bpf attached > rr232x: nfirewire 0: 1 nodes, maxhop <=0, cable IRM = > 0 (me) > firewire 0: bus manager0 (me) > o controller detected. > > Compiling GENERIC without Firewire (but with ACPI > enabled) gives: > > rr232x: no controller detected > acpi_acad0: acline initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > battery0: battery initialization start > battery0: battery initialization done, tried 1 times > > When ACPI is disabled, the GENERIC kernel hangs right > after printing: > > lo0: bpf attached > rr232x: nfirewire 0: 1 nodes, maxhop <=0, cable IRM = > 0 (me) > firewire 0: bus manager0 (me) > o controller detected. > > When I try to run GENERIC without ACPI and without > Firewire compiled in, I get: > > lo0: bpf attached > rr232x: no controller detected > > followed by the kernel hanging. > > FreeBSD 6.2 runs very well on this machine, and the > output of pciconf -vl is: > agp0@pci0:0:0: class=0x060000 card=0x00000000 > chip=0x1a308086 rev=0x11 hdr=0x00 > vendor = 'Intel Corporation' > device = '82845/E/MP/MZ Brookdale CPU to I/O > Bridge' > class = bridge > subclass = HOST-PCI > pcib1@pci0:1:0: class=0x060400 card=0x00000000 > chip=0x1a318086 rev=0x11 hdr=0x01 > vendor = 'Intel Corporation' > device = '82845/E/MP/MZ Brookdale CPU to AGP > Bridge' > class = bridge > subclass = PCI-PCI > uhci0@pci0:29:0: class=0x0c0300 card=0x00000000 > chip=0x24828086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CA/CAM (ICH3-S/ICH3-M) USB > Controller' > class = serial bus > subclass = USB > uhci1@pci0:29:1: class=0x0c0300 card=0x00000000 > chip=0x24848086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CA/CAM (ICH3-S/ICH3-M) USB > Controller' > class = serial bus > subclass = USB > uhci2@pci0:29:2: class=0x0c0300 card=0x00000000 > chip=0x24878086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CA/CAM (ICH3-S/ICH3-M) USB > Controller' > class = serial bus > subclass = USB > pcib2@pci0:30:0: class=0x060400 card=0x00000000 > chip=0x24488086 rev=0x42 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub > Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:31:0: class=0x060100 card=0x00000000 > chip=0x248c8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CAM LPC Interface or ISA bridge: > see Notes' > class = bridge > subclass = PCI-ISA > atapci0@pci0:31:1: class=0x01018a card=0x00000000 > chip=0x248a8086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CAM (ICH3-M) UltraATA/100 EIDE > Controller' > class = mass storage > subclass = ATA > pcm0@pci0:31:5: class=0x040100 card=0x88801558 > chip=0x24858086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 > Audio Controller' > class = multimedia > subclass = audio > none0@pci0:31:6: class=0x070300 card=0x18001558 > chip=0x24868086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 > Modem Controller' > class = simple comms > subclass = generic modem > drm0@pci1:0:0: class=0x030000 card=0x88801558 > chip=0x4c661002 rev=0x01 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Mobility Radeon 9000' > class = display > subclass = VGA > rl0@pci2:0:0: class=0x020000 card=0x88801558 > chip=0x813910ec rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RT8139 (A/B/C/810x/813x/C+) Fast > Ethernet Adapter' > class = network > subclass = ethernet > fwohci0@pci2:2:0: class=0x0c0010 card=0x88801558 > chip=0x8026104c rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'TSB43AB21 1394a-2000 OHCI > PHY/link-layer Controller' > class = serial bus > subclass = FireWire > bktr0@pci2:4:0: class=0x040000 card=0x00041461 > chip=0x036e109e rev=0x11 hdr=0x00 > vendor = 'Conexant (Was: Brooktree Corp)' > device = 'Bt878/Fusion 878A Mediastream > Controller' > class = multimedia > subclass = video > none1@pci2:4:1: class=0x048000 card=0x00041461 > chip=0x0878109e rev=0x11 hdr=0x00 > vendor = 'Conexant (Was: Brooktree Corp)' > device = 'Bt878/Fusion878A Video Capture (Audio > Section)' > class = multimedia > uhci3@pci2:5:0: class=0x0c0300 card=0x12340925 > chip=0x30381106 rev=0x50 hdr=0x00 > vendor = 'VIA Technologies Inc' > device = 'VT82xxxxx UHCI USB 1.1 Controller (All > VIA Chipsets)' > class = serial bus > subclass = USB > uhci4@pci2:5:1: class=0x0c0300 card=0x12340925 > chip=0x30381106 rev=0x50 hdr=0x00 > vendor = 'VIA Technologies Inc' > device = 'VT82xxxxx UHCI USB 1.1 Controller (All > VIA Chipsets)' > class = serial bus > subclass = USB > ehci0@pci2:5:2: class=0x0c0320 card=0x12340925 > chip=0x31041106 rev=0x51 hdr=0x00 > vendor = 'VIA Technologies Inc' > device = 'VT6202 USB 2.0 Enhanced Host > Controller' > class = serial bus > subclass = USB > cbb0@pci2:9:0: class=0x060700 card=0x88801558 > chip=0xac55104c rev=0x01 hdr=0x02 > vendor = 'Texas Instruments (TI)' > device = 'PCI1520 PC Card CardBus Controller' > class = bridge > subclass = PCI-CardBus > cbb1@pci2:9:1: class=0x060700 card=0x88801558 > chip=0xac55104c rev=0x01 hdr=0x02 > vendor = 'Texas Instruments (TI)' > device = 'PCI1520 PC Card CardBus Controller' > class = bridge > subclass = PCI-CardBus > > and my make options are -O -pipe. Posted below is the > device probe of my FreeBSD 6.2 system. > > 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 6.2-STABLE #3: Tue Jun 26 16:28:09 CDT 2007 > root@Maxwell.local.bsd:/usr/obj/usr/src/sys/SAGER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3066.79-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff > Features2=0x400 > Logical CPUs per core: 2 > real memory = 1073676288 (1023 MB) > avail memory = 1041166336 (992 MB) > ACPI APIC Table: > 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 > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > 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 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > acpi_button0: on acpi0 > acpi_lid0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > pcib0: port 0xcf8-0xcff iomem > 0xfff80000-0xffffffff on acpi0 > pci0: on pcib0 > agp0: mem > 0xa0000000-0xa3ffffff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > drm0: 2400 PCI> port 0xc000-0xc0ff mem > 0x90000000-0x97ffffff,0xe0000000-0xe000ffff irq 16 at > device 0.0 on pci1 > info: [drm] AGP at 0xa0000000 64MB > info: [drm] Initialized radeon 1.25.0 20060524 > uhci0: > port 0xe000-0xe01f irq 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: > on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, > addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: > port 0xe120-0xe13f irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: > on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, > addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: > port 0xe240-0xe25f irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: > on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, > addr 1 > uhub2: 2 ports with 2 removable, self powered > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > rl0: port 0xa400-0xa4ff > mem 0xd0008000-0xd00080ff irq 18 at device 0.0 on pci2 > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, auto > rl0: Ethernet address: 00:90:f5:20:01:eb > fwohci0: mem > 0xd0000800-0xd0000fff,0xd0004000-0xd0007fff irq 17 at > device 2.0 on pci2 > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:90:f5:01:00:20:01:eb > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:90:f5:20:01:eb > fwe0: Ethernet address: 02:90:f5:20:01:eb > fwe0: if_start running deferred for Giant > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc000ffc1, gen=1, CYCLEMASTER mode > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > firewire0: bus manager 1 (me) > bktr0: mem 0x80000000-0x80000fff irq > 17 at device 4.0 on pci2 > bktr0: [GIANT-LOCKED] > bktr0: AVer Media TV/FM, Philips NTSC tuner. > pci2: at device 4.1 (no driver attached) > uhci3: port 0xa000-0xa01f > irq 16 at device 5.0 on pci2 > uhci3: [GIANT-LOCKED] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, > addr 1 > uhub3: 2 ports with 2 removable, self powered > uhci4: port 0xa120-0xa13f > irq 19 at device 5.1 on pci2 > uhci4: [GIANT-LOCKED] > usb4: on uhci4 > usb4: USB revision 1.0 > uhub4: VIA UHCI root hub, class 9/0, rev 1.00/1.00, > addr 1 > uhub4: 2 ports with 2 removable, self powered > ehci0: mem > 0xd0000000-0xd00000ff irq 18 at device 5.2 on pci2 > ehci0: [GIANT-LOCKED] > usb5: EHCI version 0.95 > usb5: companion controllers, 2 ports each: usb3 usb4 > usb5: on ehci0 > usb5: USB revision 2.0 > uhub5: VIA EHCI root hub, class 9/0, rev 2.00/1.00, > addr 1 > uhub5: 4 ports with 4 removable, self powered > cbb0: at device 9.0 on > pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb1: at device 9.1 on > pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1100-0x110f at > device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pcm0: port > 0xe400-0xe4ff,0xe600-0xe63f irq 17 at device 31.5 on > pci0 > pcm0: > pci0: at device 31.6 (no > driver attached) > 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 Generic PS/2 mouse, device ID 0 > speaker0: port 0x61 on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 > irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: port > 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in > COMPATIBLE mode > ppc0: FIFO with 1/0/0 bytes threshold > ppbus0: on ppc0 > ppbus0: IEEE1284 device found /NIBBLE/ECP > Probing for PnP devices on ppbus0: > ppbus0: > PJL,PCL,IBMPPR,EPSONFX,PCLXL > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff > irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio1: port > 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcffff,0xe3000-0xe3fff,0xe4000-0xe5fff on > isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem > 0xa0000-0xbffff on isa0 > ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr > 2, iclass 3/1 > ums0: 3 buttons and Z dir. > Timecounters tick every 1.000 msec > ad0: 76319MB at ata0-master > UDMA100 > acd0: DVDR at > ata1-master UDMA33 > firewire0: New S400 device ID:0030e0f4e020d4f8 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 > ascq=0x00 sks=0x48 0x00 0x01 > SMP: AP CPU #1 Launched! > da0 at sbp0 bus 0 target 0 lun 0 > da0: Fixed Simplified > Direct Access SCSI-4 device > da0: 50.000MB/s transfers > da0: 58644MB (120103200 512 byte sectors: 255H 63S/T > 7476C) > cd0 at ata1 bus 0 target 0 lun 0 > cd0: Removable CD-ROM > SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, > Medium not present > Trying to mount root from ufs:/dev/ad0s2a > Loading configuration files. > > If there is any further system configuration data you > need, just let me know. FreeBSD is my main OS, and I'd > love to be able to start using FreeBSD 7 on it. Thanks > in advance. > > > > ____________________________________________________________________________________ > Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! > http://tv.yahoo.com/collections/3658 > _______________________________________________ > 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 Thu Sep 13 22:07:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D7FC16A418 for ; Thu, 13 Sep 2007 22:07:19 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4949C13C45A for ; Thu, 13 Sep 2007 22:07:19 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id l8DM7C0M055944; Thu, 13 Sep 2007 15:07:12 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id l8DM7Bhr055943; Thu, 13 Sep 2007 15:07:11 -0700 (PDT) (envelope-from obrien) Date: Thu, 13 Sep 2007 15:07:11 -0700 From: "David O'Brien" To: Pete Message-ID: <20070913220711.GD75569@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Pete , freebsd-current@freebsd.org References: <46E92139.1030508@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E92139.1030508@adam.com.au> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.x and HP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Thu, 13 Sep 2007 22:07:19 -0000 On Thu, Sep 13, 2007 at 09:08:33PM +0930, Pete wrote: > I've been having a rather unusual, but very annoying issue with HP DL140 > G3 Servers and FreeBSD. I thought I might give the mailing list a try to .. > When using FreeBSD 6.1, I can't even get as far as sysinstall. The > server tends to hang when initializing the drives just before it enters > into the usual setup utility. When using FreeBSD 6.2, I can get into .. > If anyone could shed some light on the situation or has any ideas, it > would be greatly appreciated. You may get a better responce if you emailed freebsd-stable - as that list is for 6.x users. This list is for freebsd-current, which is about FreeBSD 7. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 22:07:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA75716A420 for ; Thu, 13 Sep 2007 22:07:45 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id AD04513C45B for ; Thu, 13 Sep 2007 22:07:45 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id 4D39E118C9; Thu, 13 Sep 2007 17:07:45 -0500 (CDT) Date: Thu, 13 Sep 2007 17:07:44 -0500 From: Craig Boston To: Pawel Jakub Dawidek Message-ID: <20070913220744.GB5814@nowhere> Mail-Followup-To: Craig Boston , Pawel Jakub Dawidek , current@freebsd.org References: <20070906184853.GB90021@roadrunner.spoerlein.net> <20070910195833.GE1103@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910195833.GE1103@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 22:07:46 -0000 On Mon, Sep 10, 2007 at 09:58:33PM +0200, Pawel Jakub Dawidek wrote: > Can you try recent HEAD? I committed a change that allows ZFS cache > (ARC) to use more memory. This should be safe after dfr@'s vnode leak > fix and should also help performance. FYI, I've started getting kmem_map too small panics again after this change, on i386. 2GB physical RAM vm.kmem_size: 671088640 (set in loader.conf) kern.maxvnodes: 75000 (down from the autotuned value of 100000) vfs.zfs.arc_min: 20971520 vfs.zfs.arc_max: 503316480 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 Current values from a live system: kstat.zfs.misc.arcstats.c_min: 20971520 kstat.zfs.misc.arcstats.c_max: 503316480 kstat.zfs.misc.arcstats.size: 321891840 The panic showed "kmem_malloc(1568768): kmem_map too small: 458543104 total allocated" last time it happened. 640MB for kmem is pretty close to the max I can bump it up to before the system no longer boots for whatever reason. Let me know if I'm missing any relevant stats... Craig From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 22:26:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97BCC16A418; Thu, 13 Sep 2007 22:26:31 +0000 (UTC) (envelope-from lists@avioc.org) Received: from didy.avioc.org (didy.avioc.org [71.32.26.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4CECF13C46C; Thu, 13 Sep 2007 22:26:31 +0000 (UTC) (envelope-from lists@avioc.org) Received: from localhost (mail.internal.avioc.org [192.168.2.252]) by didy.avioc.org (Postfix) with ESMTP id 95FDBEB644E; Thu, 13 Sep 2007 17:09:06 -0500 (CDT) X-Virus-Scanned: amavisd-new at mail.internal.avioc.org Received: from didy.avioc.org ([192.168.2.252]) by localhost (mail.internal.avioc.org [192.168.2.252]) (amavisd-new, port 10024) with LMTP id L1p3oxcfnGkq; Thu, 13 Sep 2007 17:09:03 -0500 (CDT) Received: from [192.168.2.8] (section-8.internal.avioc.org [192.168.2.8]) by didy.avioc.org (Postfix) with ESMTP id 5CE16EB644D; Thu, 13 Sep 2007 17:09:03 -0500 (CDT) From: Brandon Weisz To: Joao Barros In-Reply-To: <70e8236f0709131425h2f651c32j5e23d7901ce6e1f7@mail.gmail.com> References: <20070906184853.GB90021@roadrunner.spoerlein.net> <20070910195833.GE1103@garage.freebsd.pl> <70e8236f0709131425h2f651c32j5e23d7901ce6e1f7@mail.gmail.com> Content-Type: text/plain Date: Thu, 13 Sep 2007 17:09:03 -0500 Message-Id: <1189721343.17751.20.camel@section-8.ipv6.avioc.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 22:26:31 -0000 On Thu, 2007-09-13 at 22:25 +0100, Joao Barros wrote: > On 9/10/07, Pawel Jakub Dawidek wrote: > > On Thu, Sep 06, 2007 at 08:48:53PM +0200, Ulrich Spoerlein wrote: > > > Hi, it's me again with another stupid question, > > > > > > ever since I switched my /usr and /home to ZFS, the system has become > > > _very_ unresponsive under load. This is not because of CPU load, but I/O > > > load. > > > > Can you try recent HEAD? I committed a change that allows ZFS cache > > (ARC) to use more memory. This should be safe after dfr@'s vnode leak > > fix and should also help performance. > > > > -- > > Pawel Jakub Dawidek http://www.wheel.pl > > pjd@FreeBSD.org http://www.FreeBSD.org > > FreeBSD committer Am I Evil? Yes, I Am! > > > > > > This happened 1 day after compiling new sources: > panic: kmem_malloc(90112): kmem_map too small: 329805824 total allocated > when writing through NFS. > On FreeBSD xeon.bsdtech.org 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Tue > Sep 11 00:08:39 WEST 2007 > root@xeon.bsdtech.org:/usr/obj/usr/src/sys/GENERIC i386 > Machine has 1GB of ram and: > vfs.zfs.arc_min: 16777216 > vfs.zfs.arc_max: 251658240 > vfs.zfs.mdcomp_disable: 0 > vfs.zfs.prefetch_disable: 1 > vfs.zfs.zio.taskq_threads: 0 > vfs.zfs.recover: 0 > vfs.zfs.vdev.cache.size: 10485760 > vfs.zfs.vdev.cache.max: 16384 > vfs.zfs.cache_flush_disable: 0 > vfs.zfs.zil_disable: 0 > vfs.zfs.debug: 0 > > I hadn't had any panics with sources from August 16 but before your > recent changes vfs.zfs.arc_max was 167772160 > kern.maxvnodes is not set to 50000 as recomended ( on purpose ) and is > currently at 52242 set by the system. Is 50000 still recomended after > your changes? > Just a "me too" - I am also seeing "kmem_map too small" panics on a amd64 NFS server with 1 GB ram after the recent zfs changes. setting vm.kmem_size_max="402653184" seems to have stopped the panics, however this was not needed previously. Brandon From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 22:31:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C61E16A418 for ; Thu, 13 Sep 2007 22:31:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 11C2713C459 for ; Thu, 13 Sep 2007 22:31:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 3885722473D; Fri, 14 Sep 2007 00:14:16 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-8-106.dynamic.mnet-online.de [82.135.8.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTP id 2B01B905F3; Fri, 14 Sep 2007 00:14:15 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.8/8.13.8/Submit) with ESMTP id l8DMEF4g000516; Fri, 14 Sep 2007 00:14:15 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Fri, 14 Sep 2007 00:14:15 +0200 (CEST) From: Michael Reifenberger To: Brooks Talley In-Reply-To: <22187550.52511189717324600.JavaMail.root@zmail.illuminati.org> Message-ID: <20070914001247.C484@fw.reifenberger.com> References: <22187550.52511189717324600.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current Subject: Re: Building a 32 bit chroot on 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, 13 Sep 2007 22:31:49 -0000 On Thu, 13 Sep 2007, Brooks Talley wrote: > Date: Thu, 13 Sep 2007 14:02:04 -0700 (PDT) > From: Brooks Talley > To: freebsd-current > Subject: Building a 32 bit chroot on amd64? > > Hi, everyone. I'm trying to build a 32 bit chroot on a 7.0-CURRENT amd64 installation. The sources are up to date. > > "make TARGET_ARCH=i386 buildworld" fails partway through with the message: > Could you try: make TARGET_ARCH=i386 TARGET_CPUTYPE=i386 buildworld Thats what I use. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 22:34:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FF8C16A419 for ; Thu, 13 Sep 2007 22:34:18 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by mx1.freebsd.org (Postfix) with ESMTP id 18CD813C465 for ; Thu, 13 Sep 2007 22:34:17 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so184291ele for ; Thu, 13 Sep 2007 15:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=UnLYX9+jQtryZnTFLq4PrZ2mWA3f6LaOHdJlSR40Yo8=; b=DytQc/uQ1b6p8usnNAkltE2OVml3zE7P+pnL3N8t3jFXvKV9kZRJfZ1NtCslPRoEoz3cQF+g6U+l+Z8ct13QmzBmt7GiyRS/73ba8WpA0NtC1jNzrFQYGngoqMDqCvwMfts0/dtE+FKnHyXV6UywWizCheRyeDEYinp2ZpMX2bY= 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=Gx3+LH7HwpdDmp6qkqGT6KSjCJRknxGajRNT+BbKOKmuxDukdyNTzB9EZ48M52qXBUcYybJ19abPvUjQAg514GunQc9fPy3TBmt/EnOOKYODR50r3jOIHw8Xejai2i/Vfkj+0CWy8kWxvBGzSW/hho8Jry3I2P4hFxnf6LGJmhY= Received: by 10.142.83.4 with SMTP id g4mr267640wfb.1189721123969; Thu, 13 Sep 2007 15:05:23 -0700 (PDT) Received: by 10.143.10.13 with HTTP; Thu, 13 Sep 2007 15:05:18 -0700 (PDT) Message-ID: <54db43990709131505x73410aaand25705f9d6c1d51b@mail.gmail.com> Date: Thu, 13 Sep 2007 18:05:18 -0400 From: "Bob Johnson" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: amd64 7.0 on HP systems? (dc7700 convertible minitower) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 22:34:18 -0000 Trying to install the amd64 7.0-200708 snapshot on an HP Compaq dc7700 convertible minitower gives the "panic: No BIOS smap info from loader" error described in PR 111952 and 111955. The amd64 6.2-RELEASE also gives this panic. The i386 7.0-200708 snapshot installs ok. I haven't tested other installs. Archive searches haven't turned up solutions other than "upgrade the BIOS and see what happens" or "use i386 and see if that works". Is there hope that this panic will be fixed in the amd64 7.0-RELEASE? Or should I just assume I will be using i386? The dc7700 is Intel Core2 CPU 6700, 4 GB RAM, BIOS 786E1 version 1.10 (seems to be most recent available). Thanks, - Bob From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 22:47:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 939BC16A41A for ; Thu, 13 Sep 2007 22:47:55 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from zmail.illuminati.org (mail.illuminati.org [70.42.141.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7452B13C442 for ; Thu, 13 Sep 2007 22:47:55 +0000 (UTC) (envelope-from brooks@illuminati.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmail.illuminati.org (Postfix) with ESMTP id 1CDC316C86E1 for ; Thu, 13 Sep 2007 15:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.002, BAYES_00=-2.599] Received: from zmail.illuminati.org ([127.0.0.1]) by localhost (zmail.illuminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGX0AGFjvBQX for ; Thu, 13 Sep 2007 15:47:52 -0700 (PDT) Received: from zmail.illuminati.org (zmail.illuminati.org [10.32.1.33]) by zmail.illuminati.org (Postfix) with ESMTP id 7CEAF16C86DE for ; Thu, 13 Sep 2007 15:47:52 -0700 (PDT) Date: Thu, 13 Sep 2007 15:47:52 -0700 (PDT) From: Brooks Talley To: freebsd-current Message-ID: <29536115.52741189723672473.JavaMail.root@zmail.illuminati.org> In-Reply-To: <20070914001247.C484@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [67.168.65.79] Subject: Re: Building a 32 bit chroot on 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, 13 Sep 2007 22:47:55 -0000 ----- "Michael Reifenberger" wrote: > On Thu, 13 Sep 2007, Brooks Talley wrote: > > > Date: Thu, 13 Sep 2007 14:02:04 -0700 (PDT) > > From: Brooks Talley > > To: freebsd-current > > Subject: Building a 32 bit chroot on amd64? > > > > Hi, everyone. I'm trying to build a 32 bit chroot on a 7.0-CURRENT > amd64 installation. The sources are up to date. > > > > "make TARGET_ARCH=i386 buildworld" fails partway through with the > message: > > > > Could you try: > make TARGET_ARCH=i386 TARGET_CPUTYPE=i386 buildworld Well, that's different at least. This time it breaks libgcc, with the clearly wrong but not surprising message that i386 doesn't support the x86_64 instruction set :) Cheers -b ===> gnu/lib/libgcc (obj,depend,all,install) make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tm.h TARGET_CPU_DEFAULT="" HEADERS="options.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/freebsd.h defaults.h" DEFINES="" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc tconfig.h TARGET_CPU_DEFAULT="" HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET" /bin/sh /usr/src/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tconfig.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc options.h awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /usr/src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.opt > optionlist awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h make -f /usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /usr/src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h /usr/bin/cc -c -O2 -fno-strict-aliasing -pipe -march=i386 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1: error: CPU you selected does not support x86-64 instruction set /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1: error: CPU you selected does not support x86-64 instruction set From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 23:52:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B720E16A41B for ; Thu, 13 Sep 2007 23:52:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8182B13C442 for ; Thu, 13 Sep 2007 23:52:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so486946rvb for ; Thu, 13 Sep 2007 16:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=1eQ5Xa+qBMXkHAoINkLCr7F6c7V9w7bYG4W+tirQeag=; b=JQ/fDp5QHXEOiWySae93LdxoJ5XA69J7j+5IrNYGZ3qK0OCVTneSQSMNt0Sz3+Xdq8WLUvQMVLxNkSny0vJ6TZP8Vo7VgKJlj3NhRLVmXEzgZ2cwf71iZxqqdhh85J7bUaqJZDJ2rAdsTcU7zZQV0XG6mjYCeT/5ueV5BFv6AF8= 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=gGdXaewbkfzWO93nbS4ZA50ouHdMD8ew49SzqnaR62g/JVhTUUaV8yYLZgBYfRcOvKc8cOQJYmAUJJ8EHoCgpmS6bN2VOwY5fBCr/m9HON4QKDzmHMzA1ViozBR0KX9BpvJCWCy05PawS+wUm6zyEHBRCfAqSTuF9h36PyduNI8= Received: by 10.115.22.1 with SMTP id z1mr1015952wai.1189727544791; Thu, 13 Sep 2007 16:52:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id j21sm195391wah.2007.09.13.16.52.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2007 16:52:23 -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 l8DNnds2016996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 08:49:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l8DNncmX016995; Fri, 14 Sep 2007 08:49:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 14 Sep 2007 08:49:38 +0900 From: Pyun YongHyeon To: Jonathan Groll Message-ID: <20070913234938.GA16931@cdnetworks.co.kr> References: <20070913203518.GP12985@groll.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070913203518.GP12985@groll.co.za> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: zfs kernel module on sparc64? 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, 13 Sep 2007 23:52:25 -0000 On Thu, Sep 13, 2007 at 10:35:20PM +0200, Jonathan Groll wrote: > Is there some obvious trick that I'm missing for building the (-current) > zfs module on sparc64? > > Building a GENERIC kernel with `make buildkernel` does not build zfs.ko > on sparc64. Is there something in the kernel config that needs to be set > that I am perhaps foolishly overlooking? I've also tried building the > module directly in /usr/src/sys/modules/zfs/, but trying to kldload the > module just resulted in link_elf: symbol undefined appearing on the > root console. > > What have I missed? > I've encountered the same issue. Latest CURRENT on sparc64 can't load any kernel modules. I'm still investigating. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 02:43:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C8B16A41B for ; Fri, 14 Sep 2007 02:43:12 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (goat.gigo.com [216.218.228.114]) by mx1.freebsd.org (Postfix) with ESMTP id 155EF13C48D for ; Fri, 14 Sep 2007 02:43:12 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from 201.24.13.31 (201-24-13-31.bsace703.dsl.brasiltelecom.net.br [201.24.13.31]) by goat.gigo.com (Postfix) with ESMTP id D2D06B88F for ; Thu, 13 Sep 2007 19:43:08 -0700 (PDT) Received: (qmail 84461 invoked by uid 1001); 13 Sep 2007 23:42:39 -0300 Message-ID: <20070914024239.84366.qmail@exxodus.fedaykin.here> Date: Thu, 13 Sep 2007 23:42:39 -0300 From: Mario Sergio Fujikawa Ferreira To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: hang on startx with nvidia / also with emu10kx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 02:43:12 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, FreeBSD exxodus.fedaykin.here 7.0-CURRENT FreeBSD 7.0-CURRENT #9: Thu Sep 13 22:46:14 BRT 2007 lioux@exxodus:/usr/src/sys/i386/compile/LIOUX i386 -CURRENT as of today September 13th 2007 with latest ports. xorg works fine if I launch it with tightvnc. However, the system hangs if I try to startx using the nvidia driver. The same happens if I try to kldload emu10kx. How do I force the system to issue a kernel dump when it hangs? I want to be able to provide a proper backtrace of the system if possible. :) Are these known issues? Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" 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 #9: Thu Sep 13 22:46:14 BRT 2007 lioux@exxodus:/usr/src/sys/i386/compile/LIOUX WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2410.99-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2082811904 (1986 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 WITNESS: spin lock intrcnt not in order list ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard WITNESS: spin lock ctl.rm_mtx not in order list kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi0: Power Button (fixed) acpi0: reservation of fefff000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 4.0 on pci0 pci1: on pcib1 nvidia0: port 0x8c00-0x8c7f mem 0xfa000000-0xfaffffff,0xc0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] WITNESS: spin lock dev.rm_mtx not in order list pci0: at device 8.0 (no driver attached) isab0: at device 9.0 on pci0 isa0: on isab0 pci0: at device 9.1 (no driver attached) pci0: at device 9.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 10.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 10.1 on pci0 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 usb1: handing over low speed device on port 2 to usb0 uhub1: port 2, device disappeared after reset ugen0: on uhub1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 12.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 13.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 13.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb80f mem 0xfe02b000-0xfe02bfff irq 21 at device 13.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib2: at device 14.0 on pci0 pci2: on pcib2 atapci4: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9cff irq 17 at device 7.0 on pci2 atapci4: [ITHREAD] ata8: on atapci4 ata8: [ITHREAD] ata9: on atapci4 ata9: [ITHREAD] pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) pci2: at device 8.2 (no driver attached) pci2: at device 11.0 (no driver attached) nfe0: port 0xb400-0xb407 mem 0xfe02a000-0xfe02afff,0xfe029000-0xfe0290ff,0xfe028000-0xfe02800f irq 22 at device 16.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:1b:fc:39:fb:23 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] pcib3: at device 22.0 on pci0 pci3: on pcib3 atapci5: port 0x7c00-0x7c7f mem 0xfdeff000-0xfdeff07f,0xfdef8000-0xfdefbfff irq 16 at device 0.0 on pci3 atapci5: [ITHREAD] ata10: on atapci5 ata10: [ITHREAD] ata11: on atapci5 ata11: [ITHREAD] acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff,0xd0000-0xd47ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ums0: on uhub0 ums0: 8 buttons and Z dir. Timecounters tick every 0.868 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging disabled acd0: DVDR at ata0-master UDMA33 acd1: DVDROM at ata0-slave UDMA33 ad4: 476940MB at ata2-master SATA150 ad6: 286188MB at ata3-master SATA150 ad16: 76319MB at ata8-master UDMA100 ad18: 76319MB at ata9-master UDMA100 SMP: AP CPU #1 Launched! hwpmc: TSC/1/0x20 K8/4/0x1ff WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad4s5 is msdosfs/ . Trying to mount root from ufs:/dev/ad4s3a WARNING: / was not properly dismounted acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 nfe0: link state changed to UP --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pciconf.txt" none0@pci0:0:0: class=0x050000 card=0x02f410de chip=0x02f410de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:1: class=0x050000 card=0x02fa10de chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:2: class=0x050000 card=0x02fe10de chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:3: class=0x050000 card=0x02f810de chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:4: class=0x050000 card=0x02f910de chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:5: class=0x050000 card=0x02ff10de chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:6: class=0x050000 card=0x027f10de chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:7: class=0x050000 card=0x027e10de chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM pcib1@pci0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCI Express Bridge' class = bridge subclass = PCI-PCI none8@pci0:8:0: class=0x050000 card=0xcb841043 chip=0x036910de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Memory Controller' class = memory subclass = RAM isab0@pci0:9:0: class=0x060100 card=0xcb841043 chip=0x036010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 LPC Bridge' class = bridge subclass = PCI-ISA none9@pci0:9:1: class=0x0c0500 card=0xcb841043 chip=0x036810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SMBus' class = serial bus subclass = SMBus none10@pci0:9:2: class=0x050000 card=0xcb841043 chip=0x036a10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Memory Controller' class = memory subclass = RAM ohci0@pci0:10:0: class=0x0c0310 card=0xcb841043 chip=0x036c10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 USB Controller' class = serial bus subclass = USB ehci0@pci0:10:1: class=0x0c0320 card=0xcb841043 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 USB Controller' class = serial bus subclass = USB atapci0@pci0:12:0: class=0x01018a card=0xcb841043 chip=0x036e10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 IDE' class = mass storage subclass = ATA atapci1@pci0:13:0: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA atapci2@pci0:13:1: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA atapci3@pci0:13:2: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA pcib2@pci0:14:0: class=0x060401 card=0xcb8410de chip=0x037010de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP55 PCI bridge' class = bridge subclass = PCI-PCI nfe0@pci0:16:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 Ethernet' class = bridge pcib3@pci0:22:0: class=0x060400 card=0x000010de chip=0x037510de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP55 PCI Express bridge' class = bridge subclass = PCI-PCI hostb0@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI nvidia0@pci1:0:0: class=0x030000 card=0x00000000 chip=0x040210de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' class = display subclass = VGA atapci4@pci2:7:0: class=0x018000 card=0x00051103 chip=0x00041103 rev=0x03 hdr=0x00 vendor = 'Triones Technologies Inc. (HighPoint)' device = 'HPT3xx UDMA66/100/133 EIDE Controller' class = mass storage none11@pci2:8:0: class=0x040100 card=0x10071102 chip=0x00041102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'Creative SB Audigy 2 ZS (WDM) Audigy Audio Processor' class = multimedia subclass = audio none12@pci2:8:1: class=0x098000 card=0x00401102 chip=0x70031102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Creative Labs SB Audigy MIDI/Game port' class = input device none13@pci2:8:2: class=0x0c0010 card=0x00101102 chip=0x40011102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Audigy IEEE1394a Firewire Controller' class = serial bus subclass = FireWire none14@pci2:11:0: class=0x0c0010 card=0x815b1043 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB21/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class = serial bus subclass = FireWire atapci5@pci3:0:0: class=0x018000 card=0x819f1043 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3132 PCI Express (1x) to 2 Port SATA300' class = mass storage --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pkg_info.txt" GraphicsMagick-1.1.7_2 Fast image processing tools based on ImageMagick ORBit2-2.14.8 High-performance CORBA ORB with support for the C language OpenEXR-1.4.0 A high dynamic-range (HDR) image file format OpenSP-1.5.2 This package is a collection of SGML/XML tools called OpenS Win4BSD-4.0_63936_i386-freebsd Win4BSD Pro 4.0-63936 aalib-1.4.r5_3 An ascii art library acroread7-7.0.9_2,1 Adobe Reader for view, print, and search PDF documents (ENU acroreadwrapper-0.0.20060221_2 Wrapper script for Adobe Reader adobe-cmaps-20051217_1 Adobe CMap collection akode-2.0.1,1 Default KDE audio backend akode-plugins-jack-2.0.1,1 Jack output plugin for akode akode-plugins-mpc-2.0.1,1 Musepack decoder plugin for akode akode-plugins-mpeg-2.0.1,1 MPEG audio decoder plugin for akode akode-plugins-oss-2.0.1,1 OSS output plugin for akode akode-plugins-polypaudio-2.0.1_1,1 Polypaudio output plugin for akode akode-plugins-resampler-2.0.1,1 Resampler plugin for akode akode-plugins-xiph-2.0.1_2,1 FLAC/Speex/Vorbis decoder plugin for akode amspsfnt-1.0_5 AMSFonts PostScript Fonts (Adobe Type 1 format) apache-2.2.6 Version 2.2 of Apache web server with prefork MPM. apache-ant-1.7.0_1 Java- and XML-based build tool, conceptually similar to mak appres-1.0.1 Program to list application's resources apr-gdbm-db42-1.2.8_1 The Apache Group's Portability Library argouml-0.24_1 A UML design tool with cognitive support arts-1.5.7_1,1 Audio system for the KDE integrated X11 desktop artswrapper-1.5.3 Setuid wrapper for arts aspell-0.60.5_2 Spelling checker with better suggestion logic than ispell ataidle-1.0 Utility to spin down ATA drives atk-1.18.0_1 A GNOME accessibility toolkit (ATK) autoconf-2.13.000227_6 Automatically configure source code on many Un*x platforms autoconf-2.53_4 Automatically configure source code on many Un*x platforms autoconf-2.59_3 Automatically configure source code on many Un*x platforms autoconf-2.61_2 Automatically configure source code on many Un*x platforms autoconf-wrapper-20070404 Wrapper script for GNU autoconf automake-1.4.6_4 GNU Standards-compliant Makefile generator (1.4) automake-1.5_4,1 GNU Standards-compliant Makefile generator (1.5) automake-1.6.3 GNU Standards-compliant Makefile generator (1.6) automake-1.9.6_2 GNU Standards-compliant Makefile generator (1.9) automake-wrapper-20070404 Wrapper script for GNU automake avahi+libdns-0.6.21 Service discovery on a local network bash-3.2.25 The GNU Project's Bourne Again SHell bdftopcf-1.0.1 Convert X font from BDF to PCF beforelight-1.0.2 A sample screen saver for X bigreqsproto-1.0.2 BigReqs extension headers bison-1.75_2,1 A parser generator from FSF, (mostly) compatible with Yacc bitmap-1.0.3 Bitmap editor and converter utilities for X bitstream-vera-1.10_4 Bitstream Vera TrueType font collection c-ares-config-1.4.0 An asynchronous DNS resolver library ca_root_nss-3.11.7 The root certificate bundle from the Mozilla Project cairo-1.4.10 Vector graphics library with cross-device output support ccache-2.4_6 A tool to minimize the compile time of C/C++ programs ccxstream-1.0.15_1 Stream media files to XBox Media Center via XBMSP cdparanoia-3.9.8_8 A CDDA extraction tool (also known as ripper) cdrdao-1.2.1_1 Record CD-R[W]s in disk-at-once mode cdrtools-devel-2.01.01a11_1,1 CD/DVD and ISO-9660 image creation and extraction tools cmpsfont-1.0_6 Computer Modern PostScript Fonts (Adobe Type 1 format) compat4x-i386-5.3_9 A convenience package to install the compat4x libraries compat5x-i386-5.4.0.8_8 A convenience package to install the compat5x libraries compat6x-i386-6.2.602110.200706 A convenience package to install the compat6x libraries compositeproto-0.3.1 Composite extension headers cups-base-1.2.12 Common UNIX Printing System curl-7.16.3 Non-interactive tool to get files from FTP, GOPHER, HTTP(S) cyrus-sasl-2.1.22 RFC 2222 SASL (Simple Authentication and Security Layer) daemontools-0.76_12 Service monitoring and logging utilities by djb damageproto-1.1.0_2 Damage extension headers db42-4.2.52_5 The Berkeley DB package, revision 4.2 dbus-1.0.2_2 A message bus system for inter-application communication dbus-glib-0.74 GLib bindings for the D-BUS messaging system dbus-qt3-0.70_1 Qt3 bindings for the D-BUS messaging system demime-1.1d A tool to scrub mime from mailing lists desktop-file-utils-0.12_1 A couple of command line utilities for working with desktop diablo-jdk-1.5.0.07.01_7 Java Development Kit 1.5.0_07.01 dirmngr-0.9.7_2 A client for managing and downloading certificate revocatio djbdns-1.05_10 A collection of secure and reliable DNS tools djbfft-0.76_2 An extremely fast library for floating-point convolution dmidecode-2.8 A tool for dumping DMI (SMBIOS) contents in human-readable dmxproto-2.2.2 DMX extension headers docbook-4.1_2 V4.1 of the DocBook DTD, designed for technical documentati docbook-sk-4.1.2_4 XML version of the DocBook DTD version controlled for Scrol docbook-xml-4.2_1 XML version of the DocBook DTD docbook-xml-4.3 DocBook/XML DTD V4.3, designed for technical documentation docbook-xml-4.4 DocBook/XML DTD V4.4, designed for technical documentation docbook-xsl-1.71.1_2 XSL DocBook stylesheets docproj-1.17_2 The "meta-port" for the FreeBSD Documentation Project dri-7.0.1,2 OpenGL hardware acceleration drivers for the DRI dsssl-docbook-modular-1.79_1,1 DSSSL stylesheets for the DocBook DTD by Norman Walsh dvd+rw-tools-7.0 DVD burning software dvipdfmx-20070409 Dvipdfm with Asian languages by CID-keyed font technology s dvipsk-tetex-5.95a_2 Convert a TeX DVI file to PostScript eclipse-3.2.2 An open extensible IDE for anything and nothing in particul eclipse-datatools-0.9.1_1 Datatools for eclipse eclipse-emf-2.2.1_1 Eclipse Modeling Framework eclipse-gef-3.2.2_2 Graphical Editing Framework for the Eclipse IDE eclipse-jad-3.2.4_1 Jad Java decompiler plugin for the Eclipse IDE eclipse-vep-1.2_1,1 A framework for creating GUI builders for Eclipse eclipse-webtools-1.5.2_1 Webtools for eclipse editres-1.0.3 Dynamic resource editor for X Toolkit Applications eel-2.18.3 Generally useful classes and extensions to GNOME encodings-1.0.2,1 X.Org Encoding fonts esound-0.2.38 A sound library for enlightenment package evieext-1.0.2 XEVIE extension headers expat-2.0.0_1 XML 1.0 parser written in C faac-1.25 MPEG-2 and MPEG-4 AAC audio encoder faad2-2.5,1 MPEG-2 and MPEG-4 AAC audio decoder fetchmail-6.3.8_4 Batch mail retrieval utility for IMAP/POP3/ETRN/ODMR ffmpeg-2007.07.12_3 Hyper fast realtime audio/video encoder/converter, streamin fftw3-3.1.2 Fast C routines to compute the Discrete Fourier Transform firefox-2.0.0.6,1 Web browser based on the browser portion of Mozilla fixesproto-4.0 Fixes extension headers fixrtf-0.1.20060303 A patch making it possible to embed PNGs into RTFs flac-1.1.2_1 Free lossless audio codec font-adobe-100dpi-1.0.0_1 X.Org Adobe 100dpi font font-adobe-75dpi-1.0.0 X.Org Adobe 75dpi font font-adobe-utopia-100dpi-1.0.1 X.Org Adobe Utopia 100dpi font font-adobe-utopia-75dpi-1.0.1 X.Org Adobe Utopia 75dpi font font-adobe-utopia-type1-1.0.1 X.Org Adobe Utopia Type1 font font-alias-1.0.1 X.Org Font aliases font-arabic-misc-1.0.0 X.Org miscellaneous Arabic fonts font-bh-100dpi-1.0.0 X.Org Bigelow Holmes 100dpi font font-bh-75dpi-1.0.0 X.Org Bigelow Holmes 75dpi font font-bh-lucidatypewriter-100dpi-1.0.0 X.Org Bigelow Holmes Lucida TypeWriter 100dpi font font-bh-lucidatypewriter-75dpi-1.0.0 X.Org Bigelow Holmes Lucida TypeWriter 75dpi font font-bh-ttf-1.0.0 X.Org Bigelow & Holmes TTF font font-bh-type1-1.0.0 X.Org Bigelow Holmes Type1 font font-bitstream-100dpi-1.0.0 X.Org Bitstream Vera 100dpi font font-bitstream-75dpi-1.0.0 X.Org Bitstream Vera 75dpi font font-bitstream-type1-1.0.0 X.Org Bitstream Vera Type1 font font-cronyx-cyrillic-1.0.0 X.Org Cronyx Cyrillic font font-cursor-misc-1.0.0 X.Org miscellaneous Cursor fonts font-daewoo-misc-1.0.0 X.Org miscellaneous Daewoo fonts font-dec-misc-1.0.0 X.Org miscellaneous Dec fonts font-ibm-type1-1.0.0 X.Org IBM Type1 font font-isas-misc-1.0.0 X.Org miscellaneous ISAS fonts font-jis-misc-1.0.0 X.Org miscellaneous JIS fonts font-micro-misc-1.0.0 X.Org miscellaneous Micro fonts font-misc-cyrillic-1.0.0 X.Org miscellaneous Cyrillic font font-misc-ethiopic-1.0.0 X.Org miscellaneous Ethiopic font font-misc-meltho-1.0.0_1 X.Org miscellaneous Meltho font font-misc-misc-1.0.0 X.Org miscellaneous Misc fonts font-mutt-misc-1.0.0 X.Org miscellaneous Mutt fonts font-schumacher-misc-1.0.0 X.Org miscellaneous Schumacher fonts font-screen-cyrillic-1.0.1 X.Org Screen Cyrillic font font-sony-misc-1.0.0 X.Org miscellaneous Sony fonts font-sun-misc-1.0.0 X.Org miscellaneous Sun fonts font-util-1.0.1 Create an index of X font files in a directory font-winitzki-cyrillic-1.0.0 X.Org Winitzki Cyrillic font font-xfree86-type1-1.0.0 X.Org XFree86 Type1 font fontcacheproto-0.1.2 Fontcache extension headers fontconfig-2.4.2_2,1 An XML-based font configuration API for X Windows fontsproto-2.0.2 Fonts extension headers fonttosfnt-1.0.3 Wrap a bitmap font in a sftn wrapper freetype-1.3.1_4 A free and portable TrueType font rendering engine freetype-tools-1.3.1_5 Tools for FreeType 1 freetype2-2.2.1_2 A free and portable TrueType font rendering engine fribidi-0.10.9 A Free Implementation of the Unicode Bidirectional Algorith fslsfonts-1.0.1 List fonts served by the X font server fstobdf-1.0.2 Generate BDF font from X font server fusefs-kmod-0.3.9.p1 Kernel module for fuse fusefs-libs-2.7.0_1 FUSE allows filesystem implementation in userspace fusefs-ntfs-1.826_1 Mount NTFS partitions (read/write) and disk images fusefs-smbnetfs-0.3.7 Mount smb shares (Fuse filesystem) gail-1.18.0_1 An implementation of the ATK interfaces for GTK+ widgets gamin-0.1.9 A file and directory monitoring system gawk-3.1.5_1 The GNU version of Awk gccmakedep-1.0.2 Create dependencies in makefiles using 'gcc -M' gconf2-2.18.0.1_1 A configuration database system for GNOME gd-2.0.35,1 A graphics library for fast creation of images gdbm-1.8.3_3 The GNU database manager gettext-0.16.1_3 GNU gettext package ghostscript-afpl-8.54_5,1 AFPL Postscript interpreter glib-1.2.10_12 Some useful routines of C programming (previous stable vers glib-2.12.13 Some useful routines of C programming (current stable versi glimpse-4.13.1 Text search engine glitz-0.5.6_1 OpenGL image compositing library glproto-1.4.8 GLX extension headers gmake-3.81_2 GNU version of 'make' utility gmime-2.2.10 Library (written in C) for parsing and creating messages us gnome-desktop-2.18.3 Additional UI API for GNOME 2 gnome-doc-utils-0.10.3_1 GNOME doc utils gnome-icon-theme-2.18.0_1 A collection of icons for the GNOME 2 desktop gnome-keyring-0.8.1_1 A program that keeps passwords and other secrets gnome-menus-2.18.3 Implementation of the FreeDesktop Desktop Menu Spec gnome-mime-data-2.18.0_1 A MIME and Application database for GNOME gnome-panel-2.18.3 Panel component for the GNOME 2 Desktop gnome-vfs-2.18.1_2 GNOME Virtual File System gnome_subr-1.0 Common startup and shutdown subroutines used by GNOME scrip gnomehier-2.2_2 A utility port that creates the GNOME directory tree gnupg-2.0.4 The GNU Privacy Guard gnutls-1.6.3 GNU Transport Layer Security library gpac-libgpac-0.4.4,1 Gpac MPEG-4 Systems library and headers gpgme-1.1.5 A library to make access to GnuPG easier gsfonts-8.11_4 Fonts used by GNU Ghostscript (or X) gstreamer-0.10.14 Development framework for creating media applications gstreamer-ffmpeg-0.10.2_1 GStreamer plug-in for manipulating MPEG video streams gstreamer-plugins-0.10.14,3 GStreamer written collection of plugins handling several me gstreamer-plugins-a52dec-0.10.6_2,3 Gstreamer ATSC A/52 stream aka AC-3 (dvd audio) plugin gstreamer-plugins-bad-0.10.5_2,3 Bad gstreamer-plugins gstreamer-plugins-core-0.10_9 Core set of typical audio and video gstreamer-plugins gstreamer-plugins-dts-0.10.5_3,3 Gstreamer dts plugin gstreamer-plugins-dvd-0.10.6_1,3 Gstreamer dvd plugin set gstreamer-plugins-gconf-0.10.6_4,3 Gstreamer gconf plugin gstreamer-plugins-gnomevfs-0.10.14_2,3 Gstreamer gnomevfs plugin gstreamer-plugins-good-0.10.6,3 Good gstreamer-plugins gstreamer-plugins-hal-0.10.6_1,3 Gstreamer hal plugin gstreamer-plugins-libpng-0.10.6_2,3 Gstreamer png plugin gstreamer-plugins-mad-0.10.6_3,3 Gstreamer mp3 decoder plugin gstreamer-plugins-mp3-0.10.0 Gstreamer Plugins Mp3 decoder meta-port gstreamer-plugins-mpeg2dec-0.10.6_2,3 Gstreamer mpeg decode plugin gstreamer-plugins-ogg-0.10.14_2,3 Gstreamer Ogg bitstream plugin gstreamer-plugins-pango-0.10.14_2,3 Gstreamer pango textoverlay plugin gstreamer-plugins-theora-0.10.14_3,3 Gstreamer theora plugin gstreamer-plugins-ugly-0.10.6,3 Ugly gstreamer-plugins gstreamer-plugins-vorbis-0.10.14_3,3 Gstreamer vorbis encoder/decoder plugin gstreamer-plugins-xvid-0.10.5_1,3 Gstreamer xvid plugin gtar-1.18_1 GNU version of the traditional tar archiver gtk-1.2.10_18 Gimp Toolkit for X11 GUI (previous stable version) gtk-2.10.14 Gimp Toolkit for X11 GUI (current stable version) gtk-engines2-2.10.2 Theme engine for the gtk+-2.0 toolkit gtkglarea-1.99.0_10 An OpenGL widget for the GTK+2 GUI toolkit gtkspell-2.0.11_5 A GTK+ 2 spell checking component hal-0.5.8.20070909 Hardware Abstraction Layer for simplifying device access help2man-1.36.4_1 Automatically generating simple manual pages from program o hicolor-icon-theme-0.10_2 A high-color icon theme shell from the FreeDesktop project hidentd-0.4 Simple and secure ident (RFC1413) server htdig-3.2.0.b6_2 A www indexing and searching system html-4.01_2 All W3C published SGML DTDs for HTML html2text-1.3.2a Converts HTML documents into plain text iceauth-1.0.1 ICE authority file utility for X ico-1.0.1 Displays a wire-frame rotating plyhedron icon-naming-utils-0.8.2 Utilities of the Tango project icu-3.6 International Components for Unicode (from IBM) ilbc-r3951 Internet Low Bit Rate codec (RFC3951) imake-1.0.2_4,1 Imake and other utilities from X.Org imlib-1.9.15_5 A graphic library for enlightenment package inputproto-1.3.2 Input extension headers intltool-0.36.1 Tools to internationalize various kinds of data files iso-codes-1.4 Lists of the country, language and currency iso names iso8879-1986_2 Character entity sets from ISO 8879:1986 (SGML) jackit-0.103.0 A low-latency audio server jad-1.5.8c Jad, a Java decompiler jadetex-3.13_2 A TeX backend for Jade, for typesetting SGML documents jasper-1.900.1_6 An implementation of the codec specified in the JPEG-2000 s javavmwrapper-2.3 Wrapper script for various Java Virtual Machines jbigkit-1.6 Lossless compression for bi-level images such as scanned pa jpeg-6b_4 IJG's jpeg compression utilities k3b-1.0.3 A CD/DVD recording GUI for KDE kbproto-1.0.3 KB extension headers kde-icons-GorillaSVG-1.4 KDE Gorilla SVG iconset kde-icons-IcOsX-0.7 KDE IcOsX iconset kde-icons-amaranth-0.8 KDE smooth iconset kde-icons-amaranth-althaea-0.5 KDE iconset like Crystal SVG, but simpler and with more sha kde-icons-cezanne-0.3b KDE Cezanne iconset kde-icons-gartoon-blue-svg-1.3 KDE Gartoon Blue SVG iconset kde-icons-gartoon-svg-1.3 KDE Gartoon SVG iconset kde-icons-graphite-rade8-1.03 KDE Mac OS X like iconset, most from rad-e8 design kde-icons-kool-gorilla-1.3.5 KDE Kool Gorilla iconset kde-icons-krystaline-1.1.6 KDE Krystaline iconset kde-icons-lime-rade8-1.01 KDE Mac OS X like iconset, most from rad-e8 design kde-icons-lush-0.1.0 KDE Lush complete iconset kde-icons-marbles-translucent-0.1.3 KDE Marbles Translucent iconset kde-icons-nuvola-1.0_1 KDE Nuvola iconset, SVG evolution of SKY kde-icons-realistic-0.10 KDE Realistic complete photo-based iconset kde-icons-sky-0.7.3 KDE SKY iconset kde-icons-steel-1.2.5 KDE iconset comprised of Steel/Silver icons with shadows kde-icons-umicons-2.0 KDE Umicons iconset kde-xdg-env-1.0_3,1 Script which hooks into startkde and helps KDE pick up XDG kdeaddons-3.5.7 Additional plugins and scripts for some KDE applications kdeaddons-atlantikdesigner-3.5.7 Editor for Atlantik kdeaddons-kaddressbook-plugins-3.5.7 Plugins for KAdressbook kdeaddons-kate-plugins-3.5.7 Additonal plugins and features for kate kdeaddons-kfile-plugins-3.5.7 Plugins for Konqueror (in filemanager mode) kdeaddons-kicker-applets-3.5.7 Additional applets for Kicker kdeaddons-knewsticker-scripts-3.5.7 Additional scripts for KNewsTicker kdeaddons-konq-plugins-3.5.7 Additonal plugins and features for Konqueror kdeaddons-ksig-3.5.7 Signature randomiser, available standalone or as a plugin w kdeaddons-noatun-plugins-3.5.7 Various plugins for Noatun kdeaddons-renamedlg-plugins-3.5.7 Plugins for Konqueror's rename dialog kdeartwork-3.5.7 Additional themes, sounds, wallpapers and window styles for kdebase-3.5.7_2 Basic applications for the KDE system kdebase-kompmgr-3.5.7 Utility needed to enable XComposite support in KDE kdegames-3.5.7 Games for the KDE integrated X11 desktop kdegraphics-3.5.7_1 Graphics utilities for the KDE3 integrated X11 desktop kdegraphics-kamera-3.5.7 Digital camera support for KDE kdegraphics-kuickshow-3.5.7 KDE image viewer kdehier-1.0_11 Utility port which installs a hierarchy of shared KDE direc kdelibs-3.5.7_1 Base set of libraries needed by KDE programs kdemultimedia-3.5.7_1 Multimedia utilities for the KDE integrated X11 desktop kdemultimedia-mpeglib_artsplug-3.5.7_1 Legacy KDE audio backend kdemultimedia-xine_artsplugin-3.5.7 Xine-based multimedia backend for KDE kdenetwork-3.5.7 Network-related programs and modules for KDE kdenetwork-kopete-0.12.5 KDE multi-protocol instant messenger (IM) kdepim-3.5.7 Personal Information Management tools for KDE kdetoys-3.5.7 Small applications for KDE kdeutils-3.5.7 Utilities for the KDE integrated X11 desktop kmplayer-0.9.3_2,2 KDE frontend to mplayer koffice-1.6.3_2,2 Office Suite for KDE3 ktorrent-2.1.4_1 BitTorrent client for KDE lame-3.97_1 ISO code based fast MP3 encoder kit latex-cjk-4.7.0_1 A LaTeX2e macro package which enables the use of CJK script lcms-1.17,1 Light Color Management System -- a color management library libFS-1.0.0 The FS library libGL-7.0.1 OpenGL library that renders using GLX or DRI libGLU-7.0.1 OpenGL utility library libICE-1.0.3,1 Inter Client Exchange library for X11 libIDL-0.8.8 A library for creating trees of CORBA IDL files libSM-1.0.3,1 Session Management library for X11 libX11-1.1.2_1,1 X11 library libXScrnSaver-1.1.2 The XScrnSaver library libXTrap-1.0.0 The XTrap library libXau-1.0.3_2 Authentication Protocol library for X11 libXaw-1.0.3,1 X Athena Widgets library libXcomposite-0.3.2,1 X Composite extension library libXcursor-1.1.8_1 X client-side cursor loading library libXdamage-1.1.1 X Damage extension library libXdmcp-1.0.2 X Display Manager Control Protocol library libXevie-1.0.2 The Xevie library libXext-1.0.3,1 X11 Extension library libXfixes-4.0.3 X Fixes extension library libXfont-1.2.8,1 X font libary libXfontcache-1.0.4 The Xfontcache library libXft-2.1.12 A client-sided font API for X applications libXi-1.0.2,1 X Input extension library libXinerama-1.0.2,1 X11 Xinerama library libXmu-1.0.3,1 X Miscellaneous Utilities libraries libXp-1.0.0,1 X print library libXpm-3.5.6_1 X Pixmap library libXprintAppUtil-1.0.1 The XprintAppUtil library libXprintUtil-1.0.1 The XprintUtil library libXrandr-1.2.1 X Resize and Rotate extension library libXrender-0.9.2 X Render extension library libXres-1.0.3_1 X Resource usage library libXt-1.0.5 X Toolkit library libXtst-1.0.2 X Test extension libXv-1.0.3,1 X Video Extension library libXvMC-1.0.4 X Video Extension Motion Compensation library libXxf86dga-1.0.1 X DGA Extension libXxf86misc-1.0.1 X XF86-Misc Extension libXxf86vm-1.0.1 X Vidmode Extension liba52-0.7.4_1 A free library for decoding ATSC A/52 streams, aka AC-3 libao-0.8.8 Portable audio output library libart_lgpl-2.3.19,1 Library for high-performance 2D graphics libassuan-1.0.3 IPC library used by GnuPG and gpgme libaudiofile-0.2.6 A sound library for SGI audio file libbonobo-2.18.0_1 A component and compound document system for GNOME2 libbonoboui-2.18.0_1 GUI frontend to the libbonobo component of GNOME 2 libcddb-1.3.0 A library to access data on a CDDB server libcdio-0.77_2 Compact Disc Input and Control Library libcroco-0.6.1 CSS2 parsing library libdaemon-0.12 Lightweight C library that eases the writing of UNIX daemon libdca-0.0.5 Free DTS Coherent Acoustics decoder libdmx-1.0.2 DMX extension library libdrm-2.3.0 Userspace interface to kernel Direct Rendering Module servi libdvdcss-1.2.9_2 Portable abstraction library for DVD decryption libdvdnav-0.1.10_2 The library for the xine-dvdnav plugin libdvdread-0.9.7_2 This is needed by ogle, which is a DVD player that supports libexif-0.6.15 Library to read digital camera file meta-data libfame-0.9.1_2 A video encoding library libfontenc-1.0.4 The fontenc Library libfpx-1.2.0.12 Library routines for working with Flashpix images libgcrypt-1.2.4_1 "General purpose crypto library based on code used in GnuPG libggi-2.2.2_1,1 A flexible drawing library libgii-1.0.2_1 GGI API for input sources libglade2-2.6.2 GNOME glade library libglut-7.0.1 OpenGL utility toolkit libgmp-4.2.1_2 A free library for arbitrary precision arithmetic libgnome-2.18.0_1 Libraries for GNOME, a GNU desktop environment libgnomecanvas-2.14.0_3 A graphics library for GNOME libgnomeui-2.18.1_1 Libraries for the GNOME GUI, a GNU desktop environment libgpg-error-1.5 Common error values for all GnuPG components libgphoto2-2.4.0 A universal digital camera picture control tool libgsf-1.14.7 An extensible i/o abstraction for dealing with structured f libiconv-1.9.2_2 A character set conversion library libid3tag-0.15.1b ID3 tags library (part of MAD project) libidn-0.6.14 Internationalized Domain Names command line tool libksba-1.0.1_1 KSBA is an X.509 Library libltdl-1.5.22_2 System independent dlopen wrapper libmad-0.15.1b_2 Libmad library (part of MAD project) libmng-1.0.9 Multiple-image Network Graphics (MNG) reference library libmodplug-0.8.4 ModPlug mod-like music shared libraries libmpcdec-1.2.6 High quality audio compression format libmpeg2-0.4.1_1 A free library for decoding mpeg-2 and mpeg-1 video streams libmusicbrainz-2.1.5 2nd generation incarnation of the CD Index - audio metadata libogg-1.1.3,3 Ogg bitstream library liboil-0.3.12 Library of optimized inner loops liboldX-1.0.1 Old X library libopensync-0.22_1 Freedesktop synchronization framework libpaper-1.1.21_3 A library providing routines for paper size management librsvg2-2.18.2 Library for parsing and rendering SVG vector-graphic files libsamplerate-0.1.2_2 Secret Rabbit Code: a Sample Rate Converter for audio libsndfile-1.0.17_1 Reading and writing files containing sampled sound (like WA libthai-0.1.5_2 Thai language support library libtheora-1.0.a7_1 Theora video codec for the Ogg multimedia streaming system libtool-1.5.22_4 Generic shared library support script libublio-20070103 User space caching library libungif-4.1.4_5 Tools and library routines for working with GIF images libusb-0.1.12_1 Library giving userland programs access to USB devices libvolume_id-0.75.0_1 Library to provide file system type information libvorbis-1.2.0,3 Audio compression codec library libwmf-0.2.8.4_2 Tools and library for converting Microsoft WMF (windows met libwnck-2.18.3 Library used for writing pagers and taskslists libwpd-0.8.9_1 Tools for importing and exporting WordPerfect(tm) documents libwww-5.4.0_4 The W3C Reference Library libxine-1.1.7_1 Libraries for xine multimedia player libxkbfile-1.0.4 XKB file library libxkbui-1.0.2 The xkbui library libxml2-2.6.30 XML parser library for GNOME libxslt-1.1.22 The XSLT C library for GNOME linc-1.0.3_6 A library for writing networked servers & clients links-0.98,1 Lynx-like text WWW browser linux-atk-1.9.1 Accessibility Toolkit, Linux/i386 binary linux-expat-1.95.8 Linux/i386 binary port of Expat XML-parsing library linux-flashplugin-9.0r48 Adobe Flash Player NPAPI Plugin linux-fontconfig-2.2.3_7 Linux/i386 binary of Fontconfig linux-glib2-2.6.6 Version 2.X Linux/i386 binary port of GLib linux-gtk2-2.6.10 GTK+ library, version 2.X, Linux binary linux-jpeg-6b.34 RPM of the JPEG lib linux-openssl-0.9.7f SSL and crypto library (Linux Version) linux-pango-1.8.1 Linux pango binary linux-png-1.2.8_2 RPM of the PNG lib linux-realplayer-10.0.8.805.20060718_1 Linux RealPlayer 10 from RealNetworks linux-tiff-3.7.1 TIFF library, Linux/i386 binary linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries linux_base-fc-4_10 Base set of packages needed in Linux mode (for i386/amd64) linuxdoc-1.1_1 The Linuxdoc SGML DTD listres-1.0.1 List resources in widgets liveMedia-2007.07.25,1 LIVE.COM Streaming Media localedata-5.4 Legacy locale data for FreeBSD 6+ luit-1.0.2_2 Locale and ISO 2022 support for Unicode terminals lynx-2.8.6.5_1,1 A non-graphical, text-based World-Wide Web client lzo-1.08_2,1 Portable speedy, lossless data compression library m4-1.4.9 GNU m4 maildrop-2.0.4 Mail delivery agent (MDA) with filtering abilities makedepend-1.0.1,1 A dependency generator for makefiles maven2-2.0.7 Java project management tool, 2.0 branch mime-support-3.39.1 MIME Media Types list mkcomposecache-1.2_1 Program to create Compose cache files mkfontdir-1.0.3 Create an index of X font files in a directory mkfontscale-1.0.3 Creates an index of scalable font files for X mldonkey-2.9.1 A OCAML client for multiple peer-to-peer networks mmencode-2.7 Translate to and from mail-oriented encoding formats mpeg4ip-libmp4v2-1.5.0.1 Mpeg-4 library and tools from mpeg4ip mplayer-0.99.10_13 High performance media player supporting many formats mplayer-skins-1.1.2_6 Skins for MPlayer's Graphical User Interface (GUI) mutt-devel-1.5.16_2 The Mongrel of Mail User Agents (development version) mysql-client-5.0.45 Multithreaded SQL database (client) nas-1.8_1 Network Audio System nasm-0.98.39,1 General-purpose multi-platform x86 assembler nautilus-2.18.3 File manager for the GNOME desktop nautilus-cd-burner-2.18.2 CD burner view for Nautilus ncurses-5.6_1 Library for terminal-independent, full-screen output neon-0.26.4 An HTTP and WebDAV client library for Unix systems net-snmp-5.3.1_3 An extendable SNMP implementation netpbm-10.26.44 A toolkit for conversion of images between different format normalizemime-1.18.20070320_1 A mime normalizer to be used as a preprocessor for email cl nspluginwrapper-0.9.91.5 A compatibility plugin for Netscape 4 (NPAPI) plugins nspr-4.6.7 A platform-neutral API for system level and libc like funct nss-3.11.7 Libraries to support development of security-enabled applic nvidia-driver-100.14.11 NVidia graphics card binary drivers for hardware OpenGL ren ocaml-3.09.3_1 The Objective Caml compiler and programming environment ocaml-lablgl-1.02_1 OpenGL interface for Objective Caml ocaml-lablgtk2-2.6.0_4 An Objective Caml interface to GTK+ 2.x oclock-1.0.1 Round clock application for X open-motif-2.2.3_5 Motif X11 Toolkit (industry standard GUI (IEEE 1295)) openal-20060211_6 A 3D positional spatialized sound library openjade-1.3.3p1 Object-oriented SGML/XML parser toolkit and DSSSL engine openldap-client-2.3.38 Open source LDAP client implementation openslp-1.2.1_2 Open-source implementation of the Service Location Protocol openssh-portable-4.7.p1,1 The portable version of OpenBSD's OpenSSH opera-9.23.20070809 A blazingly fast, full-featured, standards-compliant browse opera-linuxplugins-9.21.20070510_1 Linux plugin support for the native Opera browser ortp-0.13.0 A Real-time Transport Protocol (RTP) stack p5-Authen-SASL-2.10_1 Perl5 module for SASL authentication p5-Compress-Raw-Zlib-2.006 Low-Level Interface to zlib compression library p5-Compress-Zlib-2.006 Perl5 interface to zlib compression library p5-Digest-1.15 Modules that calculate message digests p5-Digest-HMAC-1.01 Perl5 interface to HMAC Message-Digest Algorithms p5-Digest-MD5-2.36 Perl5 interface to the MD5 algorithm p5-Digest-SHA1-2.11 Perl interface to the SHA-1 Algorithm p5-Font-AFM-1.19 An interface to Adobe font metrics files p5-GSSAPI-0.24 Perl extension providing access to the GSSAPIv2 library p5-HTML-Format-2.04 A module to format HTML to text or PS p5-HTML-Parser-3.56 Perl5 module for parsing HTML documents p5-HTML-Tagset-3.10 Some useful data table in parsing HTML p5-HTML-Tree-3.23 A collection of modules to manupulate HTML syntax trees p5-IO-Compress-Base-2.006 Base Class for IO::Uncompress modules p5-IO-Compress-Zlib-2.006 Perl5 interface for reading and writing of (g)zip files p5-MIME-Base64-3.07 Perl5 module for Base64 and Quoted-Printable encodings p5-Net-1.22,1 Perl5 modules to access and use network protocols p5-Test-Harness-2.64 Run perl standard test scripts with statistics p5-Test-Simple-0.70 Basic utilities for writing tests in perl p5-Time-HiRes-1.9707,1 A perl5 module implementing High resolution time, sleep, an p5-URI-1.35 Perl5 interface to Uniform Resource Identifier (URI) refere p5-XML-NamespaceSupport-1.09_1 A simple generic namespace support class p5-XML-Parser-2.34_2 Perl extension interface to James Clark's XML parser, expat p5-XML-SAX-0.16 Simple API for XML p5-XML-SAX-Expat-0.39 Simple API for XML p5-XML-Simple-2.18 Trivial API for reading and writing XML (esp config files) p5-gettext-1.05_1 Message handling functions p5-libwww-5.805 Perl5 library for WWW access p5-type1inst-0.6.1_4 A script that helps install Postscript fonts in X Window Sy p7zip-4.53_1 File archiver with high compression ratio pango-1.16.5 An open-source framework for the layout and rendering of i1 pccts-1.33.33 The Purdue Compiler Construction Tool Set pciids-20070906 Database of all known ID's used in PCI devices pcre-7.3 Perl Compatible Regular Expressions library pdksh-5.2.14p2_2 The Public Domain Korn Shell perl-threaded-5.8.8 Practical Extraction and Report Language pilot-link-0.12.2,1 Suite of tools used to connect and sync your Palm handled pinentry-qt-0.7.2_6 QT version of the gnupg password dialog pkg-config-0.22 A utility to retrieve information about installed libraries png-1.2.18 Library for manipulating PNG images policykit-0.1.20060514_4 Framework for controlling access to system-wide components polipo-1.0.2 A small and fast caching web proxy polypaudio-0.7_4 Sound server for UNIX poppler-0.6 A PDF rendering library poppler-data-0.1 Poppler encoding data poppler-gtk-0.6 Gtk bindings to poppler poppler-qt-0.6 Qt bindings to poppler popt-1.7_4 A getopt(3) like library with a number of enhancements, fro portaudio-18.1_2 Portable cross-platform Audio API portconf-1.2 A universal tool to set specific port knobs portupgrade-devel-2.3.1 FreeBSD ports/packages administration and management tool s postgresql-client-8.2.4 PostgreSQL database (client) postgresql-libpqxx-2.6.9 A new C++ interface for PostgreSQL postgresql-server-8.2.4_1 The most advanced open-source database available anywhere printproto-1.0.3 Print extension headers procmail-3.22_6 A local mail delivery agent pstree-2.31 List processes as a tree pth-2.0.7 GNU Portable Threads py25-libxml2-2.6.30 Python interface for XML parser library for GNOME py25-xml-0.8.4 PyXML: Python XML library enhancements python25-2.5.1 An interpreted object-oriented programming language qca-tls-1.0_2 SSL/TLS plugin for Qt qmail-1.03_5 A secure, reliable, efficient, simple, and fast MTA qmake-3.3.8_1 The build utility of the Qt project qt-copy-3.3.8_5 Multiplatform C++ application framework (+ KDE patches) randrproto-1.2.1 Randr extension headers recordproto-1.13.2 RECORD extension headers renderproto-0.9.2 RenderProto protocol headers resourceproto-1.0.2 Resource extension headers rgb-1.0.1 Uncompile an rgb corl-name database rpm-3.0.6_13 The Red Hat Package Manager rpm2cpio-1.2_2 Convert .rpm files for extraction with /usr/bin/cpio, needs rstart-1.0.2 Sample implementation of a Remote Start client rsync-2.6.9_1 A network file distribution/synchronization utility rtc-2004.02.24.1_8 Kernel module which provides /dev/rtc device support ruby+pthreads+oniguruma-1.8.6_2,1 An object-oriented interpreted scripting language ruby18-bdb42-0.6.2 Ruby interface to Sleepycat's Berkeley DB revision 2 or lat ruby18-deplate-0.8 Ruby tool for converting wiki-like markup samba-3.0.25a_1,1 A free SMB and CIFS client and server for UNIX samba-libsmbclient-3.0.25a_1 Shared libs from the samba package scr2png-1.2_1 Converts the output of "vidcontrol -p" to PNG scr2txt-1.2 Converts the output of "vidcontrol -p" to text screen-4.0.3 A multi-screen window manager scripts-1.0.1 Various X related scripts scrnsaverproto-1.1.0 ScrnSaver extension headers scrollkeeper-0.3.14_8,1 An Open Document Cataloging Project sdl-1.2.11_1,2 Cross-platform multi-media development API sdocbook-xml-1.1,1 "Simplified" DocBook XML DTD serialmail-0.75_2 Tools for passing mail across serial links sessreg-1.0.2 Manage utmp/wtmp entries for non-init X clients setxkbmap-1.0.3 Set the keyboard using the X Keyboard Extension shared-mime-info-0.22 A MIME type database from the FreeDesktop project showfont-1.0.1 Font dumper for the X font server smpeg-0.4.4_7 A free MPEG1 video player library with sound support smproxy-1.0.2 Session Manager Proxy speex-1.2.b2,1 An open-source patent-free voice codec sqlite3-3.4.1 An SQL database engine in a C library w/ Tcl wrapper startup-notification-0.9_1 Library that supports startup notification spec from freede subversion-1.4.4_1 Version control system sudo-1.6.9.4 Allow others to run commands as root svgalib-1.4.3_5 A low level console graphics library swig-1.3.31_1 Simplified Wrapper and Interface Generator t1lib-5.1.1_2,1 A Type 1 Rasterizer Library for UNIX/X11 t1utils-1.32 Six utilities for manipulating t1 fonts taglib-1.4_2 Library for manipulating ID3 tags and Ogg comments tcl-8.4.15_2,1 Tool Command Language teTeX-base-3.0_12 Thomas Esser's distribution of TeX & friends (binaries) teTeX-texmf-3.0_5 Thomas Esser's distribution of TeX & friends (texmf tree) tex-texmflocal-1.9 Meta-port that creates a site-local $TEXMF directory texi2html-1.76_1,1 Texinfo to HTML converter tidy-20000804_2 Fixes and tidies up HTML files tiff-3.8.2_1 Tools and library routines for working with TIFF images tightvnc-1.3.8_2 Enhanced version of VNC tk-8.4.15_3,2 Graphical toolkit for TCL tnef-1.4.3 Unpack data in MS Outlook TNEF format totem-2.18.2 A gstreamer-based video player for the GNOME 2 Desktop tracker-0.6.1_1 Object database, tag/metadata database, search tool and ind trapproto-3.4.3 DEC-XTRAP extension headers ttf2pt1-3.4.4_2 True Type Font to Postscript Type 1 Converter twm-1.0.3_3 Tab Window Manager for the X Window System ucspi-ssl-0.70_1 UCSPI tools for building SSL client-server applications ucspi-tcp-0.88_2 Command-line tools for building TCP client-server applicati unzip-5.52_3 List, test and extract compressed files in a ZIP archive usendmail-0.1.6_1 A replacement for qmail's sendmail drop-in v4l_compat-1.0.20060801 Video4Linux compatibility header vcdimager-0.7.23_3 GNU VCDImager/VCDRip -- The GNU VideoCD Image Maker/Ripping videoproto-2.2.2 Video extension headers viewres-1.0.1 Graphical class browser for Xt wget-1.10.2_1 Retrieve files from the Net via HTTP and FTP win32-codecs-3.1.0.r1,1 Huge compilation of Win32 binary video codecs wv-1.2.4_1 A library and executables to access Microsoft Word files wv2-0.2.3_1 A library providing routines to access Microsoft Word files x11perf-1.4.1 X11 server performance test program x264-0.0.20070708 Multimedia library and tool for encoding H.264/AVC video st xanim-2.92.0_2 Play most popular animation formats and show pictures xauth-1.0.2 X authority file utility xbiff-1.0.1 Mailbox flag for X xbindkeys-1.8.2_1 Allows you to launch shell commands under X with your keybo xbitmaps-1.0.1 X.Org bitmaps data xcalc-1.0.1 Scientific calculator for X xclick-0.1_1 Generates X11 mouse button click events xclipboard-1.0.1 X clipboard client xclock-1.0.2 Analog and digital clock for X xcmiscproto-1.1.2 XCMisc extension headers xcmsdb-1.0.1 Device Color Characterization utility for X xconsole-1.0.2 Monitor system console messages with X xcursor-themes-1.0.1_1 X.org cursors themes xcursorgen-1.0.1 Create an X cursor file from a collection of PNG images xdbedizzy-1.0.2 Demo of DBE creating a double buffered spinning scene xditview-1.0.1 Display ditroff output xdm-1.1.4_3 X.Org X display manager xdpyinfo-1.0.2 Display information utility for X xdriinfo-1.0.1_1 Query configuration information of DRI drivers xedit-1.0.2 Simple text editor for X xev-1.0.2 Print contents of X events xextproto-7.0.2 XExt extension headers xeyes-1.0.1 A follow the mouse X demo xf86-input-keyboard-1.1.1 X.Org keyboard input driver xf86-input-mouse-1.1.2 X.Org mouse input driver xf86-video-ati-6.6.3_2 X.Org ati display driver xf86-video-fbdev-0.3.1 X.Org fbdev display driver xf86-video-mga-1.4.6.1_1 X.Org mga display driver xf86-video-nv-2.1.3 X.Org nv display driver xf86-video-vesa-1.3.0 X.Org vesa display driver xf86-video-vga-4.1.0 X.Org vga display driver xf86bigfontproto-1.1.2 XFree86-Bigfont extension headers xf86dga-1.0.2 Test program for the XFree86-DGA extension xf86dgaproto-2.0.2 XFree86-DGA extension headers xf86driproto-2.0.3 XFree86-DRI extension headers xf86miscproto-0.9.2 XFree86-Misc extension headers xf86rushproto-1.1.2 XFree86-Rush extension headers xf86vidmodeproto-2.2.2 XFree86-VidModeExtension extension headers xfd-1.0.1 Display all characters in an X font xfindproxy-1.0.1 Locate available proxy services xfontsel-1.0.2 Point and click selection of X11 font names xfs-1.0.4_4,1 X.Org font server xfsinfo-1.0.1 X font server information utility xfwp-1.0.1 X firewall proxy xgamma-1.0.1 Gamma correction through the X server. xgc-1.0.1 X graphics demo xhost-1.0.1 Server access control program for X xhtml-1.0.20020801_4 W3C's XHTML DTD xine-0.99.5 An X11 multimedia player xineramaproto-1.1.2 Xinerama extension headers xinit-1.0.4_1 X Window System initializer xkbcomp-1.0.3 Compile XKB keyboard description xkbevd-1.0.2 XKB event daemon xkbprint-1.0.1 Utility for printing an XKB keyboard description xkbutils-1.0.1 XKB utility demos xkeyboard-config-1.0_1 X Keyboard Configuration Database xkill-1.0.1 Utility for killing a client by its X resource xload-1.0.2 System load average display for X xlogo-1.0.1 Displays the X Window System logo. xlsatoms-1.0.1 List interned atoms defined on a server xlsclients-1.0.1 List client applications running on a display xlsfonts-1.0.2 Server font list displayer for X xmag-1.0.1 X application for screen magnifying xman-1.0.2 Manual page display program for X xmessage-1.0.1 Display message or query in a X window xmh-1.0.1 Send and read mail with an X interface to MH xmlcatmgr-2.2 SGML and XML catalog manager xmlcharent-0.3_2 XML character entities xmodmap-1.0.2 Utility for modifying keymaps and pointer button mappings i xmore-1.0.1 Plain text display program for X xorg-7.2 X.Org complete distribution metaport xorg-apps-7.2 X.org apps meta-port xorg-cf-files-1.0.2_2 X.org cf files for use with imake builds xorg-docs-1.3,1 X.org documentation files xorg-drivers-7.2_2 X.org drivers meta-port xorg-fonts-100dpi-7.2 X.Org 100dpi bitmap fonts xorg-fonts-7.2 X.org fonts meta-port xorg-fonts-75dpi-7.2 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-7.2 X.Org Cyrillic bitmap fonts xorg-fonts-miscbitmaps-7.2 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-7.2 X.Org TrueType fonts xorg-fonts-type1-7.2 X.Org Type1 fonts xorg-libraries-7.2_2 X.org libraries meta-port xorg-protos-7.2 X.org protos meta-port xorg-server-1.2.0_2,1 X.Org X server and related programs xphelloworld-1.0.1 Sends a test page to an Xprint printer xplsprinters-1.0.1 Shows a list of Xprint printers xpr-1.0.2 Utility for printing an X window dump xprehashprinterlist-1.0.1 Recomputes the list of available printers. xprop-1.0.2 Property displayer for X xproto-7.0.10 X11 protocol headers xproxymanagementprotocol-1.0.2 X Proxy Management Protocol headers xrandr-1.2.0 Primitive command line interface to the RandR extension xrdb-1.0.3 X server resource database utility xrefresh-1.0.2 Refresh all or part of an X screen xrx-1.0.1 RX helper program xset-1.0.2 User preference utility for X xsetmode-1.0.0 Set the mode for an X Input Device xsetpointer-1.0.0 Set an X Input device as the main pointer xsetroot-1.0.1 root window parameter setting utility for X xsm-1.0.1 X Session Manager xstdcmap-1.0.1 X standard colormap utility xterm-229 Terminal emulator for the X Window System xtrans-1.0.3 Abstract network code for X xtrap-1.0.2 XTrap sample clients for X xulrunner-1.8.0.4_7 Mozilla runtime package that can be used to bootstrap XUL+X xvid-1.1.3,1 An opensource MPEG-4 codec, based on OpenDivx xvidtune-1.0.1 Video mode tuner for X xvinfo-1.0.1 Print out X-Video extension adaptor information xvkbd-2.6_3 A virtual keyboard for X applications xwd-1.0.1 Dump an image of an X window xwininfo-1.0.2 Window information utility for X xwud-1.0.1 Image displayer for X zh-arphicttf-2.11_2 Four Chinese Big5/GB TrueType fonts made by Arphic Technolo zh-docproj-0.1.20060303_2 Supportive tools for Chinese docproj build zh-ttf2pt1-3.4.0 True Type Font to Postscript Type 1 Converter with chinese zh-ttfm-0.9.5_2 A Big5/GB enhanced TrueType Font Manager zip-2.32 Create/update ZIP files compatible with pkzip --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uname.txt" FreeBSD exxodus.fedaykin.here 7.0-CURRENT FreeBSD 7.0-CURRENT #9: Thu Sep 13 22:46:14 BRT 2007 lioux@exxodus:/usr/src/sys/i386/compile/LIOUX i386 --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 03:12:39 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE0CA16A469; Fri, 14 Sep 2007 03:12:39 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 1F00213C491; Fri, 14 Sep 2007 03:12:38 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l8E3CUVe022401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 07:12:48 +0400 Message-ID: <46E9FC0C.70607@FreeBSD.org> Date: Thu, 13 Sep 2007 23:12:12 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> In-Reply-To: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Shteryana Shopova , "Constantine A. Murenin" Subject: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 03:12:39 -0000 Dear freebsd-{arch,current,hackers}@, On this 256th day of 2007, it is my great pleasure to announce the completion of my GSoC2007 project on porting the sysctl hardware sensors framework from OpenBSD to FreeBSD. All of the things that were planned to be ported from OpenBSD base system to FreeBSD have now been ported. The userland part of the framework is entirely source-code compatible with OpenBSD. For example, you can take OpenBSD's stock sensorsd(8), and it'll compile and work on FreeBSD with no modifications. The framework is quite self-contained, so I think it is a safe bet to at least try to get it into the tree even at this point, when the code freeze is taking place in preparation for RELENG_7 branching. Therefore, I hereby request that this patch be considered for immediate inclusion into FreeBSD's main CVS repository. The complete CVS patch is available from: http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz For backup purposes, a copy of this CVS patch is also available in my perforce branch, although it has tainted $P4$ tags in individual files, so use perforce as a last resort: http://p4web.freebsd.org//depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch Exact details on how to apply and test the patch are available in my LiveJournal, along with certain other comments: http://cnst.livejournal.com/38421.html#directions If you have an Intel Core 2 processor, or a Winbond or ITE Tech Super I/O chip on your board, then please test and report back on how your tests went. Best regards, Constantine Aleksandrovich Murenin, Google Summer of Code 2007 Student @ The FreeBSD Project. ;) On 13/09/2007 19:02, Constantine A. Murenin wrote: > http://perforce.freebsd.org/chv.cgi?CH=126384 > > Change 126384 by cnst@dale on 2007/09/13 23:01:55 > > On this 256th day of 2007, it is my great pleasure to > present a feature-complete port of the hardware sensors > framework from OpenBSD to FreeBSD. > > Below is a complete `cvs diff` of cnst-sensors GSoC2007 > project as of 2007-256. > > It includes the following components, listed below in > the very same order as they are appearing in this diff: > > * sample configuration file for sensorsd > * rc(8) script and glue code for sensorsd(8) > * sysctl(3) doc fixes for CTL_HW tree > * sysctl(3) documentation for hardware sensors > * sysctl(8) documentation for hardware sensors > * assorted KNF and bug-fixes for sysctl(8) > * support for the sensor structure for sysctl(8) > * coretemp(4) documentation > * it(4) documentation > * lm(4) documentation > * rc.conf(5) documentation for starting sensorsd(8) > * sensor_attach(9) et al documentation > * coretemp(4) conversion to the hw.sensors framework > * it(4) isa driver ported from OpenBSD > * lm(4) isa driver ported from OpenBSD > * /sys/kern/kern_sensors.c > o sensor_attach(9) API for drivers to register ksensors > o sensor_task_register(9) API for the update task > o sysctl(3) glue code > o hw.sensors shadow tree for sysctl(8) internal magic > * assorted KNF and bug-fixes for /sys/kern/kern_sysctl.c > * it(4) module for testing sensor_attach/detach et al > * lm(4) module for testing sensor_attach/detach et al > * > * assorted bug-fixes and HW_SENSORS definition for > * sensors display for systat(1), including all documentation > * sensorsd(8) and all applicable documentation > > The userland part of the framework is entirely source-code > compatible with OpenBSD 4.1, 4.2 and -current as of today. > > All sensor readings can be viewed with `sysctl hw.sensors`, > monitored in semi-realtime with `systat -sensors` and also > logged with `sensorsd`. Third-party tools, for example a > plug-in for nagios, are also available. A separate patch > for ports/sysutils/symon will be provided upon request. > > Submitted by: cnst@FreeBSD.org (Constantine A. Murenin) > Obtained from: generated by sensors.cvsdiff.sh from > //depot/projects/soc2007/cnst-sensors/ > Sponsored by: Google Summer of Code 2007 > > > Obtained from: http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz > > Details at: http://cnst.livejournal.com/38421.html > > Affected files ... > > .. //depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch#1 add > > Differences ... > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 03:53:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8133A16A420 for ; Fri, 14 Sep 2007 03:53:57 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53901.mail.re2.yahoo.com (web53901.mail.re2.yahoo.com [206.190.36.211]) by mx1.freebsd.org (Postfix) with SMTP id 2B61613C483 for ; Fri, 14 Sep 2007 03:53:56 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 5849 invoked by uid 60001); 14 Sep 2007 03:53:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rSxCPqZm67+6q+OBq4l3zqMzzpUlH4hkMIOzCLIlqM6Fi94WT/rW0YxUhJrR16bgObgCU1bE7pRf8IVbEXJmEyIeYesN7lTvbFqZPw1VNQmONXyshRJDkFteUuLgvLRkSVsmIT9swWDyCCi1OkBrBMgTwRwUoaDGmjX+Xyj2qA4=; X-YMail-OSG: MdJGZ8gVM1lB_r8fEujY.B_SyYNoi6dQOquFtAGxBOS.8llJMnrnS8wntE.3Zde1mAWDnM1fWU6y7.udo8ksuGTrxRhYVi1ot_osRQ9dTKGLxvxkdxd7KMICRxcN4Esn51I6silvCypqATI1FrvoALTDhQ-- Received: from [209.166.103.197] by web53901.mail.re2.yahoo.com via HTTP; Thu, 13 Sep 2007 20:53:56 PDT Date: Thu, 13 Sep 2007 20:53:56 -0700 (PDT) From: Dave Frantz To: Kip Macy In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <352686.5608.qm@web53901.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 03:53:57 -0000 Okay, I've recompiled the GENERIC 7.0-current kernel with VERBOSE_SYSINIT. ddb is in the kernel too. Booting with the GENERIC kernel built with those options and with ACPI enabled, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... And then the system hangs. I cannot break into ddb with Ctrl+Alt+Esc at this point. If I disable ACPI and boot with the same kernel, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... firewire0: 2 nodes, maxhop <=1, cable IRM=1 (me) firewire0: bus manager 1 (me) And it hangs there. Any ideas on what I should do next? Thanks in advance. --- Kip Macy wrote: > Turn on VERBOSE_SYSINIT and ddb (although clock > interrupts might not > be running at that point). > > > -Kip > > > On 9/13/07, Dave Frantz > wrote: > > I've been tracking 7.0 for several weeks now using > > cvsup. Unfortunately, in this time, I haven't been > > able to build a working kernel, even using > GENERIC. > > > > When I try to use a 7.0 current kernel, the system > > gets about 6/8ths through the device probe, then > > simply stops. It does not visibly panic; it just > stops > > the device probe and does nothing. (It acts like > the > > kernel goes into a loop someplace and never gets > out.) > > This occurs whether ACPI is enabled or not. ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 04:30:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A9416A417 for ; Fri, 14 Sep 2007 04:30:27 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1109D13C461 for ; Fri, 14 Sep 2007 04:30:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so873410waf for ; Thu, 13 Sep 2007 21:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=ojunU2APxRZoeqpuBa1k1Qhcmc/yGJFCCyT4Qi+KpQ4=; b=TxC4TrA1rXGTMA2fsxUk7pM99cwHeW2clbLiAQtcRnQdyR7mzhhKTFCS1+MU9qGzaiqIsBuys/7nkibxyS+StEdzPWLbSSTH5HlkeKPBJ+zQBLFHNaQl+VRduCCZNFdonb7GnHjH4XvsgGqEx7ByCD8YPMTa2c+v+P5SLFCv0zM= 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=e1EhtuvGFHtqsvupe3A51+GJPJzWaX0Zlt1E1Zhqs/r3eZWOHwdqNua51mR2Xw+leZZ2lnoy5g1IILbaDopNQZZSgYxce7qeIPmIg/U3l0slMhHo1EGpd5KELW+wChG3XoqZuFW2lhBKKzeqOySg2yMeIsE+WVEuiGsLuhH57z4= Received: by 10.115.74.1 with SMTP id b1mr1271694wal.1189744226343; Thu, 13 Sep 2007 21:30:26 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Thu, 13 Sep 2007 21:30:26 -0700 (PDT) Message-ID: Date: Thu, 13 Sep 2007 21:30:26 -0700 From: "Kip Macy" To: "Dave Frantz" In-Reply-To: <352686.5608.qm@web53901.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <352686.5608.qm@web53901.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 04:30:27 -0000 Try taking out firewire. And just to confirm - you have bootverbose set? -Kip On 9/13/07, Dave Frantz wrote: > Okay, I've recompiled the GENERIC 7.0-current kernel > with VERBOSE_SYSINIT. ddb is in the kernel too. > > Booting with the GENERIC kernel built with those > options and with ACPI enabled, I get: > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)... > > And then the system hangs. I cannot break into ddb > with Ctrl+Alt+Esc at this point. > > If I disable ACPI and boot with the same kernel, I > get: > > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)... firewire0: > 2 nodes, maxhop <=1, cable IRM=1 (me) > firewire0: bus manager 1 (me) > > And it hangs there. > > Any ideas on what I should do next? Thanks in advance. > > > > > --- Kip Macy wrote: > > > Turn on VERBOSE_SYSINIT and ddb (although clock > > interrupts might not > > be running at that point). > > > > > > -Kip > > > > > > On 9/13/07, Dave Frantz > > wrote: > > > I've been tracking 7.0 for several weeks now using > > > cvsup. Unfortunately, in this time, I haven't been > > > able to build a working kernel, even using > > GENERIC. > > > > > > When I try to use a 7.0 current kernel, the system > > > gets about 6/8ths through the device probe, then > > > simply stops. It does not visibly panic; it just > > stops > > > the device probe and does nothing. (It acts like > > the > > > kernel goes into a loop someplace and never gets > > out.) > > > This occurs whether ACPI is enabled or not. > > > > > > > ____________________________________________________________________________________ > Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! > http://tv.yahoo.com/collections/3658 > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 05:44:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E3416A417 for ; Fri, 14 Sep 2007 05:44:05 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53901.mail.re2.yahoo.com (web53901.mail.re2.yahoo.com [206.190.36.211]) by mx1.freebsd.org (Postfix) with SMTP id CAEC713C45D for ; Fri, 14 Sep 2007 05:44:04 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 51345 invoked by uid 60001); 14 Sep 2007 05:44: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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=a5vCxTLUjT0lUVek4fewptk2+sT7gUoAHWDZGHnf33oKuQsaEakxdDMdwy9XvJ+y37u0xNEPMODh2wQBrr8MF8Wkh+ra/92Yf+VcI/5hmgJkC0DYfqepXTar/itpGimY6iV++mB+GPki2rOQJihCtC9g+NpOb/pnhJKel2Gy0YU=; X-YMail-OSG: 6Ado.g8VM1nGn3Lxi1tzM78qXTf4HM7KcxPEBRlMkM9Di8_jGJsfp7B3pqpZP22igA-- Received: from [209.166.103.197] by web53901.mail.re2.yahoo.com via HTTP; Thu, 13 Sep 2007 22:44:03 PDT Date: Thu, 13 Sep 2007 22:44:03 -0700 (PDT) From: Dave Frantz To: Kip Macy In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <978104.51071.qm@web53901.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 05:44:05 -0000 Actually, I didn't have bootverbose set. The same GENERIC kernel, with bootverbose and ACPI set, gives: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)...rr232x: no controller detected acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery0: battery initialization done, tried 1 times then hangs. With bootverbose set and with ACPI off, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... rr232x: no controllers detected. firewire0: 2 nodes, maxhop <=1, cable IRM=1 (me) firewire0: bus manager 1 (me) and stop. I've compiled a new GENERIC kernel. The new 7.0-current kernel has VERBOSE_SYSINIT and ddb, and I've compiled out all Firewire devices (firewire, sbp, fwe, fwip, dcons, and dcons_crom.) The new kernel, with bootverbose and ACPI set, gives: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)...rr232x: no controller detected acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start then hangs. With bootverbose set and with ACPI off, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... rr232x: no controllers detected. and then it hangs. I don't think Firewire is causing this, unfortunately. At least not directly. Thank you very much for your help, by the way. --- Kip Macy wrote: > Try taking out firewire. And just to confirm - you > have bootverbose set? > > -Kip > > On 9/13/07, Dave Frantz > wrote: > > Okay, I've recompiled the GENERIC 7.0-current > kernel > > with VERBOSE_SYSINIT. ddb is in the kernel too. > > > > Booting with the GENERIC kernel built with those > > options and with ACPI enabled, I get: > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)... > > > > And then the system hangs. I cannot break into ddb > > with Ctrl+Alt+Esc at this point. > > > > If I disable ACPI and boot with the same kernel, I > > get: > > > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)... > firewire0: > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > firewire0: bus manager 1 (me) > > > > And it hangs there. > > > > Any ideas on what I should do next? Thanks in > advance. > > > > > > > > > > --- Kip Macy wrote: > > > > > Turn on VERBOSE_SYSINIT and ddb (although clock > > > interrupts might not > > > be running at that point). > > > > > > > > > -Kip > > > > > > > > > On 9/13/07, Dave Frantz > > > > wrote: > > > > I've been tracking 7.0 for several weeks now > using > > > > cvsup. Unfortunately, in this time, I haven't > been > > > > able to build a working kernel, even using > > > GENERIC. > > > > > > > > When I try to use a 7.0 current kernel, the > system > > > > gets about 6/8ths through the device probe, > then > > > > simply stops. It does not visibly panic; it > just > > > stops > > > > the device probe and does nothing. (It acts > like > > > the > > > > kernel goes into a loop someplace and never > gets > > > out.) > > > > This occurs whether ACPI is enabled or not. > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Catch up on fall's hot new shows on Yahoo! TV. > Watch previews, get listings, and more! > > http://tv.yahoo.com/collections/3658 > > > _______________________________________________ > 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" > ____________________________________________________________________________________ Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 05:52:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F0F16A417 for ; Fri, 14 Sep 2007 05:52:03 +0000 (UTC) (envelope-from kip.macy@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 856CF13C428 for ; Fri, 14 Sep 2007 05:52:03 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so525110nzf for ; Thu, 13 Sep 2007 22:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=gH/UgtpokLnt7xdoL6urSRMXPT9NDHk86HrX89Psa8c=; b=P/o62QgSUsfjTPGDFwwAMyVuTe2FePhsuak8nT5YDByfqd16BXDoTr/hcSjQMgMUunM7Tb+4F7QdlohrrQ1rIaCoSELKHogGX9Hd4Qrajc09Z4E53xEJX6fRH2K8lbH/P0+fM/VObz0kxtH7yvENh3wMbQeKmLkZ3Z8UyK5hT/M= 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=C3Xk105zf6ypoI5ns7PDT0Nktlrp7TsSqJieE69HJoc/8EjrXDE6esNOARtMDf170arUjhtjRvids0ilr5Ey8mYLyvECvNGpN9fPDe+fwT41c9oZnxfFDOpps9GyEfiSVfXmZxTeXt6CfsJqkM9SwhVxU64ErLBJnrtxZmLhCWs= Received: by 10.114.169.2 with SMTP id r2mr87464wae.1189749122207; Thu, 13 Sep 2007 22:52:02 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Thu, 13 Sep 2007 22:52:02 -0700 (PDT) Message-ID: Date: Thu, 13 Sep 2007 22:52:02 -0700 From: "Kip Macy" To: "Dave Frantz" In-Reply-To: <978104.51071.qm@web53901.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <978104.51071.qm@web53901.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 05:52:04 -0000 > run_interrupt_driven_config_hooks(0)... rr232x: no > controllers detected. put a printf in run_interrupt_driven_config_hooks printing out the addresses of the functions, with something like: printf("calling %p ...", fun); (*fun)(); printf("done\n"); The most likely scenario is one of the drivers taking you off into the weeds. -Kip > > and then it hangs. > > I don't think Firewire is causing this, unfortunately. > At least not directly. > > Thank you very much for your help, by the way. > > --- Kip Macy wrote: > > > Try taking out firewire. And just to confirm - you > > have bootverbose set? > > > > -Kip > > > > On 9/13/07, Dave Frantz > > wrote: > > > Okay, I've recompiled the GENERIC 7.0-current > > kernel > > > with VERBOSE_SYSINIT. ddb is in the kernel too. > > > > > > Booting with the GENERIC kernel built with those > > > options and with ACPI enabled, I get: > > > > > > subsystem 9000000 > > > tcov_init(0)... done. > > > subsystem a000000 > > > synch_setup(0)... done. > > > subsystem a800000 > > > run_interrupt_driven_config_hooks(0)... > > > > > > And then the system hangs. I cannot break into ddb > > > with Ctrl+Alt+Esc at this point. > > > > > > If I disable ACPI and boot with the same kernel, I > > > get: > > > > > > > > > subsystem 9000000 > > > tcov_init(0)... done. > > > subsystem a000000 > > > synch_setup(0)... done. > > > subsystem a800000 > > > run_interrupt_driven_config_hooks(0)... > > firewire0: > > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > > firewire0: bus manager 1 (me) > > > > > > And it hangs there. > > > > > > Any ideas on what I should do next? Thanks in > > advance. > > > > > > > > > > > > > > > --- Kip Macy wrote: > > > > > > > Turn on VERBOSE_SYSINIT and ddb (although clock > > > > interrupts might not > > > > be running at that point). > > > > > > > > > > > > -Kip > > > > > > > > > > > > On 9/13/07, Dave Frantz > > > > > > wrote: > > > > > I've been tracking 7.0 for several weeks now > > using > > > > > cvsup. Unfortunately, in this time, I haven't > > been > > > > > able to build a working kernel, even using > > > > GENERIC. > > > > > > > > > > When I try to use a 7.0 current kernel, the > > system > > > > > gets about 6/8ths through the device probe, > > then > > > > > simply stops. It does not visibly panic; it > > just > > > > stops > > > > > the device probe and does nothing. (It acts > > like > > > > the > > > > > kernel goes into a loop someplace and never > > gets > > > > out.) > > > > > This occurs whether ACPI is enabled or not. > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > Catch up on fall's hot new shows on Yahoo! TV. > > Watch previews, get listings, and more! > > > http://tv.yahoo.com/collections/3658 > > > > > _______________________________________________ > > 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" > > > > > > > ____________________________________________________________________________________ > Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. > http://tv.yahoo.com/ > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 06:15:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DEF116A417 for ; Fri, 14 Sep 2007 06:15:47 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53911.mail.re2.yahoo.com (web53911.mail.re2.yahoo.com [206.190.38.160]) by mx1.freebsd.org (Postfix) with SMTP id 24F0413C45E for ; Fri, 14 Sep 2007 06:15:46 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 22070 invoked by uid 60001); 14 Sep 2007 06:15:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=FMuRovM+lcsA34ykPaJc2ms22iQUORE366YE7PxN8/F9JS4kA4aYc7kLL/j84v6wIFDHxCRP9jH680wCeQyr4bnM3nc+SLlh0YEFoZ0k8nfCkdZBEvbMZJxlYycCJAUKZmXdU9c7ONlMgXPOWmeC4tT4yGOByJcpN+VdHtbVuuo=; X-YMail-OSG: vKLx0p8VM1mV1c9yx8YFnYeO01NGuq5WuZ1XnKh1..l_yGSDB5MRUlPRbLV_LuP9SDcxTphg5uhH296WxWbvpmhpHtJ25Z99ZY7n7XDTetcTxWMnLUEEizMYxhB8Eju4mWT91gXM3WOFMvjdUbLxJg-- Received: from [209.166.103.197] by web53911.mail.re2.yahoo.com via HTTP; Thu, 13 Sep 2007 23:15:46 PDT Date: Thu, 13 Sep 2007 23:15:46 -0700 (PDT) From: Dave Frantz To: Kip Macy In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <327147.21692.qm@web53911.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 06:15:47 -0000 I just finished searching the files in /usr/src/sys for run_interrupt_driven_config_hooks. The only references I get for this are in kern/subr_autoconf.c. Unfortunately, my C-fu is a little weak. I've reproduced the run_interrupt_driven_config_hooks function below. Any ideas on where I should put the printf? Is this the right function? /* ARGSUSED */ static void run_interrupt_driven_config_hooks(void *dummy); static void run_interrupt_driven_config_hooks(dummy) void *dummy; { struct intr_config_hook *hook_entry, *next_entry; mtx_lock(&intr_config_hook_lock); TAILQ_FOREACH_SAFE(hook_entry, &intr_config_hook_list, ich_links, next_entry) { next_entry = TAILQ_NEXT(hook_entry, ich_links); mtx_unlock(&intr_config_hook_lock); (*hook_entry->ich_func)(hook_entry->ich_arg); mtx_lock(&intr_config_hook_lock); } while (!TAILQ_EMPTY(&intr_config_hook_list)) { msleep(&intr_config_hook_list, &intr_config_hook_lock, PCONFIG, "conifhk", 0); } mtx_unlock(&intr_config_hook_lock); } SYSINIT(intr_config_hooks, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, run_interrupt_driven_config_hooks, NULL) --- Kip Macy wrote: > > run_interrupt_driven_config_hooks(0)... rr232x: > no > > controllers detected. > > put a printf in run_interrupt_driven_config_hooks > printing out the > addresses of the functions, > with something like: > printf("calling %p ...", fun); > (*fun)(); > printf("done\n"); > > The most likely scenario is one of the drivers > taking you off into the weeds. > > -Kip > > > > > > > and then it hangs. > > > > I don't think Firewire is causing this, > unfortunately. > > At least not directly. > > > > Thank you very much for your help, by the way. > > > > --- Kip Macy wrote: > > > > > Try taking out firewire. And just to confirm - > you > > > have bootverbose set? > > > > > > -Kip > > > > > > On 9/13/07, Dave Frantz > > > > wrote: > > > > Okay, I've recompiled the GENERIC 7.0-current > > > kernel > > > > with VERBOSE_SYSINIT. ddb is in the kernel > too. > > > > > > > > Booting with the GENERIC kernel built with > those > > > > options and with ACPI enabled, I get: > > > > > > > > subsystem 9000000 > > > > tcov_init(0)... done. > > > > subsystem a000000 > > > > synch_setup(0)... done. > > > > subsystem a800000 > > > > run_interrupt_driven_config_hooks(0)... > > > > > > > > And then the system hangs. I cannot break into > ddb > > > > with Ctrl+Alt+Esc at this point. > > > > > > > > If I disable ACPI and boot with the same > kernel, I > > > > get: > > > > > > > > > > > > subsystem 9000000 > > > > tcov_init(0)... done. > > > > subsystem a000000 > > > > synch_setup(0)... done. > > > > subsystem a800000 > > > > run_interrupt_driven_config_hooks(0)... > > > firewire0: > > > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > > > firewire0: bus manager 1 (me) > > > > > > > > And it hangs there. > > > > > > > > Any ideas on what I should do next? Thanks in > > > advance. > > > > ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 06:19:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3141816A418 for ; Fri, 14 Sep 2007 06:19:43 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6724213C45B for ; Fri, 14 Sep 2007 06:19:42 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so599203nfb for ; Thu, 13 Sep 2007 23:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=1FabhsVLaB+kiX+HXBrzY99lMzh+EUFBUTiwGLTb6YA=; b=dJc3EftMwvc8f/Is6i2r7kzLHfo9G6AP3w22WTSEWqpHeEdKo8ZJMKL7+BFfKurTmtkyuaulbVmjJuvjB2MIs6Vt1vHTb06mfsgyqoC6YhJurounpSfSSDCtoCRDwtMNFzORSS7Jrs5uwHpIoSVCgNI2s+h7Ek60Pkjza0jycIY= 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=FsK59S8qxl0JjpPka2jT+l+6vq/EIRjd4EEn8fFnwy2oiqvYSKvVEo/BmWRM/aygyuFN093uVTQCIhTPVDBjMTPSyZ5g8ZoTK3whFiEd7qeXyFm+c+wgCZ4NOtW/3SERpO9ZNZAm5CwqIbRUoMKzrWRyEFZ39pfUKuGGvb1UwUE= Received: by 10.78.170.6 with SMTP id s6mr776390hue.1189750780823; Thu, 13 Sep 2007 23:19:40 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 13 Sep 2007 23:19:40 -0700 (PDT) Message-ID: Date: Thu, 13 Sep 2007 23:19:40 -0700 From: "Kip Macy" To: "Dave Frantz" In-Reply-To: <327147.21692.qm@web53911.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <327147.21692.qm@web53911.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 06:19:43 -0000 On 9/13/07, Dave Frantz wrote: > I just finished searching the files in /usr/src/sys > for run_interrupt_driven_config_hooks. The only > references I get for this are in kern/subr_autoconf.c. > > Unfortunately, my C-fu is a little weak. I've > reproduced the run_interrupt_driven_config_hooks > function below. Any ideas on where I should put the > printf? Is this the right function? see inline > > /* ARGSUSED */ > static void run_interrupt_driven_config_hooks(void > *dummy); > > static void > run_interrupt_driven_config_hooks(dummy) > void *dummy; > { > struct intr_config_hook *hook_entry, *next_entry; > > mtx_lock(&intr_config_hook_lock); > TAILQ_FOREACH_SAFE(hook_entry, > &intr_config_hook_list, ich_links, > next_entry) { > next_entry = TAILQ_NEXT(hook_entry, ich_links); printf("calling %p ... ", hook_entry->ich_func); > mtx_unlock(&intr_config_hook_lock); > (*hook_entry->ich_func)(hook_entry->ich_arg); > mtx_lock(&intr_config_hook_lock); printf("done\n"); > } > > while (!TAILQ_EMPTY(&intr_config_hook_list)) { > msleep(&intr_config_hook_list, > &intr_config_hook_lock, PCONFIG, > "conifhk", 0); > } > mtx_unlock(&intr_config_hook_lock); > } > SYSINIT(intr_config_hooks, SI_SUB_INT_CONFIG_HOOKS, > SI_ORDER_FIRST, > run_interrupt_driven_config_hooks, NULL) > > --- Kip Macy wrote: > > > > run_interrupt_driven_config_hooks(0)... rr232x: > > no > > > controllers detected. > > > > put a printf in run_interrupt_driven_config_hooks > > printing out the > > addresses of the functions, > > with something like: > > printf("calling %p ...", fun); > > (*fun)(); > > printf("done\n"); > > > > The most likely scenario is one of the drivers > > taking you off into the weeds. > > > > -Kip > > > > > > > > > > > > and then it hangs. > > > > > > I don't think Firewire is causing this, > > unfortunately. > > > At least not directly. > > > > > > Thank you very much for your help, by the way. > > > > > > --- Kip Macy wrote: > > > > > > > Try taking out firewire. And just to confirm - > > you > > > > have bootverbose set? > > > > > > > > -Kip > > > > > > > > On 9/13/07, Dave Frantz > > > > > > wrote: > > > > > Okay, I've recompiled the GENERIC 7.0-current > > > > kernel > > > > > with VERBOSE_SYSINIT. ddb is in the kernel > > too. > > > > > > > > > > Booting with the GENERIC kernel built with > > those > > > > > options and with ACPI enabled, I get: > > > > > > > > > > subsystem 9000000 > > > > > tcov_init(0)... done. > > > > > subsystem a000000 > > > > > synch_setup(0)... done. > > > > > subsystem a800000 > > > > > run_interrupt_driven_config_hooks(0)... > > > > > > > > > > And then the system hangs. I cannot break into > > ddb > > > > > with Ctrl+Alt+Esc at this point. > > > > > > > > > > If I disable ACPI and boot with the same > > kernel, I > > > > > get: > > > > > > > > > > > > > > > subsystem 9000000 > > > > > tcov_init(0)... done. > > > > > subsystem a000000 > > > > > synch_setup(0)... done. > > > > > subsystem a800000 > > > > > run_interrupt_driven_config_hooks(0)... > > > > firewire0: > > > > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > > > > firewire0: bus manager 1 (me) > > > > > > > > > > And it hangs there. > > > > > > > > > > Any ideas on what I should do next? Thanks in > > > > advance. > > > > > > > > > > ____________________________________________________________________________________ > Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. > http://answers.yahoo.com/dir/?link=list&sid=396545433 > _______________________________________________ > 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 Sep 14 06:33:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B1816A418 for ; Fri, 14 Sep 2007 06:33:45 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [89.185.226.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6E913C45A for ; Fri, 14 Sep 2007 06:33:44 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [89.185.226.22]) by nxm.secservers.com (8.13.4/8.13.8) with ESMTP id l8E6Xgfg049733; Fri, 14 Sep 2007 08:33:42 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Brooks Talley In-Reply-To: <22187550.52511189717324600.JavaMail.root@zmail.illuminati.org> References: <22187550.52511189717324600.JavaMail.root@zmail.illuminati.org> Content-Type: text/plain Date: Fri, 14 Sep 2007 08:33:42 +0200 Message-Id: <1189751622.1343.3.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: Building a 32 bit chroot on 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: Fri, 14 Sep 2007 06:33:45 -0000 Brooks Talley wrote: > Hi, everyone. I'm trying to build a 32 bit chroot on a 7.0-CURRENT amd64 installation. The sources are up to date. > > "make TARGET_ARCH=i386 buildworld" fails partway through with the message: > > ===> lib/csu/i386-elf (obj,depend,all,install) > rm -f .depend > CC='/usr/bin/cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > /usr/bin/cc -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c > {standard input}: Assembler messages: > {standard input}:27: Error: suffix or operands invalid for `mov' > *** Error code 1 > > Stop in /usr/src/lib/csu/i386-elf. > > ...And ideas? I did successfully did it with 'make buildworld TARGET=i386' couple of days ago. > > Thanks > -Brooks > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 06:42:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE7F616A421 for ; Fri, 14 Sep 2007 06:42:41 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6E113C461 for ; Fri, 14 Sep 2007 06:42:41 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by wa-out-1112.google.com with SMTP id k17so901973waf for ; Thu, 13 Sep 2007 23:42:41 -0700 (PDT) Received: by 10.114.132.5 with SMTP id f5mr1381496wad.1189752160633; Thu, 13 Sep 2007 23:42:40 -0700 (PDT) Received: by 10.141.76.19 with HTTP; Thu, 13 Sep 2007 23:42:40 -0700 (PDT) Message-ID: <626eb4530709132342xef398f6gd16424aac395d6dc@mail.gmail.com> Date: Fri, 14 Sep 2007 15:42:40 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Dave Frantz" In-Reply-To: <978104.51071.qm@web53901.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <978104.51071.qm@web53901.mail.re2.yahoo.com> X-Google-Sender-Auth: e4aa390fc193f94e Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 06:42:41 -0000 It could be a problem of syscons. Try the following patch or serial/dcons console, or disable HTT. http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076377.html On 9/14/07, Dave Frantz wrote: > Actually, I didn't have bootverbose set. The same > GENERIC kernel, with bootverbose and ACPI set, gives: > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)...rr232x: no > controller detected > acpi_acad0: acline initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > battery0: battery initialization start > battery0: battery initialization done, tried 1 times > > then hangs. With bootverbose set and with ACPI off, I > get: > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)... rr232x: no > controllers detected. > firewire0: 2 nodes, maxhop <=1, cable IRM=1 (me) > firewire0: bus manager 1 (me) > > and stop. > > I've compiled a new GENERIC kernel. The new > 7.0-current kernel has VERBOSE_SYSINIT and ddb, and > I've compiled out all Firewire devices (firewire, sbp, > fwe, fwip, dcons, and dcons_crom.) > > The new kernel, with bootverbose and ACPI set, gives: > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)...rr232x: no > controller detected > acpi_acad0: acline initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > battery0: battery initialization start > > then hangs. With bootverbose set and with ACPI off, I > get: > > subsystem 9000000 > tcov_init(0)... done. > subsystem a000000 > synch_setup(0)... done. > subsystem a800000 > run_interrupt_driven_config_hooks(0)... rr232x: no > controllers detected. > > and then it hangs. > > I don't think Firewire is causing this, unfortunately. > At least not directly. > > Thank you very much for your help, by the way. > > --- Kip Macy wrote: > > > Try taking out firewire. And just to confirm - you > > have bootverbose set? > > > > -Kip > > > > On 9/13/07, Dave Frantz > > wrote: > > > Okay, I've recompiled the GENERIC 7.0-current > > kernel > > > with VERBOSE_SYSINIT. ddb is in the kernel too. > > > > > > Booting with the GENERIC kernel built with those > > > options and with ACPI enabled, I get: > > > > > > subsystem 9000000 > > > tcov_init(0)... done. > > > subsystem a000000 > > > synch_setup(0)... done. > > > subsystem a800000 > > > run_interrupt_driven_config_hooks(0)... > > > > > > And then the system hangs. I cannot break into ddb > > > with Ctrl+Alt+Esc at this point. > > > > > > If I disable ACPI and boot with the same kernel, I > > > get: > > > > > > > > > subsystem 9000000 > > > tcov_init(0)... done. > > > subsystem a000000 > > > synch_setup(0)... done. > > > subsystem a800000 > > > run_interrupt_driven_config_hooks(0)... > > firewire0: > > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > > firewire0: bus manager 1 (me) > > > > > > And it hangs there. > > > > > > Any ideas on what I should do next? Thanks in > > advance. > > > > > > > > > > > > > > > --- Kip Macy wrote: > > > > > > > Turn on VERBOSE_SYSINIT and ddb (although clock > > > > interrupts might not > > > > be running at that point). > > > > > > > > > > > > -Kip > > > > > > > > > > > > On 9/13/07, Dave Frantz > > > > > > wrote: > > > > > I've been tracking 7.0 for several weeks now > > using > > > > > cvsup. Unfortunately, in this time, I haven't > > been > > > > > able to build a working kernel, even using > > > > GENERIC. > > > > > > > > > > When I try to use a 7.0 current kernel, the > > system > > > > > gets about 6/8ths through the device probe, > > then > > > > > simply stops. It does not visibly panic; it > > just > > > > stops > > > > > the device probe and does nothing. (It acts > > like > > > > the > > > > > kernel goes into a loop someplace and never > > gets > > > > out.) > > > > > This occurs whether ACPI is enabled or not. > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > Catch up on fall's hot new shows on Yahoo! TV. > > Watch previews, get listings, and more! > > > http://tv.yahoo.com/collections/3658 > > > > > _______________________________________________ > > 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" > > > > > > > ____________________________________________________________________________________ > Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. > http://tv.yahoo.com/ > > _______________________________________________ > 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" > > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 06:45:04 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B44DE16A41B; Fri, 14 Sep 2007 06:45:04 +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 6837513C48E; Fri, 14 Sep 2007 06:45:04 +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 9340D2097; Fri, 14 Sep 2007 08:44:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 13E0E2096; Fri, 14 Sep 2007 08:44:59 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id EF2628447E; Fri, 14 Sep 2007 08:44:58 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Constantine A. Murenin" References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> Date: Fri, 14 Sep 2007 08:44:58 +0200 In-Reply-To: <46E9FC0C.70607@FreeBSD.org> (Constantine A. Murenin's message of "Thu\, 13 Sep 2007 23\:12\:12 -0400") Message-ID: <86ir6deoet.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Alexander Leidinger , freebsd-current@FreeBSD.org, Shteryana Shopova , freebsd-arch@FreeBSD.org Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 06:45:04 -0000 "Constantine A. Murenin" writes: > Therefore, I hereby request that this patch be considered for > immediate inclusion into FreeBSD's main CVS repository. Trouble is, we're in code freeze... you'll have to ask re@. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 06:46:51 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3890216A417 for ; Fri, 14 Sep 2007 06:46:51 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (mx1.vega.ru [87.242.77.163]) by mx1.freebsd.org (Postfix) with ESMTP id E8D3513C458 for ; Fri, 14 Sep 2007 06:46:50 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=53312 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IW4gf-000FMR-C8; Fri, 14 Sep 2007 06:29:57 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.1/8.14.1) with ESMTP id l8E6TZTa002244; Fri, 14 Sep 2007 10:29:35 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.1/8.14.1/Submit) id l8E6TZe6002243; Fri, 14 Sep 2007 10:29:35 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 14 Sep 2007 10:29:35 +0400 From: Ruslan Ermilov To: Brooks Talley Message-ID: <20070914062935.GB2058@team.vega.ru> References: <20070914001247.C484@fw.reifenberger.com> <29536115.52741189723672473.JavaMail.root@zmail.illuminati.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29536115.52741189723672473.JavaMail.root@zmail.illuminati.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@FreeBSD.org Subject: Re: Building a 32 bit chroot on 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: Fri, 14 Sep 2007 06:46:51 -0000 On Thu, Sep 13, 2007 at 03:47:52PM -0700, Brooks Talley wrote: > ----- "Michael Reifenberger" wrote: > > On Thu, 13 Sep 2007, Brooks Talley wrote: > > > > > Date: Thu, 13 Sep 2007 14:02:04 -0700 (PDT) > > > From: Brooks Talley > > > To: freebsd-current > > > Subject: Building a 32 bit chroot on amd64? > > > > > > Hi, everyone. I'm trying to build a 32 bit chroot on a 7.0-CURRENT > > amd64 installation. The sources are up to date. > > > > > > "make TARGET_ARCH=i386 buildworld" fails partway through with the > > message: > > > > > > > Could you try: > > make TARGET_ARCH=i386 TARGET_CPUTYPE=i386 buildworld > > Well, that's different at least. This time it breaks libgcc, with the clearly wrong but not surprising message that i386 doesn't support the x86_64 instruction set :) > What's in your /etc/make.conf and /etc/src.conf? Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 07:17:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51BB816A419 for ; Fri, 14 Sep 2007 07:17:58 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53907.mail.re2.yahoo.com (web53907.mail.re2.yahoo.com [206.190.36.217]) by mx1.freebsd.org (Postfix) with SMTP id 0C33013C480 for ; Fri, 14 Sep 2007 07:17:57 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 11982 invoked by uid 60001); 14 Sep 2007 07:17:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SCfL3F1NlwtnJR+bah8w66bNjB3ftuuj9bwrS62sSnVNQap5aEKLnBYeWmzo1FWVC5jAAEhT7GLt1grkvc4XxocYemQmtniOEg+w36t/JFG2hxwAX+2InczRAR9C8SIWuMM3ItWYThHmukrZ6/1YoN/J4KqOms+LDbj7f3C6l24=; X-YMail-OSG: KEuNS6AVM1n905gh8eyej1NE62GoAy3BAImqCfGwkeuAOtpNHkZzwwcCxgXTLr.kEyHx8yuYMcnfMjgwbM4DU3PCBqTzqzxr6zOHN6qE0oRd5F3tL.s53hm40w-- Received: from [209.166.103.197] by web53907.mail.re2.yahoo.com via HTTP; Fri, 14 Sep 2007 00:17:57 PDT Date: Fri, 14 Sep 2007 00:17:57 -0700 (PDT) From: Dave Frantz To: Hidetoshi Shimokawa In-Reply-To: <626eb4530709132342xef398f6gd16424aac395d6dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <246729.11385.qm@web53907.mail.re2.yahoo.com> Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 07:17:58 -0000 I just tried disabling HTT. Unfortunately, it still crashes in the exact same way. Thanks for the idea, though. --- Hidetoshi Shimokawa wrote: > It could be a problem of syscons. > Try the following patch or serial/dcons console, or > disable HTT. > > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076377.html > > On 9/14/07, Dave Frantz > wrote: > > Actually, I didn't have bootverbose set. The same > > GENERIC kernel, with bootverbose and ACPI set, > gives: > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)...rr232x: > no > > controller detected > > acpi_acad0: acline initialization start > > acpi_acad0: On Line > > acpi_acad0: acline initialization done, tried 1 > times > > battery0: battery initialization start > > battery0: battery initialization done, tried 1 > times > > > > then hangs. With bootverbose set and with ACPI > off, I > > get: > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)... rr232x: > no > > controllers detected. > > firewire0: 2 nodes, maxhop <=1, cable IRM=1 (me) > > firewire0: bus manager 1 (me) > > > > and stop. > > > > I've compiled a new GENERIC kernel. The new > > 7.0-current kernel has VERBOSE_SYSINIT and ddb, > and > > I've compiled out all Firewire devices (firewire, > sbp, > > fwe, fwip, dcons, and dcons_crom.) > > > > The new kernel, with bootverbose and ACPI set, > gives: > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)...rr232x: > no > > controller detected > > acpi_acad0: acline initialization start > > acpi_acad0: On Line > > acpi_acad0: acline initialization done, tried 1 > times > > battery0: battery initialization start > > > > then hangs. With bootverbose set and with ACPI > off, I > > get: > > > > subsystem 9000000 > > tcov_init(0)... done. > > subsystem a000000 > > synch_setup(0)... done. > > subsystem a800000 > > run_interrupt_driven_config_hooks(0)... rr232x: > no > > controllers detected. > > > > and then it hangs. > > > > I don't think Firewire is causing this, > unfortunately. > > At least not directly. > > > > Thank you very much for your help, by the way. > > > > --- Kip Macy wrote: > > > > > Try taking out firewire. And just to confirm - > you > > > have bootverbose set? > > > > > > -Kip > > > > > > On 9/13/07, Dave Frantz > > > > wrote: > > > > Okay, I've recompiled the GENERIC 7.0-current > > > kernel > > > > with VERBOSE_SYSINIT. ddb is in the kernel > too. > > > > > > > > Booting with the GENERIC kernel built with > those > > > > options and with ACPI enabled, I get: > > > > > > > > subsystem 9000000 > > > > tcov_init(0)... done. > > > > subsystem a000000 > > > > synch_setup(0)... done. > > > > subsystem a800000 > > > > run_interrupt_driven_config_hooks(0)... > > > > > > > > And then the system hangs. I cannot break into > ddb > > > > with Ctrl+Alt+Esc at this point. > > > > > > > > If I disable ACPI and boot with the same > kernel, I > > > > get: > > > > > > > > > > > > subsystem 9000000 > > > > tcov_init(0)... done. > > > > subsystem a000000 > > > > synch_setup(0)... done. > > > > subsystem a800000 > > > > run_interrupt_driven_config_hooks(0)... > > > firewire0: > > > > 2 nodes, maxhop <=1, cable IRM=1 (me) > > > > firewire0: bus manager 1 (me) > > > > > > > > And it hangs there. > > > > > > > > Any ideas on what I should do next? Thanks in > > > advance. > > > > > > > > > > > > > > > > > > > > --- Kip Macy wrote: > > > > > > > > > Turn on VERBOSE_SYSINIT and ddb (although > clock > > > > > interrupts might not > > > > > be running at that point). > > > > > > > > > > > > > > > -Kip > > > > > > > > > > > > > > > On 9/13/07, Dave Frantz > > > > > > > > wrote: > > > > > > I've been tracking 7.0 for several weeks > now > > > using > > > > > > cvsup. Unfortunately, in this time, I > haven't > > > been > > > > > > able to build a working kernel, even using > > > > > GENERIC. > > > > > > > > > > > > When I try to use a 7.0 current kernel, > the > > > system > > > > > > gets about 6/8ths through the device > probe, > > > then > > > > > > simply stops. It does not visibly panic; > it > > > just > > > > > stops > > > > > > the device probe and does nothing. (It > acts > > > like > > > > > the > > > > > > kernel goes into a loop someplace and > never > > > gets > > > > > out.) > > > > > > This occurs whether ACPI is enabled or > not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > > > Catch up on fall's hot new shows on Yahoo! TV. > > > Watch previews, get listings, and more! > > > > http://tv.yahoo.com/collections/3658 > > > > > === message truncated === ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 07:24:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4241916A417 for ; Fri, 14 Sep 2007 07:24:36 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: from web53907.mail.re2.yahoo.com (web53907.mail.re2.yahoo.com [206.190.36.217]) by mx1.freebsd.org (Postfix) with SMTP id 108B413C46B for ; Fri, 14 Sep 2007 07:24:35 +0000 (UTC) (envelope-from imperial_courier@yahoo.com) Received: (qmail 14094 invoked by uid 60001); 14 Sep 2007 07:24:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=5HzYiaeibUL8lDEHtQaHx7aiZoNQYrAtJJyxDi1qTrucpyXSluKZnPGlFo5HwcIpvuQr1bweIKnqKapmOn5yo02ejWxWN9/u6CJt2sQMZclVS9J7KzoAFXZ/zqzR5mRgW0hrUNk2lscGFvyhyOixMlNCJVYN3rccaKMjFUYpb4Q=; X-YMail-OSG: 4eC8JEwVM1mndxMDfenqd3DpHF8Kgjm0TtwO5zmmvSYUefTIG2vYOTY8y0HIczBJblI24Q.vbKABRy.zdG9nsbIpX62U0mKAYBqxhPStiaGEuHRV4fnl8.KkSQ-- Received: from [209.166.103.197] by web53907.mail.re2.yahoo.com via HTTP; Fri, 14 Sep 2007 00:24:35 PDT Date: Fri, 14 Sep 2007 00:24:35 -0700 (PDT) From: Dave Frantz To: Kip Macy In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <566461.13079.qm@web53907.mail.re2.yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Kernel Locks During Device Probe on 7.0 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: Fri, 14 Sep 2007 07:24:36 -0000 Okay, I just finished rebuilding the GENERIC kernel with this patch. All Firewire devices are still compiled out of the kernel at this point. When I boot with ACPI on, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... Calling 0xc09bf490 ... rr232x: no controller detected. done. Calling 0xc04695d0 ... done. Calling 0xc04f29d0 ... acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery0: battery initialization done, tried 1 times and hangs. If I boot with ACPI off, I get: subsystem 9000000 tcov_init(0)... done. subsystem a000000 synch_setup(0)... done. subsystem a800000 run_interrupt_driven_config_hooks(0)... Calling 0xc09bf490 ... rr232x: no controller detected. done. Calling 0xc04695d0 ... done. Calling 0xc04f29d0 ... and it stops. --- Kip Macy wrote: > On 9/13/07, Dave Frantz > wrote: > > I just finished searching the files in > /usr/src/sys > > for run_interrupt_driven_config_hooks. The only > > references I get for this are in > kern/subr_autoconf.c. > > > > Unfortunately, my C-fu is a little weak. I've > > reproduced the run_interrupt_driven_config_hooks > > function below. Any ideas on where I should put > the > > printf? Is this the right function? > > see inline > > > > > /* ARGSUSED */ > > static void run_interrupt_driven_config_hooks(void > > *dummy); > > > > static void > > run_interrupt_driven_config_hooks(dummy) > > void *dummy; > > { > > struct intr_config_hook *hook_entry, > *next_entry; > > > > mtx_lock(&intr_config_hook_lock); > > TAILQ_FOREACH_SAFE(hook_entry, > > &intr_config_hook_list, ich_links, > > next_entry) { > > next_entry = > TAILQ_NEXT(hook_entry, ich_links); > > > printf("calling %p ... ", > hook_entry->ich_func); > > > > > mtx_unlock(&intr_config_hook_lock); > > > (*hook_entry->ich_func)(hook_entry->ich_arg); > > mtx_lock(&intr_config_hook_lock); > > printf("done\n"); > > > > } > > > > while > (!TAILQ_EMPTY(&intr_config_hook_list)) { > > msleep(&intr_config_hook_list, > > &intr_config_hook_lock, PCONFIG, > > "conifhk", 0); > > } > > mtx_unlock(&intr_config_hook_lock); > > } > > SYSINIT(intr_config_hooks, > SI_SUB_INT_CONFIG_HOOKS, > > SI_ORDER_FIRST, > > run_interrupt_driven_config_hooks, NULL) > > > > --- Kip Macy wrote: > > > > > > run_interrupt_driven_config_hooks(0)... > rr232x: > > > no > > > > controllers detected. > > > > > > put a printf in > run_interrupt_driven_config_hooks > > > printing out the > > > addresses of the functions, > > > with something like: > > > printf("calling %p ...", fun); > > > (*fun)(); > > > printf("done\n"); > > > > > > The most likely scenario is one of the drivers > > > taking you off into the weeds. > > > > > > -Kip > > > > > > > > > > > > > > > > > and then it hangs. > > > > > > > > I don't think Firewire is causing this, > > > unfortunately. > > > > At least not directly. > > > > > > > > Thank you very much for your help, by the way. > > > > ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 07:49:42 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B32516A418 for ; Fri, 14 Sep 2007 07:49:42 +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 821F413C45B for ; Fri, 14 Sep 2007 07:49:40 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 64283 invoked from network); 14 Sep 2007 07:49:38 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 14 Sep 2007 07:49:38 -0000 Message-ID: <46EA3D12.8030005@FreeBSD.org> Date: Fri, 14 Sep 2007 09:49:38 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.6 (X11/20070827) MIME-Version: 1.0 To: Thomas Vogt References: <1091994189.20070913041709@arpanet.ru> <46E941D0.5020204@FreeBSD.org> <46EA3263.2060701@solnet.ch> In-Reply-To: <46EA3263.2060701@solnet.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: portsnap fetch bug or quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 07:49:42 -0000 Thomas Vogt ha scritto: > When does this happen? Our server is pretty busy every morning between > 06.00 - 07.00 (UTC+2) because of so many parallels cvsup. Strange. I noticed only now that portsnap3 is next to me (Italy) and in fact it has the best latency, but the downloads are very intermittent (I receive N updated, a pause, other N updates, and so on, with portsnap1/2 it's continuous). Usually I portsnap around 8:00 (UTC + 1 + DST). -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 08:52:14 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09A716A418 for ; Fri, 14 Sep 2007 08:52:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3B15D13C491 for ; Fri, 14 Sep 2007 08:52:13 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8E8qC9W028407 for ; Fri, 14 Sep 2007 12:52:12 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 14 Sep 2007 12:52:12 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: <20070914124630.D14000@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Fri, 14 Sep 2007 12:52:12 +0400 (MSD) Cc: Subject: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 08:52:14 -0000 Hi there colleagues, possibly stupid question: it there a way to fool jail (real, not "tinderbox" one) that it's working under i386 kernel? This would be extremely useful for local package building. Quick googling does not reveal anything, or did I miss something obvious? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 09:02:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A26D16A418 for ; Fri, 14 Sep 2007 09:02:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 006C813C465 for ; Fri, 14 Sep 2007 09:02:13 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8E9278C000926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Sep 2007 11:02:12 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l8E927Wh027706 for ; Fri, 14 Sep 2007 11:02:07 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l8E93IPG001584 for freebsd-current@freebsd.org; Fri, 14 Sep 2007 11:03:18 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Fri, 14 Sep 2007 11:03:11 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart51729916.ZM3ZIk550b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709141103.18612.h.schmalzbauer@omnisec.de> Subject: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 09:02:14 -0000 --nextPart51729916.ZM3ZIk550b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, the first thing I have to do after a csup is to apply the unionfs=20 patchset-19-20070504. Is there any chance to get it commited before RELENG_7? It fixes at least one nasty bug for me and I haven't had any problems with= =20 unionfs so far (although constantly, but not heavily used). Thanks, =2DHarry --nextPart51729916.ZM3ZIk550b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG6k5WLDqVQ9VXb8gRAgPYAJwINHjcCBgN7llJ02wSPf6SQuxQUQCgg6FQ ra1UYqRilxgG6BpgjXm9jtc= =lWuv -----END PGP SIGNATURE----- --nextPart51729916.ZM3ZIk550b-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 09:51:07 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BFE16A41A for ; Fri, 14 Sep 2007 09:51:07 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 27F1D13C467 for ; Fri, 14 Sep 2007 09:51:06 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8E9p5E8075287; Fri, 14 Sep 2007 13:51:05 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 14 Sep 2007 13:51:05 +0400 (MSD) From: Dmitry Morozovsky To: Kenneth Vestergaard Schmidt In-Reply-To: Message-ID: <20070914134928.Y14000@woozle.rinet.ru> References: <20070914124630.D14000@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Fri, 14 Sep 2007 13:51:05 +0400 (MSD) Cc: current@FreeBSD.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 09:51:07 -0000 On Fri, 14 Sep 2007, Kenneth Vestergaard Schmidt wrote: KVS> > possibly stupid question: it there a way to fool jail (real, not "tinderbox" KVS> > one) that it's working under i386 kernel? This would be extremely useful for KVS> > local package building. KVS> KVS> We do it by creating an i386 chroot on the amd64-machine. Works perfectly. I'm a bit frightened by information which is exported by kernel (which is 64bit) - or is this case treated specially? We can fool uname, but what about sysctls? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 09:57:14 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E7D316A418 for ; Fri, 14 Sep 2007 09:57:14 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 05B5713C45B for ; Fri, 14 Sep 2007 09:57:13 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant-2.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 8573F1CC10C; Fri, 14 Sep 2007 11:39:12 +0200 (CEST) Received: by coruscant-2.local (Postfix, from userid 502) id 8601663DF53; Fri, 14 Sep 2007 11:39:11 +0200 (CEST) To: Dmitry Morozovsky References: <20070914124630.D14000@woozle.rinet.ru> From: Kenneth Vestergaard Schmidt Organization: Binary Solutions Date: Fri, 14 Sep 2007 11:39:11 +0200 In-Reply-To: <20070914124630.D14000@woozle.rinet.ru> (Dmitry Morozovsky's message of "Fri\, 14 Sep 2007 12\:52\:12 +0400 \(MSD\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 09:57:14 -0000 Dmitry Morozovsky writes: > possibly stupid question: it there a way to fool jail (real, not "tinderbox" > one) that it's working under i386 kernel? This would be extremely useful for > local package building. We do it by creating an i386 chroot on the amd64-machine. Works perfectly. /Kenneth From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 10:01:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C906816A419 for ; Fri, 14 Sep 2007 10:01:24 +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 B13D713C458 for ; Fri, 14 Sep 2007 10:01:24 +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 35AD246E2F; Fri, 14 Sep 2007 06:01:24 -0400 (EDT) Date: Fri, 14 Sep 2007 11:01:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Harald Schmalzbauer In-Reply-To: <200709141103.18612.h.schmalzbauer@omnisec.de> Message-ID: <20070914110024.G14481@fledge.watson.org> References: <200709141103.18612.h.schmalzbauer@omnisec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 10:01:24 -0000 On Fri, 14 Sep 2007, Harald Schmalzbauer wrote: > the first thing I have to do after a csup is to apply the unionfs > patchset-19-20070504. Is there any chance to get it commited before > RELENG_7? It fixes at least one nasty bug for me and I haven't had any > problems with unionfs so far (although constantly, but not heavily used). RE has handed this off to Jeff Roberson for some review, and I think I saw that last week he sent out some questions to Goto-san. As I saw Goto-san at the front of the room in the first session at EuroBSDCon this morning, he may be delayed in responding a bit longer. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 07:29:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8240316A41B for ; Thu, 6 Sep 2007 07:29:48 +0000 (UTC) (envelope-from odnomzagi@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 4425413C46A for ; Thu, 6 Sep 2007 07:29:48 +0000 (UTC) (envelope-from odnomzagi@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so68603wxd for ; Thu, 06 Sep 2007 00:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=AjvUUUV9I/FcFDK+Eo3NhVOyzZ7INngKuZ4dWxNUro8=; b=RMeLhsVDCe2UgIIwl7WKdexqHH5aPJl9pP04lFXIbmqts8zUiLXR9rjLkWdv6mdPSPAHleYYpJRZJ08N0+RN5n8BVipzLrLs929Jr22F52oySAujKas4I0791P8tnLx+0xCnYkWqGsFmVlURNBhuTfrML8+EkLZMpyr9srNJK40= 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=VdJVT9LN3fG3f/m+b9Fxk0+M5cMpcaNx1X0I3YwNEoO+iSyIBm3/ow7Zkf1+fmB2+Gy0ouyJKz9nYG+68zswNdfqmqq41S/qRK5UxWjgPu9XEUBd8WspyF6ITREpQ13JiwhJ2U+Vw6TGTA8ZqpOB9Z3yMWWXlUpkF6omQ1oIIxY= Received: by 10.90.75.10 with SMTP id x10mr590166aga.1189062092304; Thu, 06 Sep 2007 00:01:32 -0700 (PDT) Received: by 10.90.35.20 with HTTP; Thu, 6 Sep 2007 00:01:30 -0700 (PDT) Message-ID: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> Date: Thu, 6 Sep 2007 09:01:32 +0200 From: "Justin Smith" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: Lawsuit over ZFS - any impact for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Sep 2007 07:29:48 -0000 FYI: Network Appliance suing Sun over ZFS http://blogs.netapp.com/dave/2007/09/netapp-sues-sun.html -- JS From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 12:42:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8B0716A46C for ; Thu, 6 Sep 2007 12:42:07 +0000 (UTC) (envelope-from marsgmiro@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5B95613C478 for ; Thu, 6 Sep 2007 12:42:07 +0000 (UTC) (envelope-from marsgmiro@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so122363nfd for ; Thu, 06 Sep 2007 05:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=EUvjpS6d46EZeinZzhzY++vepZXWn36Y4xaa0Ff+kcY=; b=swfkl+TWgTVX5OYKUe4xFg7IlhjEcixVloZ3oev/SrxPVHO+AaaGVCZvPeyXiYPDRYx6vPfh/iZEnXTXkhYuiPiRK7msFKLviaVPN8QjbKPLeDrSA8EZlKVBjYm3jIJvOBxkQeu5t/u93Jku0d189FJyRU/AuOrJU5l7LjcXOdc= 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=TX+Mv9+dQJXHjklCjb8xuC1NWN3c4fgTBRoQ+ZXHmbOOIIdebj7GRSYZYYCcBC9y9K+8B0d36SBoeBXlotZygaGNeLchyynuuESvL+amlZhRcRLgpvBZyL36BYyLhXrGB9UFz1QVo+QKieeZgJG0zs2n8Keu39VqLDCinrsnj6U= Received: by 10.78.107.8 with SMTP id f8mr283622huc.1189081012107; Thu, 06 Sep 2007 05:16:52 -0700 (PDT) Received: by 10.78.137.16 with HTTP; Thu, 6 Sep 2007 05:16:45 -0700 (PDT) Message-ID: <28edec3c0709060516y3494c581ka0d130e62008d89f@mail.gmail.com> Date: Thu, 6 Sep 2007 20:16:45 +0800 From: "Mars G. Miro" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: Invalid checksum for 7.0-CURRENT-200708-i386-disc1.iso ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Sep 2007 12:42:07 -0000 Greetz! CHECKSUM.SHA256 sez: SHA256 (7.0-CURRENT-200708-i386-disc1.iso) = 57e136c952d01ef1ede483568da9b1b7be61f313f1c85dd1b9af556ad35290b8 but I get: SHA256 (7.0-CURRENT-200708-i386-disc1.iso) = 92e20ddc4379da85045883f39f86e341d01b9bf6ecec30de2e53d5346016ab7c I've already downloaded twice. Thanks. cheers mars From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 06:31:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C29E016A419; Fri, 7 Sep 2007 06:31:15 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC8113C459; Fri, 7 Sep 2007 06:31:14 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 819FD1CC0F6; Fri, 7 Sep 2007 08:31:11 +0200 (CEST) Received: by coruscant.local (Postfix, from userid 502) id 664CD60A14D; Fri, 7 Sep 2007 08:31:10 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070905141759.GJ12013@garage.freebsd.pl> <20070905171741.GA15709@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Fri, 07 Sep 2007 08:31:09 +0200 In-Reply-To: <20070905171741.GA15709@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed\, 5 Sep 2007 19\:17\:41 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Sep 2007 06:31:15 -0000 Pawel Jakub Dawidek writes: > On Wed, Sep 05, 2007 at 05:25:09PM +0200, Kenneth Vestergaard Schmidt wrote: >> Pawel Jakub Dawidek writes: >> >> I could use some pointers on what to do - is there some way I can debug >> >> this better, maybe give some better info? >> > >> > Try disabling ZIL. This looks like a bug was already reported by Kris. >> > This was already reported to OpenSolaris. >> >> We disabled ZIL, but the bug crept up again. I've just now rebooted the >> machine with DDB-support, so I can get some more info, per Kris's mail. That would be Kip's mail. >> The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv)' >> - it cycles between RUN, CPUx and this one. > > Hmm, this means it didn't deadlock... Here's some debugging output. PIDs 14870, 14933 and 12458 are just spinning and being useless. Funnily, all three have rename() in their backtrace. db> ps pid ppid pgrp uid state wmesg wchan cmd 20724 20720 20724 0 R+ CPU 0 sysctl 20720 1012 20720 0 S+ pause 0xd1e1a864 csh 20421 948 948 125 S kqread 0xc9ad1600 pickup 14933 14931 4351 0 R rsync 14932 14931 4351 0 S select 0xc07d68b8 ssh 14931 14930 4351 0 S select 0xc07d68b8 rsync 14930 14661 4351 0 S wait 0xd1c2b804 sh 14870 14866 4351 0 S zfs:(&tx 0xc73e6f24 rsync 14867 14866 4351 0 S select 0xc07d68b8 ssh 14866 14865 4351 0 S select 0xc07d68b8 rsync 14865 14856 4351 0 S wait 0xd26c62ac sh 14856 4355 4351 0 S piperd 0xc8f94630 perl5.8.8 14661 4355 4351 0 S piperd 0xd1fcb630 perl5.8.8 12458 12457 4351 0 R rsync 12457 12397 4351 0 S select 0xc07d68b8 rsync 12397 4355 4351 0 S piperd 0xd2090dec perl5.8.8 4360 4357 4357 0 S piperd 0xd1d55630 postdrop 4357 4348 4357 0 Ss piperd 0xd1fcbdec sendmail 4355 4354 4351 0 S wait 0xd20b0000 perl5.8.8 4354 4351 4351 0 S wait 0xd2050804 perl5.8.8 4351 4348 4351 0 Ss wait 0xd20482ac sh 4348 970 970 0 S piperd 0xc741d318 cron 1013 1 1 0 S nanslp 0xc07d07e4 getty 1012 1 1012 0 Ss+ wait 0xd1c2c000 login 1011 1 1011 0 Ss+ ttyin 0xc71d6410 getty 1010 1 1010 0 Ss+ ttyin 0xc71c5410 getty 995 1 995 0 Ss select 0xc07d68b8 inetd 970 1 970 0 Ss nanslp 0xc07d07e4 cron 963 1 963 0 Ss select 0xc07d68b8 sshd 957 948 948 125 S kqread 0xd1eff480 qmgr 948 1 948 0 Ss kqread 0xd1e14e80 master 866 1 866 0 Ss select 0xc07d68b8 ntpd 776 1 776 0 Ss select 0xc07d68b8 syslogd 721 1 721 0 Ss select 0xc07d68b8 devd 360 0 0 0 SL zfs:(&tq 0xd151877c [zil_clean] 359 0 0 0 SL zfs:(&tq 0xd1518848 [zil_clean] 358 0 0 0 SL zfs:(&tq 0xd1518914 [zil_clean] 357 0 0 0 SL zfs:(&tq 0xd15189e0 [zil_clean] 356 0 0 0 SL zfs:(&tq 0xd1518aac [zil_clean] 355 0 0 0 SL zfs:(&tq 0xd1518b78 [zil_clean] 354 0 0 0 SL zfs:(&tq 0xd10ba1e8 [zil_clean] 353 0 0 0 SL zfs:(&tq 0xd10ba2b4 [zil_clean] 352 0 0 0 SL zfs:(&tq 0xd10ba380 [zil_clean] 351 0 0 0 SL zfs:(&tq 0xd1518c44 [zil_clean] 350 0 0 0 SL zfs:(&tq 0xd1518d10 [zil_clean] 349 0 0 0 SL zfs:(&tq 0xd1518ddc [zil_clean] 348 0 0 0 SL zfs:(&tq 0xd1518ea8 [zil_clean] 347 0 0 0 SL zfs:(&tq 0xd1849050 [zil_clean] 346 0 0 0 SL zfs:(&tq 0xd184911c [zil_clean] 345 0 0 0 SL zfs:(&tq 0xd18491e8 [zil_clean] 344 0 0 0 SL zfs:(&tq 0xd10ba44c [zil_clean] 343 0 0 0 SL zfs:(&tq 0xd18492b4 [zil_clean] 342 0 0 0 SL zfs:(&tq 0xd10ba518 [zil_clean] 341 0 0 0 SL zfs:(&tq 0xd10ba5e4 [zil_clean] 340 0 0 0 SL zfs:(&tq 0xd1849380 [zil_clean] 339 0 0 0 SL zfs:(&tq 0xd184944c [zil_clean] 338 0 0 0 SL zfs:(&tq 0xd10ba6b0 [zil_clean] 337 0 0 0 SL zfs:(&tq 0xd10ba77c [zil_clean] 336 0 0 0 SL zfs:(&tq 0xd1849518 [zil_clean] 335 0 0 0 SL zfs:(&tq 0xd18495e4 [zil_clean] 334 0 0 0 SL zfs:(&tq 0xd10ba848 [zil_clean] 333 0 0 0 SL zfs:(&tq 0xd18496b0 [zil_clean] 332 0 0 0 SL zfs:(&tq 0xd184977c [zil_clean] 331 0 0 0 SL zfs:(&tq 0xd1849848 [zil_clean] 330 0 0 0 SL zfs:(&tq 0xd1849914 [zil_clean] 329 0 0 0 SL zfs:(&tq 0xd10ba914 [zil_clean] 328 0 0 0 SL zfs:(&tq 0xd18499e0 [zil_clean] 327 0 0 0 SL zfs:(&tq 0xd1849aac [zil_clean] 326 0 0 0 SL zfs:(&tq 0xd1849b78 [zil_clean] 325 0 0 0 SL zfs:(&tq 0xd10ba9e0 [zil_clean] 324 0 0 0 SL zfs:(&tq 0xd1849c44 [zil_clean] 323 0 0 0 SL zfs:(&tq 0xd1849d10 [zil_clean] 322 0 0 0 SL zfs:(&tq 0xd10baaac [zil_clean] 321 0 0 0 SL zfs:(&tq 0xd0c77848 [zil_clean] 320 0 0 0 SL zfs:(&tq 0xd10bab78 [zil_clean] 319 0 0 0 SL zfs:(&tq 0xd0c77914 [zil_clean] 318 0 0 0 SL zfs:(&tq 0xd0c779e0 [zil_clean] 317 0 0 0 SL zfs:(&tq 0xd0c77aac [zil_clean] 316 0 0 0 SL zfs:(&tq 0xd10bac44 [zil_clean] 315 0 0 0 SL zfs:(&tq 0xd0c77b78 [zil_clean] 314 0 0 0 SL zfs:(&tq 0xd10bad10 [zil_clean] 313 0 0 0 SL zfs:(&tq 0xd0c77c44 [zil_clean] 312 0 0 0 SL zfs:(&tq 0xd0c77d10 [zil_clean] 311 0 0 0 SL zfs:(&tq 0xd0c77ddc [zil_clean] 310 0 0 0 SL zfs:(&tq 0xd10baddc [zil_clean] 309 0 0 0 SL zfs:(&tq 0xd10baea8 [zil_clean] 308 0 0 0 SL zfs:(&tq 0xd1518050 [zil_clean] 307 0 0 0 SL zfs:(&tq 0xd151811c [zil_clean] 306 0 0 0 SL zfs:(&tq 0xd15181e8 [zil_clean] 305 0 0 0 SL zfs:(&tq 0xd0c77ea8 [zil_clean] 304 0 0 0 SL zfs:(&tq 0xd0ea7050 [zil_clean] 303 0 0 0 SL zfs:(&tq 0xd15182b4 [zil_clean] 302 0 0 0 SL zfs:(&tq 0xd1518380 [zil_clean] 301 0 0 0 SL zfs:(&tq 0xd151844c [zil_clean] 300 0 0 0 SL zfs:(&tq 0xd1518518 [zil_clean] 299 0 0 0 SL zfs:(&tq 0xd15185e4 [zil_clean] 298 0 0 0 SL zfs:(&tq 0xd15186b0 [zil_clean] 297 0 0 0 SL zfs:(&tq 0xd0ea7c44 [zil_clean] 296 0 0 0 SL zfs:(&tq 0xd0ea7d10 [zil_clean] 295 0 0 0 SL zfs:(&tq 0xd0ea7ddc [zil_clean] 294 0 0 0 SL zfs:(&tq 0xd0ea7ea8 [zil_clean] 293 0 0 0 SL zfs:(&tq 0xd0ea711c [zil_clean] 292 0 0 0 SL zfs:(&tq 0xd10b9050 [zil_clean] 291 0 0 0 SL zfs:(&tq 0xd10b911c [zil_clean] 290 0 0 0 SL zfs:(&tq 0xd0ea71e8 [zil_clean] 289 0 0 0 SL zfs:(&tq 0xd0ea72b4 [zil_clean] 288 0 0 0 SL zfs:(&tq 0xd10b91e8 [zil_clean] 287 0 0 0 SL zfs:(&tq 0xd0ea7380 [zil_clean] 286 0 0 0 SL zfs:(&tq 0xd10b92b4 [zil_clean] 285 0 0 0 SL zfs:(&tq 0xd0ea744c [zil_clean] 284 0 0 0 SL zfs:(&tq 0xd10b9380 [zil_clean] 283 0 0 0 SL zfs:(&tq 0xd0ea7518 [zil_clean] 282 0 0 0 SL zfs:(&tq 0xd0ea75e4 [zil_clean] 281 0 0 0 SL zfs:(&tq 0xd10b944c [zil_clean] 280 0 0 0 SL zfs:(&tq 0xd10b9518 [zil_clean] 279 0 0 0 SL zfs:(&tq 0xd10b95e4 [zil_clean] 278 0 0 0 SL zfs:(&tq 0xd10b96b0 [zil_clean] 277 0 0 0 SL zfs:(&tq 0xd10b977c [zil_clean] 276 0 0 0 SL zfs:(&tq 0xd10b9848 [zil_clean] 275 0 0 0 SL zfs:(&tq 0xd0ea76b0 [zil_clean] 274 0 0 0 SL zfs:(&tq 0xd10b9914 [zil_clean] 273 0 0 0 SL zfs:(&tq 0xd10b99e0 [zil_clean] 272 0 0 0 SL zfs:(&tq 0xd10b9aac [zil_clean] 271 0 0 0 SL zfs:(&tq 0xd10b9b78 [zil_clean] 270 0 0 0 SL zfs:(&tq 0xd10b9c44 [zil_clean] 269 0 0 0 SL zfs:(&tq 0xd10b9d10 [zil_clean] 268 0 0 0 SL zfs:(&tq 0xd10b9ddc [zil_clean] 267 0 0 0 SL zfs:(&tq 0xd10b9ea8 [zil_clean] 266 0 0 0 SL zfs:(&tq 0xd0ea777c [zil_clean] 265 0 0 0 SL zfs:(&tq 0xd10ba050 [zil_clean] 264 0 0 0 SL zfs:(&tq 0xd10ba11c [zil_clean] 263 0 0 0 SL zfs:(&tq 0xd0ea7848 [zil_clean] 262 0 0 0 SL zfs:(&tq 0xd08c7518 [zil_clean] 261 0 0 0 SL zfs:(&tq 0xd08c75e4 [zil_clean] 260 0 0 0 SL zfs:(&tq 0xd08c76b0 [zil_clean] 259 0 0 0 SL zfs:(&tq 0xd08c777c [zil_clean] 258 0 0 0 SL zfs:(&tq 0xd08c7848 [zil_clean] 257 0 0 0 SL zfs:(&tq 0xd08c7914 [zil_clean] 256 0 0 0 SL zfs:(&tq 0xd08c79e0 [zil_clean] 255 0 0 0 SL zfs:(&tq 0xd08c7aac [zil_clean] 254 0 0 0 SL zfs:(&tq 0xd0ea7914 [zil_clean] 253 0 0 0 SL zfs:(&tq 0xd0ea79e0 [zil_clean] 252 0 0 0 SL zfs:(&tq 0xd08c7b78 [zil_clean] 251 0 0 0 SL zfs:(&tq 0xd08c7c44 [zil_clean] 250 0 0 0 SL zfs:(&tq 0xd08c7d10 [zil_clean] 249 0 0 0 SL zfs:(&tq 0xd0ea7aac [zil_clean] 248 0 0 0 SL zfs:(&tq 0xd08c7ddc [zil_clean] 247 0 0 0 SL zfs:(&tq 0xd0ea7b78 [zil_clean] 246 0 0 0 SL zfs:(&tq 0xd08c7ea8 [zil_clean] 245 0 0 0 SL zfs:(&tq 0xc75d3ddc [zil_clean] 244 0 0 0 SL zfs:(&tq 0xd0c77050 [zil_clean] 243 0 0 0 SL zfs:(&tq 0xd0c7711c [zil_clean] 242 0 0 0 SL zfs:(&tq 0xc75d3d10 [zil_clean] 241 0 0 0 SL zfs:(&tq 0xd0c771e8 [zil_clean] 240 0 0 0 SL zfs:(&tq 0xc75d3b78 [zil_clean] 239 0 0 0 SL zfs:(&tq 0xc75d3aac [zil_clean] 238 0 0 0 SL zfs:(&tq 0xd0c772b4 [zil_clean] 237 0 0 0 SL zfs:(&tq 0xd0c77380 [zil_clean] 236 0 0 0 SL zfs:(&tq 0xd0c7744c [zil_clean] 235 0 0 0 SL zfs:(&tq 0xc75d39e0 [zil_clean] 234 0 0 0 SL zfs:(&tq 0xd0c77518 [zil_clean] 233 0 0 0 SL zfs:(&tq 0xd0c775e4 [zil_clean] 232 0 0 0 SL zfs:(&tq 0xc75d3914 [zil_clean] 231 0 0 0 SL zfs:(&tq 0xd0c776b0 [zil_clean] 230 0 0 0 SL zfs:(&tq 0xc75d3848 [zil_clean] 229 0 0 0 SL zfs:(&tq 0xd0c7777c [zil_clean] 228 0 0 0 SL zfs:(&tq 0xc7a6c2b4 [zil_clean] 227 0 0 0 SL zfs:(&tq 0xc75d36b0 [zil_clean] 226 0 0 0 SL zfs:(&tq 0xc75d35e4 [zil_clean] 225 0 0 0 SL zfs:(&tq 0xc7a6c380 [zil_clean] 224 0 0 0 SL zfs:(&tq 0xc75d411c [zil_clean] 223 0 0 0 SL zfs:(&tq 0xc7a6c44c [zil_clean] 222 0 0 0 SL zfs:(&tq 0xc7a6c518 [zil_clean] 221 0 0 0 SL zfs:(&tq 0xc7a6c5e4 [zil_clean] 220 0 0 0 SL zfs:(&tq 0xc7a6c6b0 [zil_clean] 219 0 0 0 SL zfs:(&tq 0xc75d41e8 [zil_clean] 218 0 0 0 SL zfs:(&tq 0xc7a6c77c [zil_clean] 217 0 0 0 SL zfs:(&tq 0xc7a6c848 [zil_clean] 216 0 0 0 SL zfs:(&tq 0xc75d42b4 [zil_clean] 215 0 0 0 SL zfs:(&tq 0xc7a6c914 [zil_clean] 214 0 0 0 SL zfs:(&tq 0xc7a6c9e0 [zil_clean] 213 0 0 0 SL zfs:(&tq 0xc75d4380 [zil_clean] 212 0 0 0 SL zfs:(&tq 0xc7a6caac [zil_clean] 211 0 0 0 SL zfs:(&tq 0xc75d444c [zil_clean] 210 0 0 0 SL zfs:(&tq 0xc7a6cb78 [zil_clean] 209 0 0 0 SL zfs:(&tq 0xc7a6cc44 [zil_clean] 208 0 0 0 SL zfs:(&tq 0xc7a6cd10 [zil_clean] 207 0 0 0 SL zfs:(&tq 0xc75d4518 [zil_clean] 206 0 0 0 SL zfs:(&tq 0xc7a6cddc [zil_clean] 205 0 0 0 SL zfs:(&tq 0xc7a6cea8 [zil_clean] 204 0 0 0 SL zfs:(&tq 0xd08c7050 [zil_clean] 203 0 0 0 SL zfs:(&tq 0xd08c711c [zil_clean] 202 0 0 0 SL zfs:(&tq 0xd08c71e8 [zil_clean] 201 0 0 0 SL zfs:(&tq 0xd08c72b4 [zil_clean] 200 0 0 0 SL zfs:(&tq 0xd08c7380 [zil_clean] 199 0 0 0 SL zfs:(&tq 0xd08c744c [zil_clean] 198 0 0 0 SL zfs:(&tq 0xc75d3ea8 [zil_clean] 197 0 0 0 SL zfs:(&tq 0xc75d3c44 [zil_clean] 196 0 0 0 SL zfs:(&tq 0xc75d377c [zil_clean] 195 0 0 0 SL zfs:(&tq 0xc75d3050 [zil_clean] 194 0 0 0 SL zfs:(&tq 0xc75d311c [zil_clean] 193 0 0 0 SL zfs:(&tq 0xc75d31e8 [zil_clean] 192 0 0 0 SL zfs:(&tq 0xc75d45e4 [zil_clean] 191 0 0 0 SL zfs:(&tq 0xc75d46b0 [zil_clean] 189 0 0 0 SL zfs:(&tq 0xc75d477c [zil_clean] 188 0 0 0 SL zfs:(&tq 0xc75d32b4 [zil_clean] 187 0 0 0 SL zfs:(&tq 0xc75d3380 [zil_clean] 186 0 0 0 SL zfs:(&tq 0xc75d344c [zil_clean] 185 0 0 0 SL zfs:(&tq 0xc75d3518 [zil_clean] 183 0 0 0 SL zfs:(&tx 0xc73e6f2c [txg_thread_enter] 182 0 0 0 SL zfs:(&tx 0xc73e6f0c [txg_thread_enter] 181 0 0 0 RL [txg_thread_enter] 180 0 0 0 SL vgeom:io 0xc73d8a08 [vdev:worker da11] 179 0 0 0 SL vgeom:io 0xc73d89c8 [vdev:worker da10] 178 0 0 0 SL vgeom:io 0xc73d8948 [vdev:worker da9] 177 0 0 0 SL vgeom:io 0xc7a1c748 [vdev:worker da8] 176 0 0 0 SL vgeom:io 0xc73d8888 [vdev:worker da7] 175 0 0 0 SL vgeom:io 0xc73d8848 [vdev:worker da6] 174 0 0 0 SL vgeom:io 0xc73d7848 [vdev:worker da5] 175 0 0 0 SL vgeom:io 0xc73d8848 [vdev:worker da6] 174 0 0 0 SL vgeom:io 0xc73d7848 [vdev:worker da5] 173 0 0 0 SL vgeom:io 0xc73d8788 [vdev:worker da4] 172 0 0 0 SL vgeom:io 0xc73d8708 [vdev:worker da3] 171 0 0 0 SL vgeom:io 0xc7a1c9c8 [vdev:worker da2] 170 0 0 0 SL vgeom:io 0xc7a1cdc8 [vdev:worker da1] 169 0 0 0 SL vgeom:io 0xc7a1cbc8 [vdev:worker da0] 168 0 0 0 SL zfs:(&tq 0xc75d4848 [spa_zio_intr_5] 167 0 0 0 SL zfs:(&tq 0xc75d4848 [spa_zio_intr_5] 166 0 0 0 SL zfs:(&tq 0xc75d4914 [spa_zio_issue_5] 165 0 0 0 SL zfs:(&tq 0xc75d4914 [spa_zio_issue_5] 164 0 0 0 SL zfs:(&tq 0xc75d49e0 [spa_zio_intr_4] 163 0 0 0 SL zfs:(&tq 0xc75d49e0 [spa_zio_intr_4] 162 0 0 0 SL zfs:(&tq 0xc75d4aac [spa_zio_issue_4] 161 0 0 0 SL zfs:(&tq 0xc75d4aac [spa_zio_issue_4] 160 0 0 0 SL zfs:(&tq 0xc75d4b78 [spa_zio_intr_3] 159 0 0 0 SL zfs:(&tq 0xc75d4b78 [spa_zio_intr_3] 158 0 0 0 SL zfs:(&tq 0xc75d4c44 [spa_zio_issue_3] 157 0 0 0 SL zfs:(&tq 0xc75d4c44 [spa_zio_issue_3] 156 0 0 0 SL zfs:(&tq 0xc75d4d10 [spa_zio_intr_2] 155 0 0 0 SL zfs:(&tq 0xc75d4d10 [spa_zio_intr_2] 154 0 0 0 SL zfs:(&tq 0xc75d4ddc [spa_zio_issue_2] 153 0 0 0 SL zfs:(&tq 0xc75d4ddc [spa_zio_issue_2] 152 0 0 0 SL zfs:(&tq 0xc75d4ea8 [spa_zio_intr_1] 151 0 0 0 SL zfs:(&tq 0xc75d4ea8 [spa_zio_intr_1] 150 0 0 0 SL zfs:(&tq 0xc7a6c050 [spa_zio_issue_1] 149 0 0 0 SL zfs:(&tq 0xc7a6c050 [spa_zio_issue_1] 148 0 0 0 SL zfs:(&tq 0xc7a6c11c [spa_zio_intr_0] 147 0 0 0 SL zfs:(&tq 0xc7a6c11c [spa_zio_intr_0] 146 0 0 0 SL zfs:(&tq 0xc7a6c1e8 [spa_zio_issue_0] 145 0 0 0 SL zfs:(&tq 0xc7a6c1e8 [spa_zio_issue_0] 108 0 0 0 SL zfs:(&ar 0xc759440c [arc_reclaim_thread] 105 0 0 0 SL zfs:(&tq 0xc75d4050 [system_taskq] 104 0 0 0 SL zfs:(&tq 0xc75d4050 [system_taskq] 43 0 0 0 SL - 0xc07d0614 [schedcpu] 42 0 0 0 SL sdflush 0xc07dbb24 [softdepflush] 41 0 0 0 SL syncer 0xc07d060c [syncer] 40 0 0 0 SL vlruwt 0xc71c7000 [vnlru] 39 0 0 0 SL psleep 0xc07d6d44 [bufdaemon] 38 0 0 0 SL pgzero 0xc07dc5d8 [pagezero] 37 0 0 0 SL psleep 0xc07dc2f4 [vmdaemon] 36 0 0 0 SL psleep 0xc07dc2bc [pagedaemon] 35 0 0 0 SL pftm 0xc047ab60 [pfpurge] 34 0 0 0 WL [irq12: psm0] 33 0 0 0 WL [irq1: atkbd0] 32 0 0 0 LL *Giant 0xc7088550 [swi0: sio] 31 0 0 0 SL - 0xc715043c [fdc0] 30 0 0 0 WL [irq25: bge1] 29 0 0 0 WL [irq24: bge0] 28 0 0 0 WL [irq18: ips0] 27 0 0 0 SL idle 0xc71962e4 [mpt_raid0] 26 0 0 0 SL idle 0xc7196000 [mpt_recovery0] 25 0 0 0 WL [irq22: mpt0] 24 0 0 0 WL [irq15: ata1] 23 0 0 0 WL [irq14: ata0] 22 0 0 0 WL [irq7: acpi0] 21 0 0 0 WL [swi2: cambio] 20 0 0 0 SL ccb_scan 0xc07b82f4 [xpt_thrd] 19 0 0 0 WL [swi6: task queue] 18 0 0 0 WL [swi6: Giant taskq] 9 0 0 0 SL - 0xc70e4e80 [thread taskq] 17 0 0 0 WL [swi5: +] 8 0 0 0 SL - 0xc70fb100 [acpi_task_2] 7 0 0 0 SL - 0xc70fb100 [acpi_task_1] 6 0 0 0 SL - 0xc70fb100 [acpi_task_0] 5 0 0 0 SL - 0xc70fb200 [kqueue taskq] 16 0 0 0 SL - 0xc07d0614 [yarrow] 4 0 0 0 SL - 0xc07ce6ec [g_down] 3 0 0 0 SL - 0xc07ce6e8 [g_up] 2 0 0 0 SL - 0xc07ce6e0 [g_event] 15 0 0 0 WL [swi1: net] 14 0 0 0 WL [swi3: vm] 13 0 0 0 RL CPU 1 [swi4: clock sio] 12 0 0 0 RL [idle: cpu0] 11 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xc709dab0 [init] 10 0 0 0 SL audit_wo 0xc07db588 [audit] 0 0 0 0 WLs [swapper] db> show proc 14870 Process 14870 (rsync) at 0xd26c3ab0: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 14866 at 0xd1c2bab0 ABI: FreeBSD ELF32 arguments: /usr/local/bin/rsync threads: 1 100379 D zfs:(&tx 0xc73e6f24 rsync db> thread 100379 [thread pid 14870 tid 100379 ] sched_switch+0x19d: testb $0x20,0x68(%esi) db> bt Tracing pid 14870 tid 100379 td 0xd26c4e00 sched_switch(d26c4e00,0,1,181d9d4,8567e45,...) at sched_switch+0x19d mi_switch(1,0,d26c4e00,fc81da0c,c05b08c6,...) at mi_switch+0x146 sleepq_switch(d26c4e00,0,c07640c2,21b,0,...) at sleepq_switch+0x7f sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c txg_wait_open(c73e6e00,4b65728e,0,d5,c88e3bfc,...) at txg_wait_open+0xd5 dmu_tx_wait(d0fe6800,2,0,0,0,...) at dmu_tx_wait+0xe0 zfs_freebsd_rename(fc81dba4,fc81db7c,fc81dbc0,fc81dc0c,fc81dc68,...) at zfs_freebsd_rename+0x41e VOP_RENAME_APV(c7592e00,fc81dba4,101,c05ee4d5,5009c10,...) at VOP_RENAME_APV+0x46 kern_rename(d26c4e00,bfbfd0c8,bfbfd8c8,0,fc81dd2c,...) at kern_rename+0x2e1 rename(d26c4e00,fc81dcfc,8,0,5a0a382,...) at rename+0x29 syscall(fc81dd38) at syscall+0x305 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcbbc, ebp = 0xbfbfcbc8 --- db> show proc 14933 Process 14933 (rsync) at 0xd1f752ac: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 14931 at 0xd1f6bab0 ABI: FreeBSD ELF32 arguments: /usr/local/bin/rsync threads: 1 100321 RunQ rsync db> thread 100321 [thread pid 14933 tid 100321 ] sched_switch+0x19d: testb $0x20,0x68(%esi) db> bt Tracing pid 14933 tid 100321 td 0xd1f72200 sched_switch(d1f72200,0,1,173a9d4,8567e2f,...) at sched_switch+0x19d mi_switch(1,0,d1f72200,fc73aa0c,c05b08c6,...) at mi_switch+0x146 sleepq_switch(d1f72200,0,c07640c2,21b,0,...) at sleepq_switch+0x7f sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c txg_wait_open(c73e6e00,4b657007,0,d5,d91633b0,...) at txg_wait_open+0xd5 dmu_tx_wait(d160bd00,2,0,0,0,...) at dmu_tx_wait+0xe0 zfs_freebsd_rename(fc73aba4,fc73ab7c,fc73abc0,fc73ac0c,fc73ac68,...) at zfs_freebsd_rename+0x41e VOP_RENAME_APV(c7592e00,fc73aba4,101,119,5009c10,...) at VOP_RENAME_APV+0x46 kern_rename(d1f72200,bfbfd0c8,bfbfd8c8,0,fc73ad2c,...) at kern_rename+0x2e1 rename(d1f72200,fc73acfc,8,d1f72200,fc73ad2c,...) at rename+0x29 syscall(fc73ad38) at syscall+0x305 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcbbc, ebp = 0xbfbfcbc8 --- db> show proc 12458 Process 12458 (rsync) at 0xd1e1c804: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 12457 at 0xd1c2dab0 ABI: FreeBSD ELF32 arguments: /usr/local/bin/rsync threads: 1 100293 RunQ rsync db> thread 100293 [thread pid 12458 tid 100293 ] sched_switch+0x19d: testb $0x20,0x68(%esi) db> bt Tracing pid 12458 tid 100293 td 0xd18c5a00 sched_switch(d18c5a00,0,1,15d29d4,858acc6,...) at sched_switch+0x19d mi_switch(1,0,d18c5a00,fc5d2a0c,c05b08c6,...) at mi_switch+0x146 sleepq_switch(d18c5a00,0,c07640c2,21b,0,...) at sleepq_switch+0x7f sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c txg_wait_open(c73e6e00,4b7d2f7f,0,d5,d26010ec,...) at txg_wait_open+0xd5 dmu_tx_wait(c987f980,2,0,0,0,...) at dmu_tx_wait+0xe0 zfs_freebsd_rename(fc5d2ba4,fc5d2b7c,fc5d2bc0,fc5d2c0c,fc5d2c68,...) at zfs_freebsd_rename+0x41e VOP_RENAME_APV(c7592e00,fc5d2ba4,101,c8c63c08,5009c10,...) at VOP_RENAME_APV+0x46 kern_rename(d18c5a00,bfbfd0a8,bfbfd8a8,0,fc5d2d2c,...) at kern_rename+0x2e1 rename(d18c5a00,fc5d2cfc,8,c714b400,7df1b67,...) at rename+0x29 syscall(fc5d2d38) at syscall+0x305 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcb9c, ebp = 0xbfbfcba8 --- /Kenneth From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 15:35:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A4D16A41B for ; Fri, 7 Sep 2007 15:35:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 587B813C4B5 for ; Fri, 7 Sep 2007 15:35:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l87F02Qo018991 for ; Fri, 7 Sep 2007 17:00:09 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l87F02js018987 for freebsd-current@freebsd.org; Fri, 7 Sep 2007 17:00:02 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200709071500.l87F02js018987@lurza.secnetix.de> To: freebsd-current@freebsd.org Date: Fri, 7 Sep 2007 17:00:02 +0200 (CEST) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 07 Sep 2007 17:00:10 +0200 (CEST) X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org, olli@secnetix.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, 07 Sep 2007 15:35:28 -0000 Hi, This started to happen after updating to a recent 7-current about one week ago (it was working fine with a previous 7- current that was a few weeks older). The shell is zsh. zsh$ /usr/bin/su /libexec/ld-elf.so.1: environment corrupt; missing value for zsh$ So su(1) fails to start. Interestingly, when I first start an sh shell, I still get the same error message, but the shell starts anyway. Then I can use su(1) without problems: zsh$ sh sh: environment corrupt; missing value for $ /usr/bin/su Password: It was my impression that there should be more printed in the error message after "missing value for", so I made a hexdump: 6e 67 20 76 61 6c 75 65 20 66 6f 72 20 1b 5b 34 |ng value for .[4| 7e 0a |~.| Sure enough, my environment _does_ seem to be corrupt when I look at the output of env(1): There are several empty lines and some lines with random garbage characters and control characters. However, after starting sh, the garbage is gone. So sh seems to "repair" it somehow. Is this a bug in -current's environment handling? Or is it a bug in zsh that has only been triggered by recent changes in FreeBSD -current? Note that I use exactly the same zsh version and exactly the same zsh start profiles (i.e. basically the same environment contents) on a large number of machines, FreeBSD and other, and this problem _only_ exists on a recent FreeBSD 7-current. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 16:23:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E53516A419 for ; Fri, 7 Sep 2007 16:23:12 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from mail.integrity.hu (mail.integrity.hu [195.56.44.40]) by mx1.freebsd.org (Postfix) with SMTP id DBE9713C46C for ; Fri, 7 Sep 2007 16:23:11 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: (qmail 22465 invoked by uid 89); 7 Sep 2007 18:23:10 +0200 Message-ID: <20070907162310.22464.qmail@mail.integrity.hu> From: "Zahemszky Gabor" To: freebsd-current@freebsd.org Date: Fri, 07 Sep 2007 18:23:10 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2"; format=flowed Content-Transfer-Encoding: 7bit X-Sender: gabor@zahemszky.hu X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: Claws-mail - core dumped X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Sep 2007 16:23:12 -0000 Hi! Are there anybody out there, who can use - either the old (2.10) or the new (3.0) version of Claws-Mail n CURRENT? I used it from 1st January without any problem, but 2 or 3 weeks ago, it once dumped core, and since then, I cannot write letter with it. I can start it, I can read (and download) my mails from the server, but pressing the "New mail" or the "Reply" button generates a core dump. I tried it with old mails in ~/Mail and with the original ~/.claws-mail , and with/out the one or the other, doesn't matter. I recompiled it (recursively with portmaster -f ), upgraded it, the same. Anybody has any clue? Thanks, Zahy < Gabor at Zahemszky dot HU > PS: one of my CURRENT-running friends tried it. Installed it, and get the same -> sending mail generates a core. From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 15:06:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 248E816A421 for ; Sat, 8 Sep 2007 15:06:42 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from mail01a.mail.t-online.hu (mail01a.mail.t-online.hu [84.2.40.6]) by mx1.freebsd.org (Postfix) with ESMTP id B931113C49D for ; Sat, 8 Sep 2007 15:06:41 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from Picasso.Zahemszky.HU (dsl51B6CDF1.pool.t-online.hu [81.182.205.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail01a.mail.t-online.hu (Postfix) with ESMTP id E95EE13696A for ; Sat, 8 Sep 2007 16:40:08 +0200 (CEST) Date: Sat, 8 Sep 2007 16:40:03 +0200 From: Zahemszky =?ISO-8859-2?Q?G=E1bor?= To: freebsd-current@freebsd.org Message-ID: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> Organization: Zahemszky Bt. X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: crash (and the backtrace) in the new if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Sep 2007 15:06:42 -0000 Hi! I tried the new if_zyd driver with my new Lutec WLA-54L USB-stick on a today-based CURRENT. My machine recognised it correctly when I plugged in it: zyd0: on uhub2 zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:65:66:00 zyd0: Ethernet address: 00:02:72:65:66:00 But when I "ifconfig zyd0 up" -ed it, the machine crashed. Here is the backtrace of it: =3D=3D=3D=3D Picasso# kgdb -q kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] Unread portion of the kernel message buffer: panic: Bad list head 0xc519a6bc first->prev !=3D head cpuid =3D 1 KDB: enter: panic Physical memory: 2009 MB Dumping 76 MB: 61 45 29 13 (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc048cd99 in db_fncall (dummy1=3D-444823224, dummy2=3D0, dummy3=3D70, dummy4=3D0xe57c88b4 "@=F0H=C0") at /usr/src/sys/ddb/db_command.c:486 #2 0xc048d305 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #3 0xc048ea75 in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.c:222 #4 0xc07776d6 in kdb_trap (type=3D3, code=3D0, tf=3D0xe57c8a5c) at /usr/src/sys/kern/subr_kdb.c:502 #5 0xc0a0348b in trap (frame=3D0xe57c8a5c) at /usr/src/sys/i386/i386/trap.c:621 #6 0xc09e8eab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0777852 in kdb_enter (msg=3D0xc0a9b2f4 "panic") at cpufunc.h:60 #8 0xc0750a04 in panic (fmt=3D0xc0a55da3 "Bad list head %p first->prev !=3D head") at /usr/src/sys/kern/kern_shutdown.c:547 #9 0xc06a30aa in ehci_device_intr_start (xfer=3D0xc55b7e00) at /usr/src/sys/dev/usb/ehci.c:3266 #10 0xc06a3143 in ehci_device_intr_transfer (xfer=3D0xc55b7e00) at /usr/src/sys/dev/usb/ehci.c:3184 #11 0xc06d1d5b in usbd_start_transfer (arg=3D0xc55b7e00, segs=3D0xc5212800, nseg=3D1, error=3D0) at /usr/src/sys/dev/usb/usbdi.c:388 #12 0xc09e6155 in bus_dmamap_load (dmat=3D0xc51e7480, map=3D0xc0c182c0, buf=3D0xe57c8c0a, buflen=3D0,=20 callback=3D0xc06d1be0 , callback_arg=3D0xc55b7e00, flags=3D0) at /usr/src/sys/i386/i386/busdma_machdep.c:765 #13 0xc06d22a4 in usbd_transfer (xfer=3D0xc55b7e00) at /usr/src/sys/dev/usb/usbdi.c:312 #14 0xc06b599f in zyd_cmd (sc=3D0xc5ac3000, code=3DVariable "code" is not available. ) at /usr/src/sys/dev/usb/if_zyd.c:775 #15 0xc06b5d44 in zyd_read32 (sc=3DVariable "sc" is not available. ) at /usr/src/sys/dev/usb/if_zyd.c:819 #16 0xc06b5dc6 in zyd_lock_phy (sc=3D0xc5ac3000) at /usr/src/sys/dev/usb/if_zyd.c:876 #17 0xc06b7f7a in zyd_set_chan (sc=3D0xc5ac3000, c=3D0xc5ac33fc) at /usr/src/sys/dev/usb/if_zyd.c:1716 #18 0xc06b8206 in zyd_scantask (arg=3D0xc5ac3000) at /usr/src/sys/dev/usb/if_zyd.c:2675 #19 0xc06ce68a in usb_task_thread (arg=3D0xc0bafab4) at /usr/src/sys/dev/usb/usb.c:483 #20 0xc0732888 in fork_exit (callout=3D0xc06ce5c0 , arg=3D0xc0bafab4,=20 frame=3D0xe57c8d38) at /usr/src/sys/kern/kern_fork.c:797 #21 0xc09e8f20 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb)=20 =3D=3D=3D=3D By the way, If I boot the machine with the stick pushed in the USB-slot, I get the next error message: =3D=3D=3D=3D zyd0: on uhub2 zyd0: setting config no failed device_attach: zyd0 attach returned 6 =3D=3D=3D=3D And of course, there won't be a zyd0 interface. Can anybody help me to use it? Zahy < Gabor at Zahemszky dot HU > --=20 #!/bin/ksh Z=3D'21N16I25C25E30, 40M30E33E25T15U!';IFS=3D' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set -- $Z;for i;{ [[ $i =3D ? ]]&&print $i&&break;[[ $i =3D ??? ]]&&j=3D$i&&i=3D${i%?};typeset -i40 i=3D8#$i;print -n ${i#???};[[ "= $j" =3D ??? ]]&&print -n "${j#??} "&&j=3D;typeset +i i;};IFS=3D' 0123456789 ';s= et -- $Z;for i;{ [[ $i =3D , ]]&&i=3D2;[[ $i =3D ?? ]]||typeset -l i;j=3D"$j $i";typeset +l i;};print "$j" From owner-freebsd-current@FreeBSD.ORG Sat Sep 8 20:52:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15B0B16A41B for ; Sat, 8 Sep 2007 20:52:11 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36601.mail.mud.yahoo.com (web36601.mail.mud.yahoo.com [209.191.85.18]) by mx1.freebsd.org (Postfix) with SMTP id A9FF613C442 for ; Sat, 8 Sep 2007 20:52:10 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 77579 invoked by uid 60001); 8 Sep 2007 20:25:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nhBme3EjiTbHIi2/R+8PjfpKQ7K4yhRBOJEEfjNQg0GdAa+oV57/ra8gBciVjBnxbsTktrKeUktBkCcVLjQSswMOgdHgCQvOIz82QCjPUZRRwUc75rwkg8cuhDHe3Oyfr7zT9Xc2B8LcYFSOgFhFQ1QDM8CUi/8yYImM7AgXWz4=; X-YMail-OSG: RjcnoukVM1n.zOCFGoVJDRBbXTwct25rR84HcM6DCcxRfYRz.Dct9QXGPupedBY7GUtIJ8QsISN7UtukLgAIXGFmHU4R4yKZbMQOa_m.AVkYPuQ.trYR80pgJ8l_XA-- Received: from [85.10.53.18] by web36601.mail.mud.yahoo.com via HTTP; Sat, 08 Sep 2007 13:25:29 PDT Date: Sat, 8 Sep 2007 13:25:29 -0700 (PDT) From: Simun Mikecin To: peter.schuller@infidyne.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <855622.76488.qm@web36601.mail.mud.yahoo.com> X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Swapping on ZFS - stability issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Sep 2007 20:52:11 -0000 Peter Schuller wrote: >> I'll see if I can confirm behavior on a more recent CURRENT. The above was on=20 >> CURRENT:s from 1-2 months ago in both cases. > Confirmed on CURRENT cvsup:ed today (2007-09-08). However, the speed > at which swap was filling was much faster - on par with swap on > non-ZFS. But the machine still effectively froze, save the > console/ping, after a few seconds. > Also, I forgot to say this is all on amd64 machines. Try one of this (depends wheter you need encrypted swap or not): 1. create zvol with 4k blocksize instead of default 8k: zfs create -b 4k -V 4g tank/swap swapon /dev/zvol/tank/swap 2. use geli encrypted swap with a sectorsize of 4k: zfs create -V 4g tank/swap geli onetime -s 4096 /dev/zvol/tank/swap swapon /dev/zvol/tank/swap.eli ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 01:36:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A16F16A41B for ; Mon, 10 Sep 2007 01:36:29 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 0ADEC13C469 for ; Mon, 10 Sep 2007 01:36:28 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from ip-182.ish.com.au ([203.29.62.182]) by fish.ish.com.au with esmtpa (Exim 4.43) id 1IUXl4-0006pP-U6 for freebsd-current@freebsd.org; Mon, 10 Sep 2007 11:08:10 +1000 Mime-Version: 1.0 (Apple Message framework v752.2) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A1F9A6E-CA5B-4D40-8293-C16E4F6BDB17@ish.com.au> Content-Transfer-Encoding: 7bit From: Aristedes Maniatis Date: Mon, 10 Sep 2007 11:11:53 +1000 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Sep 2007 01:36:29 -0000 I don't want this to sound like a "is it ready yet?" email, but as we are rolling out some new servers in the next months I'd like to get some idea of whether it is time for us to start testing hardware and configurations against current, ready for deployment in the not distant future. In particular I am very interested in the excellent improvements for SMP and mysql performance. I understand that response 'version 7 will be released when it is ready', but looking at recent cvs commit messages I can't quite see the pattern of what new features are still going in and what is now bug fixes for release. I have some questions: * The bug reports at http://www.freebsd.org/cgi/query-pr-summary.cgi don't seem to correlate with activity on current. Is there a separate bug tracker so that users like myself can see what known bugs remain prior to release? Other open source projects I am affiliated with (for example those at Apache) use bug tracking databases in this way. * Is there a set release schedule and known bugs notes for snapshots? I'd like to try a snapshot but I don't know whether to wait a day/ week/month for the next one. Or are they released just when someone thinks the source is in a good overall state? Thank you Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 12:40:44 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA7916A41B for ; Mon, 10 Sep 2007 12:40:44 +0000 (UTC) (envelope-from mah@jump-ing.de) Received: from mail.ud03.udmedia.de (ud03.udmedia.de [194.117.254.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAF513C47E for ; Mon, 10 Sep 2007 12:40:43 +0000 (UTC) (envelope-from mah@jump-ing.de) Received: (qmail 777 invoked from network); 10 Sep 2007 14:14:03 +0200 Received: from unknown (HELO ?10.0.0.50?) (ud03?291p1@91.89.216.59) by mail.ud03.udmedia.de with ESMTPA; 10 Sep 2007 14:14:03 +0200 In-Reply-To: References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74423CD8-F9C1-454D-83BB-0114402C2CCC@jump-ing.de> Content-Transfer-Encoding: 7bit From: Markus Hitter Date: Mon, 10 Sep 2007 14:14:00 +0200 To: Danny Braniss X-Mailer: Apple Mail (2.752.2) X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: hackers@FreeBSD.org, freebsd-current@FreeBSD.org, 'cpghost' , 'Gavin Atkinson' Subject: Re: dump 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, 10 Sep 2007 12:40:44 -0000 Am 10.09.2007 um 10:14 schrieb Danny Braniss: > so here are some questions: > - is the readers/writer split realy needed now? my guess it was > put in in the old days to get tapes streaming - which is > btw, > what's not working. Before you put a lot of efforts into this: Why don't you just let dump/restore die and put functionality, which is needed and unique to dump, into tar? Tar is far more popular, today's world is multiplatform, today's world is multi-filesystem and if you rewrite dump, you force admins to rewrite their scripts anyways. I've always considered it as sub-optimal to have several tools for one task. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 10 16:27:38 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B76916A469 for ; Mon, 10 Sep 2007 16:27:38 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 78F4713C483 for ; Mon, 10 Sep 2007 16:27:37 +0000 (UTC) (envelope-from mwm@mired.org) Received: (qmail 76385 invoked from network); 10 Sep 2007 15:59:58 -0000 Received: from unknown (HELO mbook.mired.org) (192.168.195.2) by 0 with SMTP; 10 Sep 2007 15:59:58 -0000 Date: Mon, 10 Sep 2007 12:00:39 -0400 From: Mike Meyer To: Markus Hitter Message-ID: <20070910120039.3fc3917e@mbook.mired.org> In-Reply-To: <74423CD8-F9C1-454D-83BB-0114402C2CCC@jump-ing.de> References: <20070904233246.GA2409@epia-2.farid-hajji.net> <043a01c7f202$a7ad0920$f7071b60$@co.uk> <046801c7f229$a4534510$ecf9cf30$@co.uk> <74423CD8-F9C1-454D-83BB-0114402C2CCC@jump-ing.de> Organization: Meyer Consulting X-Mailer: Claws Mail 2.10.0 (GTK+ 2.6.10; i386-apple-darwin8.10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: hackers@FreeBSD.org, 'cpghost' , 'Gavin, freebsd-current@FreeBSD.org, Atkinson' Subject: Re: dump 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, 10 Sep 2007 16:27:38 -0000 On Mon, 10 Sep 2007 14:14:00 +0200 Markus Hitter wrote: > Am 10.09.2007 um 10:14 schrieb Danny Braniss: > > so here are some questions: > > - is the readers/writer split realy needed now? my guess it was > > put in in the old days to get tapes streaming - which is > > btw, > > what's not working. > Before you put a lot of efforts into this: Why don't you just let > dump/restore die and put functionality, which is needed and unique to > dump, into tar? Because doing that would require rewriting tar pretty much from the ground up? > Tar is far more popular, today's world is multiplatform, today's > world is multi-filesystem and if you rewrite dump, you force admins > to rewrite their scripts anyways. Tar is an excellent tool for moving data between platforms and file systems. It's not a good tool for backing up a file system. Fixing dump won't necessarily require admins to fix their scripts - it's been done more than once in the past. > I've always considered it as sub-optimal to have several tools for > one task. Just because multiple tools can perform task doesn't mean you have multiple tools for that task. I.e. - you can convince cat, cp, tar, sed, awk, rsync, and a host of others can copy a file. Which one you use depends on what you're trying to do. There's only one tool that can be used to reliably back up and restore a file system - and that's dump. Tar, cpio, GNU cp, etc. can be used to do the job, but they don't always get it right. In particular, none of them will correctly reproduce holes in files. dump will. Symlinks, special files, and similar things all cause some of the others to do odd things - exactly which ones and exactly what odd things varying depending on what you're looking at and the version of the other thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 00:40:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FC916A557 for ; Tue, 11 Sep 2007 00:40:59 +0000 (UTC) (envelope-from rnejdl@ringofsaturn.com) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [71.164.232.42]) by mx1.freebsd.org (Postfix) with ESMTP id 65E7213C457 for ; Tue, 11 Sep 2007 00:40:59 +0000 (UTC) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) by tethys.ringofsaturn.com (8.14.1/8.14.1) with ESMTP id l8B0UWLl054770 for ; Mon, 10 Sep 2007 19:30:32 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 71.164.232.42 (SquirrelMail authenticated user rnejdl) by mail.ringofsaturn.com with HTTP; Mon, 10 Sep 2007 19:30:32 -0500 (CDT) Message-ID: <54594.71.164.232.42.1189470632.squirrel@mail.ringofsaturn.com> Date: Mon, 10 Sep 2007 19:30:32 -0500 (CDT) From: "Rusty Nejdl" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.90.2/4232/Mon Sep 10 13:18:12 2007 on tethys.ringofsaturn.com X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Subject: Error in compiling kernel with CAM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 00:40:59 -0000 I have seen a few posts on this but no replied. I've got CVS code as of a few hours ago and compiling GENERIC kernel gives this: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c cc1: warnings being treated as errors /usr/src/sys/cam/cam_periph.c: In function 'cam_periph_mapmem': /usr/src/sys/cam/cam_periph.c:649: warning: pointer targets in assignment differ in signedness /usr/src/sys/cam/cam_periph.c:677: warning: pointer targets in assignment differ in signedness *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Exit 1 Thanks! Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Tue Sep 11 04:51:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D82316A417; Tue, 11 Sep 2007 04:51:09 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC4A13C461; Tue, 11 Sep 2007 04:51:09 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.6/8.13.6) with ESMTP id l8B4PHRu019042; Mon, 10 Sep 2007 22:25:17 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.6/8.13.6/Submit) id l8B4PH6U019041; Mon, 10 Sep 2007 22:25:17 -0600 (MDT) (envelope-from ken) Date: Mon, 10 Sep 2007 22:25:17 -0600 From: "Kenneth D. Merry" To: Scott Long Message-ID: <20070911042517.GA18197@nargothrond.kdm.org> References: <46E615C4.1010605@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E615C4.1010605@samsco.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.88.1/4237/Mon Sep 10 20:44:16 2007 on nargothrond.kdm.org X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: freebsd-scsi@freebsd.org, njl@freebsd.org, freebsd-current@freebsd.org Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Sep 2007 04:51:09 -0000 On Mon, Sep 10, 2007 at 22:12:52 -0600, Scott Long wrote: > All, > > The attached patch should make CAM behave properly with regard to > probing device serial numbers only when the device advertises that > it supports it. It will hopefully eliminate the need for the > CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated > legacy problem that may or may not be possible to fix). This should > especially benefit USB-UMASS devices, where the console output should > be less noisy. It might even make more devices work out-of-the-box. > So please focus testing on USB, but I'd also ask that people test > the following devices as well as any firewire devices: > > * Western Digital My Book 250GB (USB) > * Maxtor Personal Storage 3000XT (Firewire) Good idea. I wonder, though, whether devices that hang or otherwise blow up on a serial number inquiry would also have trouble with the supported pages VPD page. All the more reason we'll need people with the quirked hardware to test it... Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 12 15:18:45 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC0716A41B for ; Wed, 12 Sep 2007 15:18:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5AF5113C478 for ; Wed, 12 Sep 2007 15:18:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l8CFHKaC086336 for ; Wed, 12 Sep 2007 17:17:28 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l8CFHK8L086335; Wed, 12 Sep 2007 17:17:20 +0200 (CEST) (envelope-from olli) Date: Wed, 12 Sep 2007 17:17:20 +0200 (CEST) Message-Id: <200709121517.l8CFHK8L086335@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 12 Sep 2007 17:17:28 +0200 (CEST) X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: Subject: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Wed, 12 Sep 2007 15:18:45 -0000 Hi, (I've already posted this a few days ago, but it didn't seem to get through to the list. I have updated the 7-current machine today, and the problem is still the same.) This started to happen after updating to a recent 7-current about one week ago (it was working fine with a previous 7- current that was a few weeks older). The shell is zsh. zsh$ /usr/bin/su /libexec/ld-elf.so.1: environment corrupt; missing value for zsh$ So su(1) fails to start. Interestingly, when I first start an sh shell, I still get the same error message, but the shell starts anyway. Then I can use su(1) without problems: zsh$ sh sh: environment corrupt; missing value for $ /usr/bin/su Password: It was my impression that there should be more printed in the error message after "missing value for", so I made a hexdump: 6e 67 20 76 61 6c 75 65 20 66 6f 72 20 1b 5b 34 |ng value for .[4| 7e 0a |~.| Sure enough, my environment _does_ seem to be corrupt when I look at the output of env(1): There are several empty lines and some lines with random garbage characters and control characters. However, after starting sh, the garbage is gone. So sh seems to "repair" it somehow. Is this a bug in -current's environment handling? Or is it a bug in zsh that has only been triggered by recent changes in FreeBSD -current? Note that I use exactly the same zsh version and exactly the same zsh start profiles (i.e. basically the same environment contents) on a large number of machines, FreeBSD and other, and this problem _only_ exists on a recent FreeBSD 7-current. Best regards Oliver PS: I'm using zsh's "allexport" option, so all shell variables are automatically exported to the environment. It still isn't very big; "env | wc" reports 2.5 KB. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 07:27:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C549716A420; Thu, 13 Sep 2007 07:27:27 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAAE13C4CA; Thu, 13 Sep 2007 07:27:26 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.pil.dk (fw2.pil.dk [83.90.227.58]) by solow.pil.dk (Postfix) with ESMTP id 2C3A91CC106; Thu, 13 Sep 2007 09:27:25 +0200 (CEST) Received: by coruscant.pil.dk (Postfix, from userid 502) id 1991B61E846; Thu, 13 Sep 2007 09:27:24 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070905141759.GJ12013@garage.freebsd.pl> <20070905171741.GA15709@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Thu, 13 Sep 2007 09:27:23 +0200 In-Reply-To: (Kenneth Vestergaard Schmidt's message of "Fri\, 07 Sep 2007 08\:31\:09 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Sep 2007 07:27:27 -0000 Kenneth Vestergaard Schmidt writes: >>> The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv)' >>> - it cycles between RUN, CPUx and this one. >> >> Hmm, this means it didn't deadlock... > > Here's some debugging output. PIDs 14870, 14933 and 12458 are just > spinning and being useless. Funnily, all three have rename() in their > backtrace. No hints at all? Something else I can do? It's not the same place the processes lock, since we can just reboot the box (well, power-cycle), and when restarting the rsyncs they proceed happily for another 10-12 hours. > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 20724 20720 20724 0 R+ CPU 0 sysctl > 20720 1012 20720 0 S+ pause 0xd1e1a864 csh > 20421 948 948 125 S kqread 0xc9ad1600 pickup > 14933 14931 4351 0 R rsync > 14932 14931 4351 0 S select 0xc07d68b8 ssh > 14931 14930 4351 0 S select 0xc07d68b8 rsync > 14930 14661 4351 0 S wait 0xd1c2b804 sh > 14870 14866 4351 0 S zfs:(&tx 0xc73e6f24 rsync > 14867 14866 4351 0 S select 0xc07d68b8 ssh > 14866 14865 4351 0 S select 0xc07d68b8 rsync > 14865 14856 4351 0 S wait 0xd26c62ac sh > 14856 4355 4351 0 S piperd 0xc8f94630 perl5.8.8 > 14661 4355 4351 0 S piperd 0xd1fcb630 perl5.8.8 > 12458 12457 4351 0 R rsync > 12457 12397 4351 0 S select 0xc07d68b8 rsync > 12397 4355 4351 0 S piperd 0xd2090dec perl5.8.8 > 4360 4357 4357 0 S piperd 0xd1d55630 postdrop > 4357 4348 4357 0 Ss piperd 0xd1fcbdec sendmail > 4355 4354 4351 0 S wait 0xd20b0000 perl5.8.8 > 4354 4351 4351 0 S wait 0xd2050804 perl5.8.8 > 4351 4348 4351 0 Ss wait 0xd20482ac sh > 4348 970 970 0 S piperd 0xc741d318 cron > 1013 1 1 0 S nanslp 0xc07d07e4 getty > 1012 1 1012 0 Ss+ wait 0xd1c2c000 login > 1011 1 1011 0 Ss+ ttyin 0xc71d6410 getty > 1010 1 1010 0 Ss+ ttyin 0xc71c5410 getty > 995 1 995 0 Ss select 0xc07d68b8 inetd > 970 1 970 0 Ss nanslp 0xc07d07e4 cron > 963 1 963 0 Ss select 0xc07d68b8 sshd > 957 948 948 125 S kqread 0xd1eff480 qmgr > 948 1 948 0 Ss kqread 0xd1e14e80 master > 866 1 866 0 Ss select 0xc07d68b8 ntpd > 776 1 776 0 Ss select 0xc07d68b8 syslogd > 721 1 721 0 Ss select 0xc07d68b8 devd > 360 0 0 0 SL zfs:(&tq 0xd151877c [zil_clean] > 359 0 0 0 SL zfs:(&tq 0xd1518848 [zil_clean] > 358 0 0 0 SL zfs:(&tq 0xd1518914 [zil_clean] > 357 0 0 0 SL zfs:(&tq 0xd15189e0 [zil_clean] > 356 0 0 0 SL zfs:(&tq 0xd1518aac [zil_clean] > 355 0 0 0 SL zfs:(&tq 0xd1518b78 [zil_clean] > 354 0 0 0 SL zfs:(&tq 0xd10ba1e8 [zil_clean] > 353 0 0 0 SL zfs:(&tq 0xd10ba2b4 [zil_clean] > 352 0 0 0 SL zfs:(&tq 0xd10ba380 [zil_clean] > 351 0 0 0 SL zfs:(&tq 0xd1518c44 [zil_clean] > 350 0 0 0 SL zfs:(&tq 0xd1518d10 [zil_clean] > 349 0 0 0 SL zfs:(&tq 0xd1518ddc [zil_clean] > 348 0 0 0 SL zfs:(&tq 0xd1518ea8 [zil_clean] > 347 0 0 0 SL zfs:(&tq 0xd1849050 [zil_clean] > 346 0 0 0 SL zfs:(&tq 0xd184911c [zil_clean] > 345 0 0 0 SL zfs:(&tq 0xd18491e8 [zil_clean] > 344 0 0 0 SL zfs:(&tq 0xd10ba44c [zil_clean] > 343 0 0 0 SL zfs:(&tq 0xd18492b4 [zil_clean] > 342 0 0 0 SL zfs:(&tq 0xd10ba518 [zil_clean] > 341 0 0 0 SL zfs:(&tq 0xd10ba5e4 [zil_clean] > 340 0 0 0 SL zfs:(&tq 0xd1849380 [zil_clean] > 339 0 0 0 SL zfs:(&tq 0xd184944c [zil_clean] > 338 0 0 0 SL zfs:(&tq 0xd10ba6b0 [zil_clean] > 337 0 0 0 SL zfs:(&tq 0xd10ba77c [zil_clean] > 336 0 0 0 SL zfs:(&tq 0xd1849518 [zil_clean] > 335 0 0 0 SL zfs:(&tq 0xd18495e4 [zil_clean] > 334 0 0 0 SL zfs:(&tq 0xd10ba848 [zil_clean] > 333 0 0 0 SL zfs:(&tq 0xd18496b0 [zil_clean] > 332 0 0 0 SL zfs:(&tq 0xd184977c [zil_clean] > 331 0 0 0 SL zfs:(&tq 0xd1849848 [zil_clean] > 330 0 0 0 SL zfs:(&tq 0xd1849914 [zil_clean] > 329 0 0 0 SL zfs:(&tq 0xd10ba914 [zil_clean] > 328 0 0 0 SL zfs:(&tq 0xd18499e0 [zil_clean] > 327 0 0 0 SL zfs:(&tq 0xd1849aac [zil_clean] > 326 0 0 0 SL zfs:(&tq 0xd1849b78 [zil_clean] > 325 0 0 0 SL zfs:(&tq 0xd10ba9e0 [zil_clean] > 324 0 0 0 SL zfs:(&tq 0xd1849c44 [zil_clean] > 323 0 0 0 SL zfs:(&tq 0xd1849d10 [zil_clean] > 322 0 0 0 SL zfs:(&tq 0xd10baaac [zil_clean] > 321 0 0 0 SL zfs:(&tq 0xd0c77848 [zil_clean] > 320 0 0 0 SL zfs:(&tq 0xd10bab78 [zil_clean] > 319 0 0 0 SL zfs:(&tq 0xd0c77914 [zil_clean] > 318 0 0 0 SL zfs:(&tq 0xd0c779e0 [zil_clean] > 317 0 0 0 SL zfs:(&tq 0xd0c77aac [zil_clean] > 316 0 0 0 SL zfs:(&tq 0xd10bac44 [zil_clean] > 315 0 0 0 SL zfs:(&tq 0xd0c77b78 [zil_clean] > 314 0 0 0 SL zfs:(&tq 0xd10bad10 [zil_clean] > 313 0 0 0 SL zfs:(&tq 0xd0c77c44 [zil_clean] > 312 0 0 0 SL zfs:(&tq 0xd0c77d10 [zil_clean] > 311 0 0 0 SL zfs:(&tq 0xd0c77ddc [zil_clean] > 310 0 0 0 SL zfs:(&tq 0xd10baddc [zil_clean] > 309 0 0 0 SL zfs:(&tq 0xd10baea8 [zil_clean] > 308 0 0 0 SL zfs:(&tq 0xd1518050 [zil_clean] > 307 0 0 0 SL zfs:(&tq 0xd151811c [zil_clean] > 306 0 0 0 SL zfs:(&tq 0xd15181e8 [zil_clean] > 305 0 0 0 SL zfs:(&tq 0xd0c77ea8 [zil_clean] > 304 0 0 0 SL zfs:(&tq 0xd0ea7050 [zil_clean] > 303 0 0 0 SL zfs:(&tq 0xd15182b4 [zil_clean] > 302 0 0 0 SL zfs:(&tq 0xd1518380 [zil_clean] > 301 0 0 0 SL zfs:(&tq 0xd151844c [zil_clean] > 300 0 0 0 SL zfs:(&tq 0xd1518518 [zil_clean] > 299 0 0 0 SL zfs:(&tq 0xd15185e4 [zil_clean] > 298 0 0 0 SL zfs:(&tq 0xd15186b0 [zil_clean] > 297 0 0 0 SL zfs:(&tq 0xd0ea7c44 [zil_clean] > 296 0 0 0 SL zfs:(&tq 0xd0ea7d10 [zil_clean] > 295 0 0 0 SL zfs:(&tq 0xd0ea7ddc [zil_clean] > 294 0 0 0 SL zfs:(&tq 0xd0ea7ea8 [zil_clean] > 293 0 0 0 SL zfs:(&tq 0xd0ea711c [zil_clean] > 292 0 0 0 SL zfs:(&tq 0xd10b9050 [zil_clean] > 291 0 0 0 SL zfs:(&tq 0xd10b911c [zil_clean] > 290 0 0 0 SL zfs:(&tq 0xd0ea71e8 [zil_clean] > 289 0 0 0 SL zfs:(&tq 0xd0ea72b4 [zil_clean] > 288 0 0 0 SL zfs:(&tq 0xd10b91e8 [zil_clean] > 287 0 0 0 SL zfs:(&tq 0xd0ea7380 [zil_clean] > 286 0 0 0 SL zfs:(&tq 0xd10b92b4 [zil_clean] > 285 0 0 0 SL zfs:(&tq 0xd0ea744c [zil_clean] > 284 0 0 0 SL zfs:(&tq 0xd10b9380 [zil_clean] > 283 0 0 0 SL zfs:(&tq 0xd0ea7518 [zil_clean] > 282 0 0 0 SL zfs:(&tq 0xd0ea75e4 [zil_clean] > 281 0 0 0 SL zfs:(&tq 0xd10b944c [zil_clean] > 280 0 0 0 SL zfs:(&tq 0xd10b9518 [zil_clean] > 279 0 0 0 SL zfs:(&tq 0xd10b95e4 [zil_clean] > 278 0 0 0 SL zfs:(&tq 0xd10b96b0 [zil_clean] > 277 0 0 0 SL zfs:(&tq 0xd10b977c [zil_clean] > 276 0 0 0 SL zfs:(&tq 0xd10b9848 [zil_clean] > 275 0 0 0 SL zfs:(&tq 0xd0ea76b0 [zil_clean] > 274 0 0 0 SL zfs:(&tq 0xd10b9914 [zil_clean] > 273 0 0 0 SL zfs:(&tq 0xd10b99e0 [zil_clean] > 272 0 0 0 SL zfs:(&tq 0xd10b9aac [zil_clean] > 271 0 0 0 SL zfs:(&tq 0xd10b9b78 [zil_clean] > 270 0 0 0 SL zfs:(&tq 0xd10b9c44 [zil_clean] > 269 0 0 0 SL zfs:(&tq 0xd10b9d10 [zil_clean] > 268 0 0 0 SL zfs:(&tq 0xd10b9ddc [zil_clean] > 267 0 0 0 SL zfs:(&tq 0xd10b9ea8 [zil_clean] > 266 0 0 0 SL zfs:(&tq 0xd0ea777c [zil_clean] > 265 0 0 0 SL zfs:(&tq 0xd10ba050 [zil_clean] > 264 0 0 0 SL zfs:(&tq 0xd10ba11c [zil_clean] > 263 0 0 0 SL zfs:(&tq 0xd0ea7848 [zil_clean] > 262 0 0 0 SL zfs:(&tq 0xd08c7518 [zil_clean] > 261 0 0 0 SL zfs:(&tq 0xd08c75e4 [zil_clean] > 260 0 0 0 SL zfs:(&tq 0xd08c76b0 [zil_clean] > 259 0 0 0 SL zfs:(&tq 0xd08c777c [zil_clean] > 258 0 0 0 SL zfs:(&tq 0xd08c7848 [zil_clean] > 257 0 0 0 SL zfs:(&tq 0xd08c7914 [zil_clean] > 256 0 0 0 SL zfs:(&tq 0xd08c79e0 [zil_clean] > 255 0 0 0 SL zfs:(&tq 0xd08c7aac [zil_clean] > 254 0 0 0 SL zfs:(&tq 0xd0ea7914 [zil_clean] > 253 0 0 0 SL zfs:(&tq 0xd0ea79e0 [zil_clean] > 252 0 0 0 SL zfs:(&tq 0xd08c7b78 [zil_clean] > 251 0 0 0 SL zfs:(&tq 0xd08c7c44 [zil_clean] > 250 0 0 0 SL zfs:(&tq 0xd08c7d10 [zil_clean] > 249 0 0 0 SL zfs:(&tq 0xd0ea7aac [zil_clean] > 248 0 0 0 SL zfs:(&tq 0xd08c7ddc [zil_clean] > 247 0 0 0 SL zfs:(&tq 0xd0ea7b78 [zil_clean] > 246 0 0 0 SL zfs:(&tq 0xd08c7ea8 [zil_clean] > 245 0 0 0 SL zfs:(&tq 0xc75d3ddc [zil_clean] > 244 0 0 0 SL zfs:(&tq 0xd0c77050 [zil_clean] > 243 0 0 0 SL zfs:(&tq 0xd0c7711c [zil_clean] > 242 0 0 0 SL zfs:(&tq 0xc75d3d10 [zil_clean] > 241 0 0 0 SL zfs:(&tq 0xd0c771e8 [zil_clean] > 240 0 0 0 SL zfs:(&tq 0xc75d3b78 [zil_clean] > 239 0 0 0 SL zfs:(&tq 0xc75d3aac [zil_clean] > 238 0 0 0 SL zfs:(&tq 0xd0c772b4 [zil_clean] > 237 0 0 0 SL zfs:(&tq 0xd0c77380 [zil_clean] > 236 0 0 0 SL zfs:(&tq 0xd0c7744c [zil_clean] > 235 0 0 0 SL zfs:(&tq 0xc75d39e0 [zil_clean] > 234 0 0 0 SL zfs:(&tq 0xd0c77518 [zil_clean] > 233 0 0 0 SL zfs:(&tq 0xd0c775e4 [zil_clean] > 232 0 0 0 SL zfs:(&tq 0xc75d3914 [zil_clean] > 231 0 0 0 SL zfs:(&tq 0xd0c776b0 [zil_clean] > 230 0 0 0 SL zfs:(&tq 0xc75d3848 [zil_clean] > 229 0 0 0 SL zfs:(&tq 0xd0c7777c [zil_clean] > 228 0 0 0 SL zfs:(&tq 0xc7a6c2b4 [zil_clean] > 227 0 0 0 SL zfs:(&tq 0xc75d36b0 [zil_clean] > 226 0 0 0 SL zfs:(&tq 0xc75d35e4 [zil_clean] > 225 0 0 0 SL zfs:(&tq 0xc7a6c380 [zil_clean] > 224 0 0 0 SL zfs:(&tq 0xc75d411c [zil_clean] > 223 0 0 0 SL zfs:(&tq 0xc7a6c44c [zil_clean] > 222 0 0 0 SL zfs:(&tq 0xc7a6c518 [zil_clean] > 221 0 0 0 SL zfs:(&tq 0xc7a6c5e4 [zil_clean] > 220 0 0 0 SL zfs:(&tq 0xc7a6c6b0 [zil_clean] > 219 0 0 0 SL zfs:(&tq 0xc75d41e8 [zil_clean] > 218 0 0 0 SL zfs:(&tq 0xc7a6c77c [zil_clean] > 217 0 0 0 SL zfs:(&tq 0xc7a6c848 [zil_clean] > 216 0 0 0 SL zfs:(&tq 0xc75d42b4 [zil_clean] > 215 0 0 0 SL zfs:(&tq 0xc7a6c914 [zil_clean] > 214 0 0 0 SL zfs:(&tq 0xc7a6c9e0 [zil_clean] > 213 0 0 0 SL zfs:(&tq 0xc75d4380 [zil_clean] > 212 0 0 0 SL zfs:(&tq 0xc7a6caac [zil_clean] > 211 0 0 0 SL zfs:(&tq 0xc75d444c [zil_clean] > 210 0 0 0 SL zfs:(&tq 0xc7a6cb78 [zil_clean] > 209 0 0 0 SL zfs:(&tq 0xc7a6cc44 [zil_clean] > 208 0 0 0 SL zfs:(&tq 0xc7a6cd10 [zil_clean] > 207 0 0 0 SL zfs:(&tq 0xc75d4518 [zil_clean] > 206 0 0 0 SL zfs:(&tq 0xc7a6cddc [zil_clean] > 205 0 0 0 SL zfs:(&tq 0xc7a6cea8 [zil_clean] > 204 0 0 0 SL zfs:(&tq 0xd08c7050 [zil_clean] > 203 0 0 0 SL zfs:(&tq 0xd08c711c [zil_clean] > 202 0 0 0 SL zfs:(&tq 0xd08c71e8 [zil_clean] > 201 0 0 0 SL zfs:(&tq 0xd08c72b4 [zil_clean] > 200 0 0 0 SL zfs:(&tq 0xd08c7380 [zil_clean] > 199 0 0 0 SL zfs:(&tq 0xd08c744c [zil_clean] > 198 0 0 0 SL zfs:(&tq 0xc75d3ea8 [zil_clean] > 197 0 0 0 SL zfs:(&tq 0xc75d3c44 [zil_clean] > 196 0 0 0 SL zfs:(&tq 0xc75d377c [zil_clean] > 195 0 0 0 SL zfs:(&tq 0xc75d3050 [zil_clean] > 194 0 0 0 SL zfs:(&tq 0xc75d311c [zil_clean] > 193 0 0 0 SL zfs:(&tq 0xc75d31e8 [zil_clean] > 192 0 0 0 SL zfs:(&tq 0xc75d45e4 [zil_clean] > 191 0 0 0 SL zfs:(&tq 0xc75d46b0 [zil_clean] > 189 0 0 0 SL zfs:(&tq 0xc75d477c [zil_clean] > 188 0 0 0 SL zfs:(&tq 0xc75d32b4 [zil_clean] > 187 0 0 0 SL zfs:(&tq 0xc75d3380 [zil_clean] > 186 0 0 0 SL zfs:(&tq 0xc75d344c [zil_clean] > 185 0 0 0 SL zfs:(&tq 0xc75d3518 [zil_clean] > 183 0 0 0 SL zfs:(&tx 0xc73e6f2c [txg_thread_enter] > 182 0 0 0 SL zfs:(&tx 0xc73e6f0c [txg_thread_enter] > 181 0 0 0 RL [txg_thread_enter] > 180 0 0 0 SL vgeom:io 0xc73d8a08 [vdev:worker da11] > 179 0 0 0 SL vgeom:io 0xc73d89c8 [vdev:worker da10] > 178 0 0 0 SL vgeom:io 0xc73d8948 [vdev:worker da9] > 177 0 0 0 SL vgeom:io 0xc7a1c748 [vdev:worker da8] > 176 0 0 0 SL vgeom:io 0xc73d8888 [vdev:worker da7] > 175 0 0 0 SL vgeom:io 0xc73d8848 [vdev:worker da6] > 174 0 0 0 SL vgeom:io 0xc73d7848 [vdev:worker da5] > 175 0 0 0 SL vgeom:io 0xc73d8848 [vdev:worker da6] > 174 0 0 0 SL vgeom:io 0xc73d7848 [vdev:worker da5] > 173 0 0 0 SL vgeom:io 0xc73d8788 [vdev:worker da4] > 172 0 0 0 SL vgeom:io 0xc73d8708 [vdev:worker da3] > 171 0 0 0 SL vgeom:io 0xc7a1c9c8 [vdev:worker da2] > 170 0 0 0 SL vgeom:io 0xc7a1cdc8 [vdev:worker da1] > 169 0 0 0 SL vgeom:io 0xc7a1cbc8 [vdev:worker da0] > 168 0 0 0 SL zfs:(&tq 0xc75d4848 [spa_zio_intr_5] > 167 0 0 0 SL zfs:(&tq 0xc75d4848 [spa_zio_intr_5] > 166 0 0 0 SL zfs:(&tq 0xc75d4914 [spa_zio_issue_5] > 165 0 0 0 SL zfs:(&tq 0xc75d4914 [spa_zio_issue_5] > 164 0 0 0 SL zfs:(&tq 0xc75d49e0 [spa_zio_intr_4] > 163 0 0 0 SL zfs:(&tq 0xc75d49e0 [spa_zio_intr_4] > 162 0 0 0 SL zfs:(&tq 0xc75d4aac [spa_zio_issue_4] > 161 0 0 0 SL zfs:(&tq 0xc75d4aac [spa_zio_issue_4] > 160 0 0 0 SL zfs:(&tq 0xc75d4b78 [spa_zio_intr_3] > 159 0 0 0 SL zfs:(&tq 0xc75d4b78 [spa_zio_intr_3] > 158 0 0 0 SL zfs:(&tq 0xc75d4c44 [spa_zio_issue_3] > 157 0 0 0 SL zfs:(&tq 0xc75d4c44 [spa_zio_issue_3] > 156 0 0 0 SL zfs:(&tq 0xc75d4d10 [spa_zio_intr_2] > 155 0 0 0 SL zfs:(&tq 0xc75d4d10 [spa_zio_intr_2] > 154 0 0 0 SL zfs:(&tq 0xc75d4ddc [spa_zio_issue_2] > 153 0 0 0 SL zfs:(&tq 0xc75d4ddc [spa_zio_issue_2] > 152 0 0 0 SL zfs:(&tq 0xc75d4ea8 [spa_zio_intr_1] > 151 0 0 0 SL zfs:(&tq 0xc75d4ea8 [spa_zio_intr_1] > 150 0 0 0 SL zfs:(&tq 0xc7a6c050 [spa_zio_issue_1] > 149 0 0 0 SL zfs:(&tq 0xc7a6c050 [spa_zio_issue_1] > 148 0 0 0 SL zfs:(&tq 0xc7a6c11c [spa_zio_intr_0] > 147 0 0 0 SL zfs:(&tq 0xc7a6c11c [spa_zio_intr_0] > 146 0 0 0 SL zfs:(&tq 0xc7a6c1e8 [spa_zio_issue_0] > 145 0 0 0 SL zfs:(&tq 0xc7a6c1e8 [spa_zio_issue_0] > 108 0 0 0 SL zfs:(&ar 0xc759440c [arc_reclaim_thread] > 105 0 0 0 SL zfs:(&tq 0xc75d4050 [system_taskq] > 104 0 0 0 SL zfs:(&tq 0xc75d4050 [system_taskq] > 43 0 0 0 SL - 0xc07d0614 [schedcpu] > 42 0 0 0 SL sdflush 0xc07dbb24 [softdepflush] > 41 0 0 0 SL syncer 0xc07d060c [syncer] > 40 0 0 0 SL vlruwt 0xc71c7000 [vnlru] > 39 0 0 0 SL psleep 0xc07d6d44 [bufdaemon] > 38 0 0 0 SL pgzero 0xc07dc5d8 [pagezero] > 37 0 0 0 SL psleep 0xc07dc2f4 [vmdaemon] > 36 0 0 0 SL psleep 0xc07dc2bc [pagedaemon] > 35 0 0 0 SL pftm 0xc047ab60 [pfpurge] > 34 0 0 0 WL [irq12: psm0] > 33 0 0 0 WL [irq1: atkbd0] > 32 0 0 0 LL *Giant 0xc7088550 [swi0: sio] > 31 0 0 0 SL - 0xc715043c [fdc0] > 30 0 0 0 WL [irq25: bge1] > 29 0 0 0 WL [irq24: bge0] > 28 0 0 0 WL [irq18: ips0] > 27 0 0 0 SL idle 0xc71962e4 [mpt_raid0] > 26 0 0 0 SL idle 0xc7196000 [mpt_recovery0] > 25 0 0 0 WL [irq22: mpt0] > 24 0 0 0 WL [irq15: ata1] > 23 0 0 0 WL [irq14: ata0] > 22 0 0 0 WL [irq7: acpi0] > 21 0 0 0 WL [swi2: cambio] > 20 0 0 0 SL ccb_scan 0xc07b82f4 [xpt_thrd] > 19 0 0 0 WL [swi6: task queue] > 18 0 0 0 WL [swi6: Giant taskq] > 9 0 0 0 SL - 0xc70e4e80 [thread taskq] > 17 0 0 0 WL [swi5: +] > 8 0 0 0 SL - 0xc70fb100 [acpi_task_2] > 7 0 0 0 SL - 0xc70fb100 [acpi_task_1] > 6 0 0 0 SL - 0xc70fb100 [acpi_task_0] > 5 0 0 0 SL - 0xc70fb200 [kqueue taskq] > 16 0 0 0 SL - 0xc07d0614 [yarrow] > 4 0 0 0 SL - 0xc07ce6ec [g_down] > 3 0 0 0 SL - 0xc07ce6e8 [g_up] > 2 0 0 0 SL - 0xc07ce6e0 [g_event] > 15 0 0 0 WL [swi1: net] > 14 0 0 0 WL [swi3: vm] > 13 0 0 0 RL CPU 1 [swi4: clock sio] > 12 0 0 0 RL [idle: cpu0] > 11 0 0 0 RL [idle: cpu1] > 1 0 1 0 SLs wait 0xc709dab0 [init] > 10 0 0 0 SL audit_wo 0xc07db588 [audit] > 0 0 0 0 WLs [swapper] > > db> show proc 14870 > Process 14870 (rsync) at 0xd26c3ab0: > state: NORMAL > uid: 0 gids: 0, 0, 5 > parent: pid 14866 at 0xd1c2bab0 > ABI: FreeBSD ELF32 > arguments: /usr/local/bin/rsync > threads: 1 > 100379 D zfs:(&tx 0xc73e6f24 rsync > db> thread 100379 > [thread pid 14870 tid 100379 ] > sched_switch+0x19d: testb $0x20,0x68(%esi) > db> bt > Tracing pid 14870 tid 100379 td 0xd26c4e00 > sched_switch(d26c4e00,0,1,181d9d4,8567e45,...) at sched_switch+0x19d > mi_switch(1,0,d26c4e00,fc81da0c,c05b08c6,...) at mi_switch+0x146 > sleepq_switch(d26c4e00,0,c07640c2,21b,0,...) at sleepq_switch+0x7f > sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 > _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c > txg_wait_open(c73e6e00,4b65728e,0,d5,c88e3bfc,...) at txg_wait_open+0xd5 > dmu_tx_wait(d0fe6800,2,0,0,0,...) at dmu_tx_wait+0xe0 > zfs_freebsd_rename(fc81dba4,fc81db7c,fc81dbc0,fc81dc0c,fc81dc68,...) at zfs_freebsd_rename+0x41e > VOP_RENAME_APV(c7592e00,fc81dba4,101,c05ee4d5,5009c10,...) at VOP_RENAME_APV+0x46 > kern_rename(d26c4e00,bfbfd0c8,bfbfd8c8,0,fc81dd2c,...) at kern_rename+0x2e1 > rename(d26c4e00,fc81dcfc,8,0,5a0a382,...) at rename+0x29 > syscall(fc81dd38) at syscall+0x305 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcbbc, ebp = 0xbfbfcbc8 --- > > db> show proc 14933 > Process 14933 (rsync) at 0xd1f752ac: > state: NORMAL > uid: 0 gids: 0, 0, 5 > parent: pid 14931 at 0xd1f6bab0 > ABI: FreeBSD ELF32 > arguments: /usr/local/bin/rsync > threads: 1 > 100321 RunQ rsync > db> thread 100321 > [thread pid 14933 tid 100321 ] > sched_switch+0x19d: testb $0x20,0x68(%esi) > db> bt > Tracing pid 14933 tid 100321 td 0xd1f72200 > sched_switch(d1f72200,0,1,173a9d4,8567e2f,...) at sched_switch+0x19d > mi_switch(1,0,d1f72200,fc73aa0c,c05b08c6,...) at mi_switch+0x146 > sleepq_switch(d1f72200,0,c07640c2,21b,0,...) at sleepq_switch+0x7f > sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 > _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c > txg_wait_open(c73e6e00,4b657007,0,d5,d91633b0,...) at txg_wait_open+0xd5 > dmu_tx_wait(d160bd00,2,0,0,0,...) at dmu_tx_wait+0xe0 > zfs_freebsd_rename(fc73aba4,fc73ab7c,fc73abc0,fc73ac0c,fc73ac68,...) at zfs_freebsd_rename+0x41e > VOP_RENAME_APV(c7592e00,fc73aba4,101,119,5009c10,...) at VOP_RENAME_APV+0x46 > kern_rename(d1f72200,bfbfd0c8,bfbfd8c8,0,fc73ad2c,...) at kern_rename+0x2e1 > rename(d1f72200,fc73acfc,8,d1f72200,fc73ad2c,...) at rename+0x29 > syscall(fc73ad38) at syscall+0x305 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcbbc, ebp = 0xbfbfcbc8 --- > > db> show proc 12458 > Process 12458 (rsync) at 0xd1e1c804: > state: NORMAL > uid: 0 gids: 0, 0, 5 > parent: pid 12457 at 0xd1c2dab0 > ABI: FreeBSD ELF32 > arguments: /usr/local/bin/rsync > threads: 1 > 100293 RunQ rsync > db> thread 100293 > [thread pid 12458 tid 100293 ] > sched_switch+0x19d: testb $0x20,0x68(%esi) > db> bt > Tracing pid 12458 tid 100293 td 0xd18c5a00 > sched_switch(d18c5a00,0,1,15d29d4,858acc6,...) at sched_switch+0x19d > mi_switch(1,0,d18c5a00,fc5d2a0c,c05b08c6,...) at mi_switch+0x146 > sleepq_switch(d18c5a00,0,c07640c2,21b,0,...) at sleepq_switch+0x7f > sleepq_wait(c73e6f24,c73e6eac,c758ddf9,1,0,...) at sleepq_wait+0x36 > _cv_wait(c73e6f24,c73e6eac,c758dce6,19e,c73e6f1c,...) at _cv_wait+0x13c > txg_wait_open(c73e6e00,4b7d2f7f,0,d5,d26010ec,...) at txg_wait_open+0xd5 > dmu_tx_wait(c987f980,2,0,0,0,...) at dmu_tx_wait+0xe0 > zfs_freebsd_rename(fc5d2ba4,fc5d2b7c,fc5d2bc0,fc5d2c0c,fc5d2c68,...) at zfs_freebsd_rename+0x41e > VOP_RENAME_APV(c7592e00,fc5d2ba4,101,c8c63c08,5009c10,...) at VOP_RENAME_APV+0x46 > kern_rename(d18c5a00,bfbfd0a8,bfbfd8a8,0,fc5d2d2c,...) at kern_rename+0x2e1 > rename(d18c5a00,fc5d2cfc,8,c714b400,7df1b67,...) at rename+0x29 > syscall(fc5d2d38) at syscall+0x305 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (128, FreeBSD ELF32, rename), eip = 0x28103ccb, esp = 0xbfbfcb9c, ebp = 0xbfbfcba8 --- > > /Kenneth /Kenneth From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 07:41:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F96916A41B for ; Thu, 13 Sep 2007 07:41:59 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0AE13C457 for ; Thu, 13 Sep 2007 07:41:59 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 7FEE65C62; Thu, 13 Sep 2007 09:23:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 80) id AE78B5C3F; Thu, 13 Sep 2007 09:23:17 +0200 (CEST) To: Aristedes Maniatis MIME-Version: 1.0 Date: Thu, 13 Sep 2007 09:23:17 +0200 From: =?UTF-8?Q?Daniel_Ger=C5=BEo?= In-Reply-To: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> References: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> Message-ID: X-Sender: danger@rulez.sk User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danger@rulez.sk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 07:41:59 -0000 Hello Aristedes, On Thu, 13 Sep 2007 09:22:10 +1000, Aristedes Maniatis wrote: > * Is there a set release schedule and known bugs notes for snapshots? > I'd like to try a snapshot but I don't know whether to wait a day/ > week/month for the next one. Or are they released just when someone > thinks the source is in a good overall state? You can get the very recent snapshot at http://snapshots.us.freebsd.org/. They are built on a daily basis. -- S pozdravom / Best Regards, Daniel Geržo From owner-freebsd-current@FreeBSD.ORG Thu Sep 13 18:35:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8AF16A41A for ; Thu, 13 Sep 2007 18:35:03 +0000 (UTC) (envelope-from ricardo.areis@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 5036C13C45E for ; Thu, 13 Sep 2007 18:35:03 +0000 (UTC) (envelope-from ricardo.areis@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so516816wxd for ; Thu, 13 Sep 2007 11:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=9/JN9AtAPPeELQBL+MFhhSZ7xJ8ghDSBsJNCA/1gm0c=; b=JHgpH24e5CoLX2ZqA+3wRD6xPlr9ygA3VLqiv/bke1xOrp2MK6oU9x10ZYqA931BJ9CetXyykjEfco5P2JkuaUNP/vNz9qKEwx0169xsepFNxe11qbWBYz8US5lWddY677mx3N9gYQDuk7mrFpZEL34ExhIq8FbuiU0rHFuT5l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Ad/7Uz9S3Eg+WNK37rua2fK0DCB5MdZ8V7VaGNB91Ws+UkS49KzIrL89cj8xmFKnBl9+r7mL+xlX1pW07YXP6ST8Ftcdj5MAsJF2qI7LiZ3cNgI7bglzZdG+CnESZCkgZNkp0j+MO6NiFr8cs0AYR58S1OOXdnPVx5VmpU5WTcg= Received: by 10.90.63.16 with SMTP id l16mr2275802aga.1189707033531; Thu, 13 Sep 2007 11:10:33 -0700 (PDT) Received: by 10.90.119.1 with HTTP; Thu, 13 Sep 2007 11:10:33 -0700 (PDT) Message-ID: <398a5c890709131110u2c0acc81r3e511a4b4e6a5521@mail.gmail.com> Date: Thu, 13 Sep 2007 15:10:33 -0300 From: "Ricardo A. Reis" To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Mac lomac/high(low-high) can't see lomac/low(low-low) in FreeBSD 7.0-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, 13 Sep 2007 18:35:03 -0000 Hi, I attempt to create a web enviromente with mac_lomac and mac_partition, but root user can't see insecure user. My configurations, teste# kldstat Id Refs Address Size Name 1 10 0xc0400000 903430 kernel 2 1 0xc0d04000 2464 accf_http.ko 3 1 0xc0d07000 1fb4 mac_partition.ko 4 1 0xc0d09000 21b8 mac_seeotheruids.ko 5 1 0xc0d0c000 a5bc mac_lomac.ko 6 1 0xc0d17000 6a2c4 acpi.ko teste# cat /boot/loader.conf|grep -v # accf_http_load="YES" mac_lomac_load="YES" mac_partition_load="YES" security.mac.lomac.trust_all_interfaces=1 mac_seeotheruids_load="YES" teste# cat /etc/mac.conf |grep -v # default_labels file ?biba,?lomac default_labels ifnet ?biba,?lomac default_labels process ?biba,?lomac,?partition default_labels socket ?biba,?lomac login.conf .................... insecure:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=lomac/low(low-low),partition/1: ---------------- default .... .... :label=lomac/high(low-high): ----------------- root user = default class www user = insecure class teste# getpmac lomac/high(low-high),partition/0 ps -Zaxu ----------------------------------------------------------------------------------- LABEL USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND lomac/equal(low-high),partition/0 root 11 100.0 0.0 0 8 ?? RL Wed11AM 1644: 53.86 [idle: cpu3] lomac/equal(low-high),partition/0 root 12 100.0 0.0 0 8 ?? RL Wed11AM 1645: 05.20 [idle: cpu2] lomac/equal(low-high),partition/0 root 13 100.0 0.0 0 8 ?? RL Wed11AM 1645: 03.54 [idle: cpu1] lomac/equal(low-high),partition/0 root 14 100.0 0.0 0 8 ?? RL Wed11AM 1643: 32.38 [idle: cpu0] lomac/equal(low-high),partition/0 root 0 0.0 0.0 0 0 ?? WLs Wed11AM 0:00.01[swapper] lomac/high(low-high),partition/0 root 1 0.0 0.0 1888 464 ?? SLs Wed11AM 0: 00.01 /sbin/init -- lomac/equal(low-high),partition/0 root 2 0.0 0.0 0 8 ?? DL Wed11AM 0:01.90[g_event] lomac/equal(low-high),partition/0 root 3 0.0 0.0 0 8 ?? DL Wed11AM 0:04.99[g_up] lomac/equal(low-high),partition/0 root 4 0.0 0.0 0 8 ?? DL Wed11AM 0:04.25[g_down] lomac/equal(low-high),partition/0 root 5 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[kqueue taskq] lomac/equal(low-high),partition/0 root 6 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[acpi_task_0] lomac/equal(low-high),partition/0 root 7 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[acpi_task_1] lomac/equal(low-high),partition/0 root 8 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[acpi_task_2] lomac/equal(low-high),partition/0 root 9 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[xpt_thrd] lomac/equal(low-high),partition/0 root 10 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[audit] lomac/equal(low-high),partition/0 root 15 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi1: net] lomac/equal(low-high),partition/0 root 16 0.0 0.0 0 8 ?? WL Wed11AM 1:46.42[swi4: clock sio] lomac/equal(low-high),partition/0 root 17 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi3: vm] lomac/equal(low-high),partition/0 root 18 0.0 0.0 0 8 ?? DL Wed11AM 0:10.05[yarrow] lomac/equal(low-high),partition/0 root 19 0.0 0.0 0 8 ?? WL Wed11AM 0:01.40[swi6: Giant taskq] lomac/equal(low-high),partition/0 root 20 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi6: task queue] lomac/equal(low-high),partition/0 root 21 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi2: cambio] lomac/equal(low-high),partition/0 root 22 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi5: +] lomac/equal(low-high),partition/0 root 23 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[thread taskq] lomac/equal(low-high),partition/0 root 24 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq9: acpi0] lomac/equal(low-high),partition/0 root 25 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[em0 taskq] lomac/equal(low-high),partition/0 root 26 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[em1 taskq] lomac/equal(low-high),partition/0 root 27 0.0 0.0 0 8 ?? WL Wed11AM 0:01.70[irq17: aac0] lomac/equal(low-high),partition/0 root 28 0.0 0.0 0 8 ?? DL Wed11AM 0:00.02[aac0aif] lomac/equal(low-high),partition/0 root 29 0.0 0.0 0 8 ?? WL Wed11AM 0:28.00[irq258: bce0] lomac/equal(low-high),partition/0 root 30 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq259: bce1] lomac/equal(low-high),partition/0 root 31 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq23: uhci0 uhci+] lomac/equal(low-high),partition/0 root 32 0.0 0.0 0 8 ?? DL Wed11AM 0:00.04[usb0] lomac/equal(low-high),partition/0 root 33 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[usbtask-hc] lomac/equal(low-high),partition/0 root 34 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[usbtask-dr] lomac/equal(low-high),partition/0 root 35 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq22: uhci1 uhci3] lomac/equal(low-high),partition/0 root 36 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[usb1] lomac/equal(low-high),partition/0 root 37 0.0 0.0 0 8 ?? DL Wed11AM 0:00.01[usb2] lomac/equal(low-high),partition/0 root 38 0.0 0.0 0 8 ?? DL Wed11AM 0:00.01[usb3] lomac/equal(low-high),partition/0 root 39 0.0 0.0 0 8 ?? DL Wed11AM 0:00.01[usb4] lomac/equal(low-high),partition/0 root 40 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq14: ata0] lomac/equal(low-high),partition/0 root 41 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq15: ata1] lomac/equal(low-high),partition/0 root 42 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[irq1: atkbd0] lomac/equal(low-high),partition/0 root 43 0.0 0.0 0 8 ?? WL Wed11AM 0:00.00[swi0: sio] lomac/equal(low-high),partition/0 root 44 0.0 0.0 0 16 ?? DL Wed11AM 0:00.00[sctp_iterator] lomac/equal(low-high),partition/0 root 45 0.0 0.0 0 8 ?? DL Wed11AM 0:00.05[pagedaemon] lomac/equal(low-high),partition/0 root 46 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[vmdaemon] lomac/equal(low-high),partition/0 root 47 0.0 0.0 0 8 ?? DL Wed11AM 0:00.00[pagezero] lomac/equal(low-high),partition/0 root 48 0.0 0.0 0 8 ?? DL Wed11AM 0:00.27[bufdaemon] lomac/equal(low-high),partition/0 root 49 0.0 0.0 0 8 ?? DL Wed11AM 0:00.39[vnlru] lomac/equal(low-high),partition/0 root 50 0.0 0.0 0 8 ?? DL Wed11AM 1:09.13[syncer] lomac/equal(low-high),partition/0 root 51 0.0 0.0 0 8 ?? DL Wed11AM 0:00.48[softdepflush] lomac/high(low-high),partition/0 root 648 0.0 0.0 3240 1008 ?? Ss Wed11AM 0: 00.00 /usr/sbin/moused -p /dev/ums0 -t auto -I /va lomac/high(low-high),partition/0 root 700 0.0 0.0 1888 524 ?? Ss Wed11AM 0: 00.00 /sbin/devd lomac/high(low-high),partition/0 root 769 0.0 0.0 3156 1192 ?? Ss Wed11AM 0: 00.13 /usr/sbin/syslogd -s lomac/high(low-high),partition/0 root 883 0.0 0.1 5592 3056 ?? Ss Wed11AM 0: 00.00 /usr/sbin/sshd lomac/high(low-high),partition/0 root 890 0.0 0.0 3184 1260 ?? Ss Wed11AM 0: 00.17 /usr/sbin/cron -s lomac/high(low-high),partition/0 root 946 0.0 0.1 8360 3916 ?? Ss Wed11AM 0: 00.03 sshd: grede [priv] (sshd) lomac/high(low-high),partition/0 grede 949 0.0 0.1 8360 3932 ?? S Wed11AM 0: 00.07 sshd: grede@ttyp0 (sshd) lomac/high(low-high),partition/0 root 938 0.0 0.0 3156 1076 v0 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv0 lomac/high(low-high),partition/0 root 939 0.0 0.0 3156 1076 v1 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv1 lomac/high(low-high),partition/0 root 940 0.0 0.0 3156 1076 v2 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv2 lomac/high(low-high),partition/0 root 941 0.0 0.0 3156 1076 v3 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv3 lomac/high(low-high),partition/0 root 942 0.0 0.0 3156 1076 v4 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv4 lomac/high(low-high),partition/0 root 943 0.0 0.0 3156 1076 v5 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv5 lomac/high(low-high),partition/0 root 944 0.0 0.0 3156 1076 v6 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv6 lomac/high(low-high),partition/0 root 945 0.0 0.0 3156 1076 v7 Ss+ Wed11AM 0:00.00 /usr/libexec/getty Pc ttyv7 lomac/high(low-high),partition/0 grede 950 0.0 0.1 5444 2920 p0 Ss Wed11AM 0:00.01 -tcsh (tcsh) lomac/high(low-high),partition/0 root 952 0.0 0.1 3592 1572 p0 S Wed11AM 0: 00.01 su - lomac/high(low-high),partition/0 root 953 0.0 0.1 5444 3212 p0 S Wed11AM 0: 00.05 -su (csh) lomac/high(low-high),partition/0 root 4522 0.0 0.0 3220 1052 p0 R+ 2:57PM 0: 00.00 ps -Zaxu ---------------------------- Apache teste# /usr/sbin/setpmac lomac/low\(low-low\),partition/1 apachectl start teste# /usr/sbin/setpmac lomac/low\(low-low\),partition/1 csh teste# ps -Zaxu teste# getpmac lomac/low(low-low),partition/1 LABEL USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND lomac/low(low-low),partition/1 www 4529 5.7 0.5 28092 17196 ?? S 2:58PM 0: 00.00 /usr/local/sbin/httpd lomac/low(low-low),partition/1 www 4530 5.7 0.5 28092 17196 ?? S 2:58PM 0: 00.00 /usr/local/sbin/httpd lomac/low(low-low),partition/1 www 4531 5.7 0.5 28092 17196 ?? S 2:58PM 0: 00.00 /usr/local/sbin/httpd lomac/low(low-low),partition/1 www 4532 5.7 0.5 28092 17196 ?? S 2:58PM 0: 00.00 /usr/local/sbin/httpd lomac/low(low-low),partition/1 www 4533 5.7 0.5 28092 17196 ?? S 2:58PM 0: 00.00 /usr/local/sbin/httpd lomac/low(low-low),partition/1 root 4528 5.0 0.5 28052 17152 ?? Ss 2:58PM 0: 00.52 /usr/local/sbin/httpd lomac/low(low-low),partition/1 root 4534 0.0 0.1 5444 3000 p0 S 2:58PM 0: 00.01 csh lomac/low(low-low),partition/1 root 4538 0.0 0.0 3220 1000 p0 R+ 2:59PM 0: 00.00 ps -Zaxu Thanks by any help... Ricardo A. Reis From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 07:20:50 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8281116A418 for ; Fri, 14 Sep 2007 07:20:50 +0000 (UTC) (envelope-from tv@solnet.ch) Received: from mail01.solnet.ch (mail01.solnet.ch [212.101.4.135]) by mx1.freebsd.org (Postfix) with ESMTP id 49B0C13C46B for ; Fri, 14 Sep 2007 07:20:50 +0000 (UTC) (envelope-from tv@solnet.ch) X-Virus-Scanned: by amavisd-new at mail01.solnet.ch Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JDtZ8iXIaERE; Fri, 14 Sep 2007 07:04:19 +0000 (UTC) Received: from tom.local (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail01.solnet.ch (Postfix) with ESMTP id 7F018C606; Fri, 14 Sep 2007 07:04:19 +0000 (UTC) Message-ID: <46EA3263.2060701@solnet.ch> Date: Fri, 14 Sep 2007 09:04:03 +0200 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alex Dupre References: <1091994189.20070913041709@arpanet.ru> <46E941D0.5020204@FreeBSD.org> In-Reply-To: <46E941D0.5020204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: Alexander Sizov , current@FreeBSD.org Subject: Re: portsnap fetch bug or quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 07:20:50 -0000 Hello When does this happen? Our server is pretty busy every morning between 06.00 - 07.00 (UTC+2) because of so many parallels cvsup. We are also using portsnap for serveral servers without any problem at different time. JFYI: We are planning to setup a faster server at the end of next week. Regards, Thomas Alex Dupre schrieb: > Alexander Sizov ha scritto: > >> Looking up portsnap3.FreeBSD.org mirrors... none found. >> Fetching snapshot tag from portsnap3.FreeBSD.org... done. >> Fetching 1980 patches.....10....20....30....40 ... >> 1420....1430.... done. >> >> The number of fetching patches (1980) != number of fetched patches >> (143[8-9]). Why it happens? > > Does it happen only on portsnap3, right? > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 09:13:23 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A809516A418; Fri, 14 Sep 2007 09:13:23 +0000 (UTC) (envelope-from tv@solnet.ch) Received: from mail01.solnet.ch (mail01.solnet.ch [212.101.4.135]) by mx1.freebsd.org (Postfix) with ESMTP id 68FC813C469; Fri, 14 Sep 2007 09:13:23 +0000 (UTC) (envelope-from tv@solnet.ch) X-Virus-Scanned: by amavisd-new at mail01.solnet.ch Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xruDiR6npdLc; Fri, 14 Sep 2007 09:13:22 +0000 (UTC) Received: from tom.local (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail01.solnet.ch (Postfix) with ESMTP id 4C1CCC47F; Fri, 14 Sep 2007 09:13:22 +0000 (UTC) Message-ID: <46EA50A2.4000406@solnet.ch> Date: Fri, 14 Sep 2007 11:13:06 +0200 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alex Dupre References: <1091994189.20070913041709@arpanet.ru> <46E941D0.5020204@FreeBSD.org> <46EA3263.2060701@solnet.ch> <46EA3D12.8030005@FreeBSD.org> In-Reply-To: <46EA3D12.8030005@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Sep 2007 11:00:11 +0000 Cc: current@FreeBSD.org Subject: Re: portsnap fetch bug or quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 09:13:23 -0000 Hi We are tier 1 mirror for openoffice, mysql, several linux distributions and many other open source projects and we are aware of our i/o problem on our current ftp/rsync/http mirror. All rsync and cvsup processes generating a lot of i/o and high cpu load in generall but especially at 6-7 (UTC +2) in the morning. The fact that this machine is also nearly full with almost 2 tb of data (95% of diskspace) is not helping to reduce the i/o problem. It was never planned to use this machine as a ftp mirror but a major hardware crash forced us to do so. This machine is underpowered. It just a backup system running inside a jail. We are sorry but I'm pretty sure our performance problems should be fixed at the end of next week with our new hardware (much faster cpu, much more diskspace, standalone machine). Regards, Thomas Alex Dupre schrieb: > Thomas Vogt ha scritto: >> When does this happen? Our server is pretty busy every morning between >> 06.00 - 07.00 (UTC+2) because of so many parallels cvsup. > > Strange. I noticed only now that portsnap3 is next to me (Italy) and in > fact it has the best latency, but the downloads are very intermittent (I > receive N updated, a pause, other N updates, and so on, with portsnap1/2 > it's continuous). Usually I portsnap around 8:00 (UTC + 1 + DST). > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 11:08:16 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C9416A417 for ; Fri, 14 Sep 2007 11:08:16 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8A513C458 for ; Fri, 14 Sep 2007 11:08:16 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so433821wra for ; Fri, 14 Sep 2007 04:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=RUv0/ojsyDLmu7YOh4sJmfz2akBQU4KgrJ5OylogjGQ=; b=ZLJHxbcRgrIe4fwgJE8mIvibIddKld14Ge0mVPMaGBTNCpVZqweRABgOA6Bu4ofwZqSebuJJ5mPRMJs0MB6WS56rPW35pfeuRxuAHATtnI7a00JfPrs8ugMJvecHlOZrlCFlbGtD/pYYfpnV6rwjxlhsu2iPN+eNpx+08FRtuhE= 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=FqlC0lzfjI/2NhXYHE/T8n9WJvHdrmYfjNMI9c59fS+WciBlVVl5aodCUPv/Uk8v39pH0IyqpifANrkPw/sQwNqWd3xQ/GP/MCDvFtFq7I1fWVlNqiqGRmRwb3KnWm5fVf9vQtvG87XEsTO8aHyEShV2XJWlJhQSACsj0JpCwnY= Received: by 10.78.177.3 with SMTP id z3mr925756hue.1189768094239; Fri, 14 Sep 2007 04:08:14 -0700 (PDT) Received: by 10.78.173.13 with HTTP; Fri, 14 Sep 2007 04:08:14 -0700 (PDT) Message-ID: <7ad7ddd90709140408p49468629hd01e41c6c8820a3a@mail.gmail.com> Date: Fri, 14 Sep 2007 13:08:14 +0200 From: "Ulrich Spoerlein" To: "Brandon Weisz" In-Reply-To: <1189721343.17751.20.camel@section-8.ipv6.avioc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070906184853.GB90021@roadrunner.spoerlein.net> <20070910195833.GE1103@garage.freebsd.pl> <70e8236f0709131425h2f651c32j5e23d7901ce6e1f7@mail.gmail.com> <1189721343.17751.20.camel@section-8.ipv6.avioc.org> Cc: Joao Barros , Pawel Jakub Dawidek , current@freebsd.org Subject: Re: ZFS not caching right? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 11:08:17 -0000 On 9/14/07, Brandon Weisz wrote: > On Thu, 2007-09-13 at 22:25 +0100, Joao Barros wrote: > > This happened 1 day after compiling new sources: > > panic: kmem_malloc(90112): kmem_map too small: 329805824 total allocated > > when writing through NFS. > > Machine has 1GB of ram and: > > vfs.zfs.arc_min: 16777216 > > vfs.zfs.arc_max: 251658240 > > > > I hadn't had any panics with sources from August 16 but before your > > recent changes vfs.zfs.arc_max was 167772160 > > kern.maxvnodes is not set to 50000 as recomended ( on purpose ) and is > > currently at 52242 set by the system. Is 50000 still recomended after > > your changes? > > > > Just a "me too" - > > I am also seeing "kmem_map too small" panics on a amd64 NFS server with > 1 GB ram after the recent zfs changes. setting > vm.kmem_size_max="402653184" seems to have stopped the panics, however > this was not needed previously. Hmm, it's solid for me. i386 with 1GB RAM and arc_max of 128MB (instead of 256MB). maxvnodes is set to 50k and kmem is at its system tuned default. Uli From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 11:26:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DEA116A418 for ; Fri, 14 Sep 2007 11:26:47 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id E30B713C45D for ; Fri, 14 Sep 2007 11:26:46 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so611746rvb for ; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=J/lLhZtaOchrNeMbXNGFpEJMnEbimpElGUsHXaD4Rnw=; b=Q5RIjaqGQ9mRkt7OENA91XQm/aKqgdkOn5HFiqraAdEgoRM6lNrXlVULo/G9pK3/793QATlTUun/ktWazbC1na/uWo6ARIq6za07ar7ngpjTVbrs4Uvb3/ZmJSNV84h2C21xMr6XKNH4YVLn6BckTWmQ0BE7CTSYi/34pf+9uGQ= 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=VPampRX7wRbQp1YDMeKAV9ESkqFN1EZQzW8nEMwRVAjtfB/h7Ka9d8RVTS1SoW/EU1lz1iyZzNoEtqVEf+EtzaePkAuUhLcqakJ72iRlRFLCVe5y1RcSRbEyZVxsBre5PX77/gDiYZmPPmNoVOTU3hTqhPw+zfJMmOpbT1JfBSg= Received: by 10.114.198.1 with SMTP id v1mr1682182waf.1189769206330; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) Message-ID: <632825b40709140426s466e20afkc410c56aa4f1dae9@mail.gmail.com> Date: Fri, 14 Sep 2007 08:26:46 -0300 From: William To: "Nate Lawson" In-Reply-To: <46E6DF34.1060304@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> <46E6DF34.1060304@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 11:26:47 -0000 On 9/11/07, Nate Lawson wrote: > > William Grzybowski wrote: > > On 9/6/07, *Nate Lawson* > wrote: > > > > Nate Lawson wrote: > > > I've done some major rework on the EC driver. This should help > with > > > various problems, including timeouts while checking battery status > or > > > temperature. The attached patches are for 6.x and 7.x. Please > > test and > > > let me know if you get any new errors on dmesg or if it fixes > > things for > > > you (especially HP/Compaq laptop owners). > > > > > > If you still have problems, try setting each of these tunables > > > individually and then both together (i.e., in > > /boot/loader.conf). Note > > > that this will be four (4) test runs total, so don't just set both > and > > > say it doesn't work. > > > > > > debug.acpi.ec.burst= "1" > > > debug.acpi.ec.polled="1" > > > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, > no > > > problems in either regular or burst mode. > > > > > > > > > Commit message: > > > Rewrite the EC driver event model. The main goal is to avoid > > > polling/interrupt-driven fallback and instead use polling only > during > > > boot and pure interrupt-driven mode after boot. Polled mode could > be > > > relegated completely to a legacy role if we could enable > interrupts > > > during boot. Polled mode can be forced after boot by setting > > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > > > One minor note -- power off shutdown (shutdown/halt -p) is turned > into a > > (safe) reboot with this patch. I have tested the fix, which is just > to > > force polled mode during shutdown as well. I don't have time to > > re-roll > > the patch today but will send tomorrow. > > > > Please test the patch as posted, ignoring that minor issue. The > test > > results during normal use are still valid. > > > > > > Hi Nate, > > > > I tested this patch on my acer notebook (intel chipset) and i did not > > notice any changes, unless some errors on dmesg, like: > > acpi_ec0: EcCommand: no response to 0x84 > > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > > acpi_ec0: EcCommand: no response to 0x82 > > acpi_ec0: EcCommand: no response to 0x80 > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE > > As I noted before, your system enters the poll loop with the status > appearing to be already complete. Can you get back to me on my previous > questions, especially whether forcing polled mode works for you? I > didn't see any errors in that dmesg case. > > I've updated the patches to do one final check if the interrupt-driven > mode gets a timeout. If the status is complete, it will force the > system back into polled mode since interrupt mode doesn't work. It also > has a case for polled mode during boot where the status appears to be > already complete. It waits a short while before actually checking the > status, just in case the EC is really slow and hasn't gotten to work on > the new request yet. > > Give it a try also, with no tunables set. Nate, Yesterday I send to you privately the answers which you asked for, annoy me if you didn't receive... Today I recompiled the kernel from a today's cvs without modules with KTR and recompiled the acpi module without any patches, without any debug option on boot, the system can initialize the battery and the thermal, when i enable any debug (polled or burst or even both) the battery get ready after 2 tries. Tonight I will remake some testes with your patches to make sure about things which I told you. Thanks, -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 11:45:54 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6BF116A418 for ; Fri, 14 Sep 2007 11:45:54 +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 3284C13C461 for ; Fri, 14 Sep 2007 11:45:53 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8EBjq4Z068715 for ; Fri, 14 Sep 2007 15:45:52 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1189770352; bh=05aGiJqpMmUlVM1oi4m7kZcBMOarMOzSaA03s0Y tK0k=; l=444; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=kwR52WVjFu/VxYffgKR5r7KYdv9DwKKKs02qWIeO 2cg/9RpBmdWjFMW3pJE2ZCyOq/2wWagzMfbqLPXbW237xQ/yfM7P08H/uEU/KTuYLCv EGy0ckm5btayvrlFP8nHY0db0uLWl2uSv49UROszzqIl/ZypjMhyjeTH9x5Bgu04= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8EBjqRt068714 for freebsd-current@FreeBSD.ORG; Fri, 14 Sep 2007 15:45:52 +0400 (MSD) (envelope-from ache) Date: Fri, 14 Sep 2007 15:45:52 +0400 From: Andrey Chernov To: freebsd-current@FreeBSD.ORG Message-ID: <20070914114552.GA68610@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , freebsd-current@FreeBSD.ORG References: <200709121517.l8CFHK8L086335@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709121517.l8CFHK8L086335@lurza.secnetix.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 11:45:54 -0000 On Wed, Sep 12, 2007 at 05:17:20PM +0200, Oliver Fromme wrote: > This started to happen after updating to a recent 7-current > about one week ago (it was working fine with a previous 7- > current that was a few weeks older). The shell is zsh. > > zsh$ /usr/bin/su > /libexec/ld-elf.so.1: environment corrupt; missing value for > zsh$ Search for 'zsh oddities with recent -current' topic in this list. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 11:54:16 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4227116A468; Fri, 14 Sep 2007 11:54:16 +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 0B5B813C442; Fri, 14 Sep 2007 11:54:15 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id CC61C63476; Fri, 14 Sep 2007 14:28:59 +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 94554-01; Fri, 14 Sep 2007 14:28:56 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 83D5663470; Fri, 14 Sep 2007 14:28:55 +0300 (EEST) Message-ID: <46EA7077.8010200@bulinfo.net> Date: Fri, 14 Sep 2007 14:28:55 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070913) MIME-Version: 1.0 To: Scott Long References: <46E615C4.1010605@samsco.org> In-Reply-To: <46E615C4.1010605@samsco.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 11:54:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, This patch solves problems with one of my memory sticks: http://lists.freebsd.org/pipermail/freebsd-arm/2007-August/000704.html Now: umass0: on uhub0 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 967MB (1981440 512 byte sectors: 64H 32S/T 967C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached Best Regards Scott Long wrote: > All, > > The attached patch should make CAM behave properly with regard to > probing device serial numbers only when the device advertises that > it supports it. It will hopefully eliminate the need for the > CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated > legacy problem that may or may not be possible to fix). This should > especially benefit USB-UMASS devices, where the console output should > be less noisy. It might even make more devices work out-of-the-box. > So please focus testing on USB, but I'd also ask that people test > the following devices as well as any firewire devices: > > * Western Digital My Book 250GB (USB) > * Maxtor Personal Storage 3000XT (Firewire) > > Thanks, > > Scott > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG6nB2xJBWvpalMpkRAgSWAJ9BuFERvPQmWWod6fud9T2lSJpCsACfXhoO mJVa3xaAmWDYwvtReWZl51I= =7J6C -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 12:06:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1704B16A419 for ; Fri, 14 Sep 2007 12:06:33 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id E942D13C45B for ; Fri, 14 Sep 2007 12:06:30 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l8EBYkHd098186; Fri, 14 Sep 2007 06:34:47 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46EA71D5.9010207@freebsd.org> Date: Fri, 14 Sep 2007 06:34:45 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20070914024239.84366.qmail@exxodus.fedaykin.here> In-Reply-To: <20070914024239.84366.qmail@exxodus.fedaykin.here> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/4272/Fri Sep 14 03:36:36 2007 on ns.trinitel.com X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: hang on startx with nvidia / also with emu10kx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 12:06:33 -0000 Mario Sergio Fujikawa Ferreira wrote: > Hi, > > FreeBSD exxodus.fedaykin.here 7.0-CURRENT FreeBSD 7.0-CURRENT #9: Thu Sep 13 22:46:14 BRT 2007 lioux@exxodus:/usr/src/sys/i386/compile/LIOUX i386 > > -CURRENT as of today September 13th 2007 with latest ports. > xorg works fine if I launch it with tightvnc. However, the system > hangs if I try to startx using the nvidia driver. The same happens > if I try to kldload emu10kx. > > How do I force the system to issue a kernel dump when it > hangs? I want to be able to provide a proper backtrace of the system > if possible. :) > > Are these known issues? I have the same issue. It has been happening for me for a while, so I switched to the nv driver (which is terribly slow for me). I was able to get a dump, by having all the debugger bits in the kernel config, and when it locked up, I simply typed "call doadump" [enter], then "reset" [enter]. I got my dump, even though I couldn't see the typing. I have yet to do anything with the dump :( Eric From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 12:11:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB93116A419 for ; Fri, 14 Sep 2007 12:11:32 +0000 (UTC) (envelope-from asmrookie@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 7E74C13C48D for ; Fri, 14 Sep 2007 12:11:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so551746ugf for ; Fri, 14 Sep 2007 05:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=cmEOe3vFvzGGg6HTpKvSyKNwC3PIwrWyj04mXQOjOUA=; b=MBhPrxuqAKixgj/BgYh/Iu1f++MTwe4IwHBQTdWmN6ZrRpp93DIsZxhM5gBC0iaIXhQ51Cq+x2vdVxnsrFvb/FdaVb+dbR9KcjD3Fm2mg9jtj5TToSFU/H6lk55qsEVTyS+2/2N8Z336iFJe6bIgxDIHx1t6p/BKSYiMcDTb6Jg= 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=rOsqkFFDPQn4wiqcHVeu2/3jcvi2Jaxyhp9i7pxbLHFYXkTSC2vQ1yoMqYbkhKvAP5ZfmZn8dG3JfhXd7F0b3jgzH52x5bcUuuU7fjsJorrx/hgwvm8NNShl368NmQGGRgggjpvX5Lb+WRMZp8sPL/LTWDal3bFZnKYXSizmvBg= Received: by 10.78.206.9 with SMTP id d9mr981320hug.1189771890206; Fri, 14 Sep 2007 05:11:30 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Fri, 14 Sep 2007 05:11:30 -0700 (PDT) Message-ID: <3bbf2fe10709140511p5462d638t5bdb608c7afff1da@mail.gmail.com> Date: Fri, 14 Sep 2007 14:11:30 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Mario Sergio Fujikawa Ferreira" In-Reply-To: <20070914024239.84366.qmail@exxodus.fedaykin.here> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070914024239.84366.qmail@exxodus.fedaykin.here> X-Google-Sender-Auth: aace3cf604a4044b Cc: freebsd-current@freebsd.org Subject: Re: hang on startx with nvidia / also with emu10kx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 12:11:32 -0000 2007/9/14, Mario Sergio Fujikawa Ferreira : > Hi, > > FreeBSD exxodus.fedaykin.here 7.0-CURRENT FreeBSD 7.0-CURRENT #9: Thu Sep 13 22:46:14 BRT 2007 lioux@exxodus:/usr/src/sys/i386/compile/LIOUX i386 > > -CURRENT as of today September 13th 2007 with latest ports. > xorg works fine if I launch it with tightvnc. However, the system > hangs if I try to startx using the nvidia driver. The same happens > if I try to kldload emu10kx. > > How do I force the system to issue a kernel dump when it > hangs? I want to be able to provide a proper backtrace of the system > if possible. :) Please recompile the kernel with all the debugging options on (with KDB, DDB, INVARIANTS, INVARIANT_SUPPORT, WITNESS, and without WITNESS_SKIPSPIN, KDB_UNATTENDED). Then, when your kernel hangs, just press ctrl+alt+esc and you should break in ddb. At that point it would be useful to have informations about following commands: - ps - show alllocks - the backtrace of any thread (you can get it only switching to its stack frame and doing a 'bt') Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 12:14:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490FC16A41A for ; Fri, 14 Sep 2007 12:14:00 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from farris.bafirst.com (adsl-065-081-102-002.sip.jan.bellsouth.net [65.81.102.2]) by mx1.freebsd.org (Postfix) with ESMTP id D2FC413C428 for ; Fri, 14 Sep 2007 12:13:59 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.12.64]) by farris.bafirst.com with esmtp; Fri, 14 Sep 2007 07:13:57 -0500 id 0006D415.46EA7B05.00015EEA Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Fri, 14 Sep 2007 07:13:56 -0500 id 0004AC29.46EA7B04.000000D7 Received: from dsl-189-129-12-64.prod-infinitum.com.mx (dsl-189-129-12-64.prod-infinitum.com.mx [189.129.12.64]) by intranet.encontacto.net (Horde MIME library) with HTTP; Fri, 14 Sep 2007 07:13:56 -0500 Message-ID: <20070914071356.lxl5mwubqosooc08@intranet.encontacto.net> X-Priority: 3 (Normal) Date: Fri, 14 Sep 2007 07:13:56 -0500 From: eculp@encontacto.net To: freebsd-current@freebsd.org References: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> In-Reply-To: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) X-Originating-IP: 189.129.12.64 Subject: Re: Lawsuit over ZFS - any impact for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 12:14:00 -0000 Quoting Justin Smith : > FYI: > > Network Appliance suing Sun over ZFS > > http://blogs.netapp.com/dave/2007/09/netapp-sues-sun.html The sun side is equally interesting, in my opinion: http://blogs.sun.com/jonathan/entry/on_patent_trolling ed > -- > JS > _______________________________________________ > 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 Sep 14 12:48:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A707216A417 for ; Fri, 14 Sep 2007 12:48:18 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5E313C442 for ; Fri, 14 Sep 2007 12:48:18 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so670158nfb for ; Fri, 14 Sep 2007 05:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=6I7BC050leB1pYl8p8hbNl4s3Phy49ey3epcDJVGDQc=; b=JjMVPv/D+5kSXTZqf8dCle0r3HYcm/csdSur/6H7vtYfVUCwRwuTxo+cpBlPUW4bMtGIsZiLeghjoUM6uOl7knbOU528DmHDu6Lh32A/a1x1tpUmd0X+AsRmBsL7buIyeV1fPxfUeea+mvSX+Qr3asyscOMR4NxWggdY01hY8rE= 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=ZD+2gYWYhTq3u6kUlwKlpfrFxZRJwWtnYa7EQiw5OZl+nxOI9NCBRaGB/FHUYTkAU6jKHW2BxwKfeIPVFCSkUHU0eSccxRFwN4qdWY22pUdy5GSi3WpkoBd9JO420aHNGCx+g+OSU8Ag3I8h4izJIrcjz0/+8TArXCS7F1oHPvE= Received: by 10.86.89.4 with SMTP id m4mr1385562fgb.1189774096113; Fri, 14 Sep 2007 05:48:16 -0700 (PDT) Received: by 10.86.25.2 with HTTP; Fri, 14 Sep 2007 05:48:16 -0700 (PDT) Message-ID: <47d0403c0709140548k7f0208a5tcd9c1497b7581e26@mail.gmail.com> Date: Fri, 14 Sep 2007 12:48:16 +0000 From: "Ben Kaduk" To: danger@rulez.sk In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2E4631F6-0AE9-4451-A51A-BCF4DB8DECEC@ish.com.au> Cc: freebsd-current@freebsd.org, bug-followup@freebsd.org Subject: Re: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 12:48:18 -0000 Hi Daniel On 9/13/07, Daniel Ger=9Eo wrote: > > Hello Aristedes, > > On Thu, 13 Sep 2007 09:22:10 +1000, Aristedes Maniatis > wrote: > > > * Is there a set release schedule and known bugs notes for snapshots? > > I'd like to try a snapshot but I don't know whether to wait a day/ > > week/month for the next one. Or are they released just when someone > > thinks the source is in a good overall state? > > You can get the very recent snapshot at http://snapshots.us.freebsd.org/. > They are built on a daily basis. > I have an open PR -- docs/115000 -- which includes a patch to the FreeBSD FAQ's to the effect that snapshots are monthly, not daily. Do you think it is reasonable for me to change that part of the patch to point to the daily snapshots that you mention here? Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 13:19:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7E1A16A420 for ; Fri, 14 Sep 2007 13:19:52 +0000 (UTC) (envelope-from miwi@FreeBSD.org) Received: from mail.unixfreunde.de (mail.unixfreunde.de [217.172.44.88]) by mx1.freebsd.org (Postfix) with ESMTP id 64BDC13C459 for ; Fri, 14 Sep 2007 13:19:52 +0000 (UTC) (envelope-from miwi@FreeBSD.org) Received: from mail.unixfreunde.de (mail.unixfreunde.de [217.172.44.88]) by mail.unixfreunde.de (Postfix) with SMTP id 4F0C8E6791 for ; Fri, 14 Sep 2007 13:02:59 +0000 (UTC) Received: from miwi.homeunix.com (dslb-082-083-128-170.pools.arcor-ip.net [82.83.128.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.unixfreunde.de (Postfix) with ESMTP id 7275DE6032; Fri, 14 Sep 2007 13:02:54 +0000 (UTC) Date: Fri, 14 Sep 2007 15:00:54 +0200 From: Martin Wilke To: "Zahemszky Gabor" In-Reply-To: <20070907162310.22464.qmail@mail.integrity.hu> References: <20070907162310.22464.qmail@mail.integrity.hu> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) User-Agent: miwi@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_rresZFuLVbhl3_tIRKOdq7X; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-Id: <20070914130256.7275DE6032@mail.unixfreunde.de> X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Sep 14 13:02:58 2007 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 125,46ea868213412121813794 Cc: freebsd-current@freebsd.org Subject: Re: Claws-mail - core dumped X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 13:19:52 -0000 --Sig_rresZFuLVbhl3_tIRKOdq7X Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 07 Sep 2007 18:23:10 +0200 "Zahemszky Gabor" wrote: |Hi!=20 | |Are there anybody out there, who can use - either the old (2.10) or |the new (3.0) version of Claws-Mail n CURRENT? I used it from 1st |January without any problem, but 2 or 3 weeks ago, it once dumped |core, and since then, I cannot write letter with it. I can start it, I |can read (and download) my mails from the server, but pressing the |"New mail" or the "Reply" button generates a core dump. I tried it |with old mails in ~/Mail and with the original ~/.claws-mail , and |with/out the one or the other, doesn't matter. I recompiled it |(recursively with portmaster -f ), upgraded it, the same.=20 | |Anybody has any clue?=20 | |Thanks, Zahy < Gabor at Zahemszky dot HU >=20 | |PS: one of my CURRENT-running friends tried it. Installed it, and get |the same -> sending mail generates a core. | Hi, I need few more infos. What does "uname -a" and "pkg_info" output? Is there a core dump? Thanks miwi --=20 Martin Wilke | irc.unixfreunde.de #bsd=20 miwi@FreeBSD.org | miwi@unixfreunde.de FreeBSD Committer | Power to Serve --Sig_rresZFuLVbhl3_tIRKOdq7X Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG6oYGFwpycAVoI1MRAkS+AJ9M6i82yD0uVvy/T8rNq3q3ucpgzgCgrenu A4KkJe8K+bbohksJi5dyEig= =M2xs -----END PGP SIGNATURE----- --Sig_rresZFuLVbhl3_tIRKOdq7X-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 14:28:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FC916A421 for ; Fri, 14 Sep 2007 14:28:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id CE95713C469 for ; Fri, 14 Sep 2007 14:28:35 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.15] (helo=mx5.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IWC9q-00010V-Cg for freebsd-current@freebsd.org; Fri, 14 Sep 2007 16:28:34 +0200 Received: from x1fa2.x.pppool.de ([89.59.31.162]:61072 helo=peedub.jennejohn.org) by mx5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68-dev #12) id 1IWC9q-0005Qb-7H for freebsd-current@freebsd.org; Fri, 14 Sep 2007 16:28:34 +0200 Date: Fri, 14 Sep 2007 16:28:33 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20070914162833.1994a964@peedub.jennejohn.org> In-Reply-To: <20070914130256.7275DE6032@mail.unixfreunde.de> References: <20070907162310.22464.qmail@mail.integrity.hu> <20070914130256.7275DE6032@mail.unixfreunde.de> Organization: DENX Softwre Engineering GmbH X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.13; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Claws-mail - core dumped X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.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, 14 Sep 2007 14:28:36 -0000 On Fri, 14 Sep 2007 15:00:54 +0200 Martin Wilke wrote: > On Fri, 07 Sep 2007 18:23:10 +0200 > "Zahemszky Gabor" wrote: > > |Hi! > | > |Are there anybody out there, who can use - either the old (2.10) or > |the new (3.0) version of Claws-Mail n CURRENT? I used it from 1st > |January without any problem, but 2 or 3 weeks ago, it once dumped > |core, and since then, I cannot write letter with it. I can start it, I > |can read (and download) my mails from the server, but pressing the > |"New mail" or the "Reply" button generates a core dump. I tried it > |with old mails in ~/Mail and with the original ~/.claws-mail , and > |with/out the one or the other, doesn't matter. I recompiled it > |(recursively with portmaster -f ), upgraded it, the same. > | > |Anybody has any clue? > | > |Thanks, Zahy < Gabor at Zahemszky dot HU > > | > |PS: one of my CURRENT-running friends tried it. Installed it, and get > |the same -> sending mail generates a core. > | > Hi, > > I need few more infos. What does "uname -a" and "pkg_info" output? Is > there a core dump? > Just an additional data point. I installed a fresh kernel and unserland on September 7th. I also installed claws-mail the same day. I've had no problem composing, sending or replying to mail. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 14:39:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6D216A417; Fri, 14 Sep 2007 14:39:51 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7A713C458; Fri, 14 Sep 2007 14:39:51 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 251D75C71; Fri, 14 Sep 2007 16:20:22 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.rulez.sk Received: by mail.rulez.sk (Postfix, from userid 80) id BC0715C43; Fri, 14 Sep 2007 16:20:19 +0200 (CEST) To: Ben Kaduk MIME-Version: 1.0 Date: Fri, 14 Sep 2007 16:20:19 +0200 From: =?UTF-8?Q?Daniel_Ger=C5=BEo?= Organization: The FreeBSD Project In-Reply-To: <47d0403c0709140548k7f0208a5tcd9c1497b7581e26@mail.gmail.com> References: <47d0403c0709140548k7f0208a5tcd9c1497b7581e26@mail.gmail.com> Message-ID: X-Sender: danger@FreeBSD.org User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, bug-followup@freebsd.org Subject: Re: 7 release timetable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danger@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: Fri, 14 Sep 2007 14:39:51 -0000 On Fri, 14 Sep 2007 12:48:16 +0000, "Ben Kaduk" wrote: > Hi Daniel > > On 9/13/07, Daniel Geržo wrote: >> >> Hello Aristedes, >> >> On Thu, 13 Sep 2007 09:22:10 +1000, Aristedes Maniatis >> wrote: >> >> > * Is there a set release schedule and known bugs notes for snapshots? >> > I'd like to try a snapshot but I don't know whether to wait a day/ >> > week/month for the next one. Or are they released just when someone >> > thinks the source is in a good overall state? >> >> You can get the very recent snapshot at > http://snapshots.us.freebsd.org/. >> They are built on a daily basis. >> > > I have an open PR -- docs/115000 -- which includes > a patch to the FreeBSD FAQ's to the effect that snapshots > are monthly, not daily. Do you think it is reasonable for me to > change that part of the patch to point to the daily snapshots > that you mention here? Of course, your update would be welcome. I can handle your PR then and commit it to the tree. Just let me know when it's updated. > > Thanks, > -- Sincerely, Daniel Geržo From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 14:50:49 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3784716A418 for ; Fri, 14 Sep 2007 14:50:49 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 102AE13C442 for ; Fri, 14 Sep 2007 14:50:48 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l8EEogIA012893; Fri, 14 Sep 2007 09:50:42 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 14 Sep 2007 09:50:42 -0500 (CDT) From: "Sean C. Farley" To: freebsd-current@FreeBSD.org In-Reply-To: <200709121517.l8CFHK8L086335@lurza.secnetix.de> Message-ID: References: <200709121517.l8CFHK8L086335@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, FB_WORD1_END_DOLLAR autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: sergei@FreeBSD.org Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 14:50:49 -0000 On Wed, 12 Sep 2007, Oliver Fromme wrote: > Hi, > > (I've already posted this a few days ago, but it didn't > seem to get through to the list. I have updated the > 7-current machine today, and the problem is still the > same.) > > This started to happen after updating to a recent 7-current > about one week ago (it was working fine with a previous 7- > current that was a few weeks older). The shell is zsh. > > zsh$ /usr/bin/su > /libexec/ld-elf.so.1: environment corrupt; missing value for > zsh$ Did you also upgrade zsh at the same time? You should have been having troubles with zsh much earlier since my change to the *env() function went in early July. :) zsh 4.3.4 has a bug where it was mixing calls to *env() functions with direct manipulation of environ. The CVS version of zsh is fixed. I created PR ports/115094[1] to patch it in the ports tree about a month ago. *nudging sergei* :) > So su(1) fails to start. Interestingly, when I first start > an sh shell, I still get the same error message, but the > shell starts anyway. Then I can use su(1) without problems: > > zsh$ sh > sh: environment corrupt; missing value for > $ /usr/bin/su > Password: > > It was my impression that there should be more printed in > the error message after "missing value for", so I made a > hexdump: > > 6e 67 20 76 61 6c 75 65 20 66 6f 72 20 1b 5b 34 |ng value for .[4| > 7e 0a |~.| There should be something besides ^[[4~ printed, but the internal function __merge_environ() has been presented with an environ it could not handle. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115094 -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 15:01:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8430716A417; Fri, 14 Sep 2007 15:01:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 0691D13C442; Fri, 14 Sep 2007 15:01:37 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [192.38.9.151] (account mc467741@c2i.net HELO laptop) by mailfe03.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 619618122; Fri, 14 Sep 2007 17:01:35 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Date: Fri, 14 Sep 2007 17:01:50 +0200 User-Agent: KMail/1.9.7 References: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> In-Reply-To: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709141701.51507.hselasky@c2i.net> Cc: Zahemszky =?iso-8859-2?q?G=E1bor?= Subject: Re: crash (and the backtrace) in the new if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 15:01:38 -0000 Hi, Maybe there is a race condition in the ZYD driver because Giant is not lock= ed=20 when calling the start routine? =2D-HPS On Saturday 08 September 2007, Zahemszky G=E1bor wrote: > Hi! > > I tried the new if_zyd driver with my new Lutec WLA-54L USB-stick on a > today-based CURRENT. My machine recognised it correctly when I plugged > in it: > > zyd0: on uhub2 > zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:65:66:00 > zyd0: Ethernet address: 00:02:72:65:66:00 > > But when I "ifconfig zyd0 up" -ed it, the machine crashed. Here > is the backtrace of it: > From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 15:19:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3540116A420 for ; Fri, 14 Sep 2007 15:19:38 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id C6F2513C4E1 for ; Fri, 14 Sep 2007 15:19:37 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.1/8.14.1) with ESMTP id l8EFJaA1059406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Sep 2007 10:19:37 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1/Submit) id l8EF7QZW033962; Fri, 14 Sep 2007 10:07:26 -0500 (CDT) (envelope-from dan) Date: Fri, 14 Sep 2007 10:07:26 -0500 From: Dan Nelson To: freebsd-current@freebsd.org, olli@secnetix.de Message-ID: <20070914150725.GD3693@dan.emsphone.com> References: <200709071500.l87F02js018987@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709071500.l87F02js018987@lurza.secnetix.de> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 15:19:38 -0000 In the last episode (Sep 07), Oliver Fromme said: > This started to happen after updating to a recent 7-current > about one week ago (it was working fine with a previous 7- > current that was a few weeks older). The shell is zsh. > > zsh$ /usr/bin/su > /libexec/ld-elf.so.1: environment corrupt; missing value for > zsh$ Try applying the patch in PR 115094. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 17:12:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34EFF16A419; Fri, 14 Sep 2007 17:12:37 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id F10B413C45D; Fri, 14 Sep 2007 17:12:36 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JOD00G5XACZ0F80@mta-1.ms.rz.RWTH-Aachen.de>; Fri, 14 Sep 2007 18:41:23 +0200 (CEST) Received: from talos.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.3.22]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 14 Sep 2007 18:41:23 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.8/1) with ESMTP id l8EGfNoJ030405; Fri, 14 Sep 2007 18:41:23 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IWEEN-00027k-1m; Fri, 14 Sep 2007 18:41:23 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id B47D33F41B; Fri, 14 Sep 2007 18:41:17 +0200 (CEST) Date: Fri, 14 Sep 2007 18:41:17 +0200 From: Christian Brueffer In-reply-to: <46E0777A.8070901@root.org> To: Nate Lawson Message-id: <20070914164117.GC1872@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=raC6veAxrt5nqIoY Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.20,256,1186351200"; d="scan'208";a="22613638" X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <46E0777A.8070901@root.org> User-Agent: Mutt/1.5.11 Cc: acpi@FreeBSD.ORG, current@FreeBSD.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 17:12:37 -0000 --raC6veAxrt5nqIoY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test and > let me know if you get any new errors on dmesg or if it fixes things for > you (especially HP/Compaq laptop owners). >=20 Tested version c on a Thinkpad T41p, everything worked before, everything works now. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --raC6veAxrt5nqIoY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFG6rmtbHYXjKDtmC0RAuuVAJ0YJjtQzElsB/h1FvR7ExESxqzmrQCg7TcJ E81UtFga8jtRYSi4eJWdM/s= =g2PP -----END PGP SIGNATURE----- --raC6veAxrt5nqIoY-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 18:15:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52DC316A417 for ; Fri, 14 Sep 2007 18:15:16 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 4377713C480 for ; Fri, 14 Sep 2007 18:15:16 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.20,256,1186383600"; d="scan'208";a="524117643" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2007 11:15:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8EIFG62003925 for ; Fri, 14 Sep 2007 11:15:16 -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 l8EIFDVx000792 for ; Fri, 14 Sep 2007 18:15:15 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); Fri, 14 Sep 2007 11:15:13 -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); Fri, 14 Sep 2007 11:15:13 -0700 Message-ID: <46EACF9C.9050702@cisco.com> Date: Fri, 14 Sep 2007 14:14:52 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 18:15:13.0532 (UTC) FILETIME=[31C13BC0:01C7F6FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9290; t=1189793716; x=1190657716; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Trouble=20with=20xorg |Sender:=20; bh=+BkYRKJqhc/WTF4+SH2QNix9MKyN1bvgEq8f29gSOgM=; b=W5D8kACXgM2xnEX0r7j7rkCfteqS51NIg9XYvJ6FZvYXTsCbYcU8YczGTmERUMs22l7IWvbr TSz4wOzUSyQSGAFHH8G9X98PeggGsMmIvwNXAil6MGP3p18bJbsPt6G6; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Subject: Trouble with xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 18:15:16 -0000 Hi all: I just picked up the current disk snapshot and loaded my two new machines with 7.0.. of course xorg was not present in the disks.. soo.. I went and got the latest ports and into the xorg directory and did the make install... and I get: *********************************************************************** if /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT KeysymStr.lo -MD -MP -MF ".deps/KeysymStr.Tpo" -c -o KeysymStr.lo KeysymStr.c; then mv -f ".deps/KeysymStr.Tpo" ".deps/KeysymStr.Plo"; else rm -f ".deps/KeysymStr.Tpo"; exit 1; fi cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT KeysymStr.lo -MD -MP -MF .deps/KeysymStr.Tpo -c KeysymStr.c -fPIC -DPIC -o .libs/KeysymStr.o cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT KeysymStr.lo -MD -MP -MF .deps/KeysymStr.Tpo -c KeysymStr.c -o KeysymStr.o >/dev/null 2>&1 if /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DI R_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT StrKeysym.lo -MD -MP -MF ".deps/StrKeysym.Tpo" -c -o StrKeysym.lo StrKeysym.c; then mv -f ".deps/StrKeysym.Tpo" ".deps/StrKeysym.Plo"; else rm -f ".deps/StrKeysym.Tpo"; exit 1; fi cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT StrKeysym.lo -MD -MP -MF .deps/StrKeysym.Tpo -c StrKeysym.c -fPIC -DPIC -o .libs/StrKeysym.o cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT StrKeysym.lo -MD -MP -MF .deps/StrKeysym.Tpo -c StrKeysym.c -o StrKeysym.o >/dev/null 2>&1 /bin/sh /usr/local/bin/libtool --tag=CC --mode=link cc -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -o libX11.la -rpath /usr/local/lib -version-number 6:2:0 -no-undefined AllCells.lo AllowEv.lo AllPlanes.lo AutoRep.lo Backgnd.lo BdrWidth.lo Bell.lo Border.lo ChAccCon.lo ChActPGb.lo ChClMode.lo ChCmap.lo ChGC.lo ChKeyCon.lo ChkIfEv.lo ChkMaskEv.lo ChkTypEv.lo ChkTypWEv.lo ChkWinEv.lo ChPntCon.lo ChProp.lo ChSaveSet.lo ChWAttrs.lo ChWindow.lo CirWin.lo CirWinDn.lo CirWinUp.lo ClDisplay.lo ClearArea.lo Clear.lo ConfWind.lo Context.lo ConvSel.lo CopyArea.lo CopyCmap.lo CopyGC.lo CopyPlane.lo CrBFData.lo CrCmap.lo CrCursor.lo CrGC.lo CrGlCur.lo CrPFBData.lo CrPixmap.lo CrWindow.lo Cursor.lo DefCursor.lo DelProp.lo Depths.lo DestSubs.lo DestWind.lo DisName.lo DrArc.lo DrArcs.lo DrLine.lo DrLines.lo DrPoint.lo DrPoints.lo DrRect.lo DrRects.lo DrSegs.lo ErrDes.lo ErrHndlr.lo evtomask.lo EvToWire.lo FetchName.lo FillArc.lo FillArcs.lo FillPoly.lo FillRct.lo FillRcts.lo FilterEv.lo Flush.lo Font.lo FontInfo.lo FontNames.lo FreeCmap.lo FreeCols.lo FreeCurs.lo FreeEData.lo FreeGC.lo FreePix.lo FSSaver.lo FSWrap.lo GCMisc.lo Geom.lo GetAtomNm.lo GetColor.lo GetDflt.lo GetFPath.lo GetFProp.lo GetGCVals.lo GetGeom.lo GetHColor.lo GetHints.lo GetIFocus.lo GetImage.lo GetKCnt.lo GetMoEv.lo GetNrmHint.lo GetPCnt.lo GetPntMap.lo GetProp.lo GetRGBCMap.lo GetSOwner.lo GetSSaver.lo GetStCmap.lo GetTxtProp.lo GetWAttrs.lo GetWMCMapW.lo GetWMProto.lo globals.lo GrButton.lo GrKeybd.lo GrKey.lo GrPointer.lo GrServer.lo Host.lo Iconify.lo IfEvent.lo imConv.lo ImText16.lo ImText.lo ImUtil.lo InitExt.lo InsCmap.lo IntAtom.lo KeyBind.lo KeysymStr.lo KillCl.lo LiHosts.lo LiICmaps.lo LiProps.lo ListExt.lo LoadFont.lo LockDis.lo locking.lo LookupCol.lo LowerWin.lo Macros.lo MapRaised.lo MapSubs.lo MapWindow.lo MaskEvent.lo Misc.lo ModMap.lo MoveWin.lo NextEvent.lo OCWrap.lo OMWrap.lo OpenDis.lo ParseCmd.lo ParseCol.lo ParseGeom.lo PeekEvent.lo PeekIfEv.lo Pending.lo PixFormats.lo PmapBgnd.lo PmapBord.lo PolyReg.lo PolyTxt16.lo PolyTxt.lo PropAlloc.lo PutBEvent.lo PutImage.lo Quarks.lo QuBest.lo QuColor.lo QuColors.lo QuCurShp.lo QuExt.lo QuKeybd.lo QuPntr.lo QuStipShp.lo QuTextE16.lo QuTextExt.lo QuTileShp.lo QuTree.lo RaiseWin.lo RdBitF.lo RecolorC.lo ReconfWin.lo ReconfWM.lo Region.lo RegstFlt.lo RepWindow.lo RestackWs.lo RotProp.lo ScrResStr.lo SelInput.lo SendEvent.lo SetBack.lo SetClMask.lo SetClOrig.lo SetCRects.lo SetDashes.lo SetFont.lo SetFore.lo SetFPath.lo SetFunc.lo SetHints.lo SetIFocus.lo SetLocale.lo SetLStyle.lo SetNrmHint.lo SetPMask.lo SetPntMap.lo SetRGBCMap.lo SetSOwner.lo SetSSaver.lo SetState.lo SetStCmap.lo SetStip.lo SetTile.lo SetTSOrig.lo SetTxtProp.lo SetWMCMapW.lo SetWMProto.lo StBytes.lo StColor.lo StColors.lo StName.lo StNColor.lo StrKeysym.lo StrToText.lo Sync.lo Synchro.lo Text16.lo Text.lo TextExt16.lo TextExt.lo TextToStr.lo TrCoords.lo UndefCurs.lo UngrabBut.lo UngrabKbd.lo UngrabKey.lo UngrabPtr.lo UngrabSvr.lo UninsCmap.lo UnldFont.lo UnmapSubs.lo UnmapWin.lo VisUtil.lo WarpPtr.lo Window.lo WinEvent.lo Withdraw.lo WMGeom.lo WMProps.lo WrBitF.lo XlibAsync.lo XlibInt.lo Xrm.lo ConnDis.lo x11_trans.lo xlibi18n/libi18n.la xcms/libxcms.la xkb/libxkb.la -L/usr/local/lib -lXau -L/usr/local/lib -lXdmcp -lrpcsvc libtool: link: `StrToText.lo' is not a valid libtool object *** Error code 1 Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. *** Error code 1 Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. *** Error code 1 Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. *** Error code 1 Stop in /usr/ports/x11/libX11/work/libX11-1.1.2. *** Error code 1 Stop in /usr/ports/x11/libX11. *** Error code 1 Stop in /usr/ports/graphics/dri. *** Error code 1 Stop in /usr/ports/x11/xorg. ********************************************************** Any ideas? Did I miss some step? R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 18:57:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB15316A417 for ; Fri, 14 Sep 2007 18:57:28 +0000 (UTC) (envelope-from probsd@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E87D13C46B for ; Fri, 14 Sep 2007 18:57:28 +0000 (UTC) (envelope-from probsd@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1908657pyb for ; Fri, 14 Sep 2007 11:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=RFzPFqhuz9qeuy4qFsuZMDqX22kkzhz5XDhSvHy4Rtc=; b=c/seES+uPDlEmF3PlE+TKXtgeY84DYxE/rbHJ+wxuSmNuiNknrg0vPuTf1rKB0ZR8X5bYGdl7iedOJCRJk3oatMmYX2XcrDm0PG/xyGgoTdXQxUPqDwC1ZcfNDizoTAVYGYMpWsgNLxhpr3R+oNo3RpqW7SxOdZlollkXAQwBfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=BHyNozdTq7N6/VoxNxJtOn2SNi4ITxhkwulkeYqHbAi22Q2yqIYiRPAfbRZkvPVvxQuqV5l4klxvG7fJQnzLqLPYvgDRa/jMAflDBfTPLgYdLC1WG5r4nprncVcyXn4mxpo/B2sk1fMyVztYKxviMW4KITQ8TVNJjOcUgdXWbVU= Received: by 10.35.10.13 with SMTP id n13mr2553842pyi.1189794677955; Fri, 14 Sep 2007 11:31:17 -0700 (PDT) Received: from rcpu ( [76.238.81.71]) by mx.google.com with ESMTPS id a2sm1343554pyi.2007.09.14.11.31.12 (version=SSLv3 cipher=RC4-MD5); Fri, 14 Sep 2007 11:31:13 -0700 (PDT) Message-ID: <00b201c7f6fd$80fea7c0$040aa8c0@rcpu> From: "Rick" To: "Randall Stewart" , References: <46EACF9C.9050702@cisco.com> Date: Fri, 14 Sep 2007 13:31:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: Subject: Re: Trouble with xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 18:57:28 -0000 Hi Randall, Just to get things going faster for you why don't you just do "pkg_add -r xorg"? Good luck. Rick ----- Original Message ----- From: "Randall Stewart" To: Sent: Friday, September 14, 2007 1:14 PM Subject: Trouble with xorg > Hi all: > > I just picked up the current disk snapshot and loaded > my two new machines with 7.0.. of course xorg was > not present in the disks.. soo.. I went and got > the latest ports and into the xorg directory and did > the make install... and I get: > *********************************************************************** > if /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE > -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe > -MT KeysymStr.lo -MD -MP -MF ".deps/KeysymStr.Tpo" -c -o KeysymStr.lo > KeysymStr.c; then mv -f ".deps/KeysymStr.Tpo" ".deps/KeysymStr.Plo"; else > rm -f ".deps/KeysymStr.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t > -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT > KeysymStr.lo -MD -MP -MF .deps/KeysymStr.Tpo -c > KeysymStr.c -fPIC -DPIC -o .libs/KeysymStr.o > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t > -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT > KeysymStr.lo -MD -MP -MF .deps/KeysymStr.Tpo -c KeysymStr.c -o KeysymStr.o > >/dev/null 2>&1 > if /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DI > R_BIT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t > -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT > StrKeysym.lo -MD -MP -MF ".deps/StrKeysym.Tpo" -c -o StrKeysym.lo > StrKeysym.c; then mv -f ".deps/StrKeysym.Tpo" ".deps/StrKeysym.Plo"; else > rm -f ".deps/StrKeysym.Tpo"; exit 1; fi > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t > -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT > StrKeysym.lo -MD -MP -MF .deps/StrKeysym.Tpo -c > StrKeysym.c -fPIC -DPIC -o .libs/StrKeysym.o > cc -DHAVE_CONFIG_H -I. -I. -I. -I../include/X11 -I../include -I../include/X11 > -I../include -I../include/X11 -I../src/xcms -I../src/xkb -I../src/xlibi18n > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include > -I/usr/local/include -I/usr/local/include -DHASXDMAUTH -D_BSD_SOURCE -DX11_t > -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL -O2 -fno-strict-aliasing -pipe -MT > StrKeysym.lo -MD -MP -MF .deps/StrKeysym.Tpo -c StrKeysym.c -o StrKeysym.o > >/dev/null 2>&1 > /bin/sh /usr/local/bin/libtool --tag=CC --mode=link > cc -I../include -I../include/X11 -I../include -I../include/X11 -I../src/xcms > -I../src/xkb -I../src/xlibi18n -Wall -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include > -DHASXDMAUTH -D_BSD_SOURCE -DX11_t -DTRANS_CLIENT -DMALLOC_0_RETURNS_NULL > -O2 -fno-strict-aliasing -pipe -o libX11.la -rpath > /usr/local/lib -version-number 6:2:0 -no-undefined AllCells.lo AllowEv.lo > AllPlanes.lo AutoRep.lo Backgnd.lo BdrWidth.lo Bell.lo Border.lo > ChAccCon.lo ChActPGb.lo ChClMode.lo ChCmap.lo ChGC.lo ChKeyCon.lo > ChkIfEv.lo ChkMaskEv.lo ChkTypEv.lo ChkTypWEv.lo ChkWinEv.lo ChPntCon.lo > ChProp.lo ChSaveSet.lo ChWAttrs.lo ChWindow.lo CirWin.lo CirWinDn.lo > CirWinUp.lo ClDisplay.lo ClearArea.lo Clear.lo ConfWind.lo Context.lo > ConvSel.lo CopyArea.lo CopyCmap.lo CopyGC.lo CopyPlane.lo CrBFData.lo > CrCmap.lo CrCursor.lo CrGC.lo CrGlCur.lo CrPFBData.lo CrPixmap.lo > CrWindow.lo Cursor.lo DefCursor.lo DelProp.lo Depths.lo DestSubs.lo > DestWind.lo DisName.lo DrArc.lo DrArcs.lo DrLine.lo DrLines.lo DrPoint.lo > DrPoints.lo DrRect.lo DrRects.lo DrSegs.lo ErrDes.lo ErrHndlr.lo > evtomask.lo EvToWire.lo FetchName.lo FillArc.lo FillArcs.lo FillPoly.lo > FillRct.lo FillRcts.lo FilterEv.lo Flush.lo Font.lo FontInfo.lo > FontNames.lo FreeCmap.lo FreeCols.lo FreeCurs.lo FreeEData.lo FreeGC.lo > FreePix.lo FSSaver.lo FSWrap.lo GCMisc.lo Geom.lo GetAtomNm.lo > GetColor.lo GetDflt.lo GetFPath.lo GetFProp.lo GetGCVals.lo GetGeom.lo > GetHColor.lo > GetHints.lo GetIFocus.lo GetImage.lo GetKCnt.lo GetMoEv.lo GetNrmHint.lo > GetPCnt.lo GetPntMap.lo GetProp.lo GetRGBCMap.lo GetSOwner.lo GetSSaver.lo > GetStCmap.lo GetTxtProp.lo GetWAttrs.lo GetWMCMapW.lo GetWMProto.lo > globals.lo GrButton.lo GrKeybd.lo GrKey.lo GrPointer.lo GrServer.lo > Host.lo Iconify.lo IfEvent.lo imConv.lo ImText16.lo ImText.lo ImUtil.lo > InitExt.lo InsCmap.lo IntAtom.lo KeyBind.lo KeysymStr.lo KillCl.lo > LiHosts.lo LiICmaps.lo LiProps.lo ListExt.lo LoadFont.lo LockDis.lo > locking.lo LookupCol.lo LowerWin.lo Macros.lo MapRaised.lo MapSubs.lo > MapWindow.lo MaskEvent.lo Misc.lo ModMap.lo MoveWin.lo NextEvent.lo > OCWrap.lo OMWrap.lo OpenDis.lo ParseCmd.lo ParseCol.lo ParseGeom.lo > PeekEvent.lo PeekIfEv.lo Pending.lo PixFormats.lo PmapBgnd.lo PmapBord.lo > PolyReg.lo PolyTxt16.lo PolyTxt.lo PropAlloc.lo PutBEvent.lo PutImage.lo > Quarks.lo QuBest.lo QuColor.lo QuColors.lo QuCurShp.lo QuExt.lo > QuKeybd.lo QuPntr.lo QuStipShp.lo QuTextE16.lo QuTextExt.lo QuTileShp.lo > QuTree.lo RaiseWin.lo RdBitF.lo RecolorC.lo ReconfWin.lo ReconfWM.lo > Region.lo RegstFlt.lo RepWindow.lo RestackWs.lo RotProp.lo ScrResStr.lo > SelInput.lo SendEvent.lo SetBack.lo SetClMask.lo SetClOrig.lo > SetCRects.lo SetDashes.lo SetFont.lo SetFore.lo SetFPath.lo SetFunc.lo > SetHints.lo SetIFocus.lo SetLocale.lo SetLStyle.lo SetNrmHint.lo > SetPMask.lo SetPntMap.lo SetRGBCMap.lo SetSOwner.lo SetSSaver.lo > SetState.lo SetStCmap.lo SetStip.lo SetTile.lo SetTSOrig.lo SetTxtProp.lo > SetWMCMapW.lo SetWMProto.lo StBytes.lo StColor.lo StColors.lo StName.lo > StNColor.lo StrKeysym.lo StrToText.lo Sync.lo Synchro.lo Text16.lo > Text.lo TextExt16.lo TextExt.lo TextToStr.lo TrCoords.lo UndefCurs.lo > UngrabBut.lo UngrabKbd.lo UngrabKey.lo UngrabPtr.lo UngrabSvr.lo > UninsCmap.lo UnldFont.lo UnmapSubs.lo UnmapWin.lo VisUtil.lo WarpPtr.lo > Window.lo WinEvent.lo Withdraw.lo WMGeom.lo WMProps.lo WrBitF.lo > XlibAsync.lo XlibInt.lo Xrm.lo ConnDis.lo x11_trans.lo xlibi18n/libi18n.la > xcms/libxcms.la > xkb/libxkb.la -L/usr/local/lib -lXau -L/usr/local/lib -lXdmcp -lrpcsvc > libtool: link: `StrToText.lo' is not a valid libtool object > *** Error code 1 > > Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. > *** Error code 1 > > Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. > *** Error code 1 > > Stop in /usr/ports/x11/libX11/work/libX11-1.1.2/src. > *** Error code 1 > > Stop in /usr/ports/x11/libX11/work/libX11-1.1.2. > *** Error code 1 > > Stop in /usr/ports/x11/libX11. > *** Error code 1 > > Stop in /usr/ports/graphics/dri. > *** Error code 1 > > Stop in /usr/ports/x11/xorg. > ********************************************************** > > Any ideas? Did I miss some step? > > > R > -- > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 803-317-4952 (cell) > _______________________________________________ > 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 Sep 14 19:24:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98D916A41A for ; Fri, 14 Sep 2007 19:24:33 +0000 (UTC) (envelope-from SRS0=689b31d93095b6e46b5e8988ac514a49d3ce52e0=458=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 9A60013C48A for ; Fri, 14 Sep 2007 19:24:33 +0000 (UTC) (envelope-from SRS0=689b31d93095b6e46b5e8988ac514a49d3ce52e0=458=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id TCM74530; Fri, 14 Sep 2007 12:24:30 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 72A654500E; Fri, 14 Sep 2007 12:24:30 -0700 (PDT) To: "Rick" In-Reply-To: Your message of "Fri, 14 Sep 2007 13:31:43 CDT." <00b201c7f6fd$80fea7c0$040aa8c0@rcpu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189797870_75971P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 14 Sep 2007 12:24:30 -0700 From: "Kevin Oberman" Message-Id: <20070914192430.72A654500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;;; X-Sender: X-To_Name: Rick X-To_Domain: gmail.com X-To: "Rick" X-To_Email: probsd@gmail.com X-To_Alias: probsd Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: Trouble with xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 19:24:34 -0000 --==_Exmh_1189797870_75971P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: "Rick" > Date: Fri, 14 Sep 2007 13:31:43 -0500 > Sender: owner-freebsd-current@freebsd.org > > Hi Randall, > > Just to get things going faster for you why don't you just do "pkg_add -r > xorg"? > pkg_add -r for current? That is often not a really good idea. Do we have packages built for it? (For the record, I had no build issues with xorg-7.3, but I am seeing some odd keyboard behavior.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1189797870_75971P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG6t/ukn3rs5h7N1ERArlaAJwP7it7+0wg78zs4j1dNMlWlvPuXgCdG19m ce5Z2ry1tyiMIiUlGbWs5pY= =/WS7 -----END PGP SIGNATURE----- --==_Exmh_1189797870_75971P-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 21:32:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CD4B16A417 for ; Fri, 14 Sep 2007 21:32:35 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.freebsd.org (Postfix) with ESMTP id 3B44F13C469 for ; Fri, 14 Sep 2007 21:32:35 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="18161011" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2007 14:32:35 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8ELWXlm004406; Fri, 14 Sep 2007 14:32:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8ELWXuD024333; Fri, 14 Sep 2007 21:32: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); Fri, 14 Sep 2007 14:32:33 -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); Fri, 14 Sep 2007 14:32:32 -0700 Message-ID: <46EAFDDA.7080008@cisco.com> Date: Fri, 14 Sep 2007 17:32:10 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20070914192430.72A654500E@ptavv.es.net> In-Reply-To: <20070914192430.72A654500E@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 21:32:33.0061 (UTC) FILETIME=[C2A9FD50:01C7F716] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=684; t=1189805553; x=1190669553; c=relaxed/simple; s=sjdkim1004; 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=20Trouble=20with=20xorg |Sender:=20; bh=gUaZPHWRitbNeoBVjmT0FovJDTJQBldSMzVkIMP9Yz0=; b=bQaEjFLmtauDCgWIMaz7VVk8Ta1nPtznPSnoJ0R9DiVSYY8SSsK8DcbOltXNF7Zg1bE56dMB jJxbweiBYX2oJTeV3jsU5nm34Ezp9BCNVusTAu4mYO9XhkKeAW9GxcOqAvvlYobP22iuebPHAS uR4JBpFJaNJrz1WaZPbhhsa4U=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: Rick , freebsd-current@freebsd.org Subject: Re: Trouble with xorg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Sep 2007 21:32:35 -0000 Kevin Oberman wrote: >>From: "Rick" >>Date: Fri, 14 Sep 2007 13:31:43 -0500 >>Sender: owner-freebsd-current@freebsd.org >> >>Hi Randall, >> >>Just to get things going faster for you why don't you just do "pkg_add -r >>xorg"? >> > > > pkg_add -r for current? That is often not a really good idea. Do we have > packages built for it? > > (For the record, I had no build issues with xorg-7.3, but I am seeing > some odd keyboard behavior.) Thats why I have not done it.. last time I tried that .. I was in a lot worse way then just not building :-0 R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 22:39:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B533A16A417 for ; Fri, 14 Sep 2007 22:39:22 +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 4B41B13C458 for ; Fri, 14 Sep 2007 22:39:22 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 9E7A41CC26; Sat, 15 Sep 2007 10:39:20 +1200 (NZST) Date: Sat, 15 Sep 2007 10:39:20 +1200 From: Andrew Thompson To: JoaoBR Message-ID: <20070914223920.GB78224@heff.fud.org.nz> References: <200708251905.18834.joao@matik.com.br> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <200708251905.18834.joao@matik.com.br> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: if_wi channel set 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: Fri, 14 Sep 2007 22:39:22 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Aug 25, 2007 at 07:05:18PM -0300, JoaoBR wrote: > > Hi > > I sent this some time ago but nothing changed. > > Whatever channel I try to set on a wi card it stays at channel 3, I use hostap > > Even hardcoding the default channel in if_wi.c does not help, it is not > possible setting the channel to anything else as channel 3 which it is > already when the driver comes up > > somebody has a help for me? Can you please test this patch. Andrew --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wi_hostapchan.diff" Index: if_wi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/wi/if_wi.c,v retrieving revision 1.213 diff -u -p -r1.213 if_wi.c --- if_wi.c 5 Sep 2007 21:31:32 -0000 1.213 +++ if_wi.c 14 Sep 2007 22:36:16 -0000 @@ -608,7 +608,7 @@ wi_power(struct wi_softc *sc, int why) break; case PWR_RESUME: if (ifp->if_flags & IFF_UP) { - wi_init(ifp); + wi_init(sc); (void)wi_intr(sc); } break; @@ -3536,8 +3536,17 @@ wi_set_channel(struct ieee80211com *ic) struct wi_softc *sc = ifp->if_softc; WI_LOCK(sc); - if (!(sc->sc_flags & WI_FLAGS_SCANNING)) { + if (sc->sc_enabled && !(sc->sc_flags & WI_FLAGS_SCANNING)) { sc->wi_channel = ic->ic_curchan; + wi_write_val(sc, WI_RID_OWN_CHNL, + ieee80211_chan2ieee(ic, ic->ic_curchan)); + + if (ic->ic_opmode == IEEE80211_M_HOSTAP && + sc->sc_firmware_type == WI_INTERSIL) { + /* XXX: some cards need to be re-enabled */ + wi_cmd(sc, WI_CMD_DISABLE | WI_PORT0, 0, 0, 0); + wi_cmd(sc, WI_CMD_ENABLE | WI_PORT0, 0, 0, 0); + } } WI_UNLOCK(sc); } --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 03:25:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE93416A419 for ; Sat, 15 Sep 2007 03:25:24 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9F02D13C45A for ; Sat, 15 Sep 2007 03:25:24 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so785132rvb for ; Fri, 14 Sep 2007 20:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=zosaznSzpY+sZApdH0gs2yopszHPK9RhDZ3cqawBZ5s=; b=q6nQK6maxPWcLLdSVzalALGK+Z4/J6Xay1yzRvDSvJueBCZ9KNmXHVknDtBkcdMXz/aoux8tL99/63QKw7jZK8dzjw9bK+ppfXNZtxh1ZzlQdchLLoB3+cP79iiPBzlW2LO+IAqFQazWuOYS55aPnBu+EFWzod2GzSGGy431EvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; b=a+HL+N8MVMx28Q8LsxkuwjkPBU7Lg2kpskOrp1651RYn8KpKkNoT4E4ntZBYdXbTNi0aF4L6EjRAjnv4Cf17+Skr/LEZkzzPnUExQbqHTd1fY4s1dk76lFPSRZkYm/OTbU7Xy0DFqVSw8ah4LdyvI2qIq75Enxm94CJaZSNk5e0= Received: by 10.141.23.7 with SMTP id a7mr186646rvj.1189826723878; Fri, 14 Sep 2007 20:25:23 -0700 (PDT) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id l17sm2552111rvb.2007.09.14.20.25.19 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2007 20:25:21 -0700 (PDT) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Sat, 15 Sep 2007 12:25:07 +0900 Date: Sat, 15 Sep 2007 12:25:07 +0900 To: Zahemszky =?UTF8?Q?G=E1bor?= Message-ID: <20070915032507.GA94238@freebsd.weongyo.org> References: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-current@freebsd.org Subject: Re: crash (and the backtrace) in the new if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 03:25:25 -0000 Hello, I checked your panic in my environment and tried to repeat panic you encountered, but I failed. The panic was happened when you ran `ifconfig zyd0 up'. That means USB rx/tx interrupt pipes works OK and the device initialized successfully. According to your backtrace log, A panic is occured during scanning and `Bad list head....` message is defined QMD_LIST_CHECK_HEAD macro which is defined at `sys/queue.h'. In my opinion, there are a race condition in ehci or zyd. Can you try to build the buildworld and the buildkernel newly with CURRENT and tell me the result after trying to up the zyd driver again? > zyd0: on > uhub2 zyd0: setting config no failed > device_attach: zyd0 attach returned 6 This condition only appears when you reboot FreeBSD, not power on that the current zyd driver has the hardware reset problem. It's a known issue. Thank you for your feedback. :-) Best Regards, Weongyo Jeong On Sat, Sep 08, 2007 at 04:40:03PM +0200, Zahemszky Gbor wrote: > Hi! > > I tried the new if_zyd driver with my new Lutec WLA-54L USB-stick on a > today-based CURRENT. My machine recognised it correctly when I plugged > in it: > > zyd0: on uhub2 > zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:65:66:00 > zyd0: Ethernet address: 00:02:72:65:66:00 > > But when I "ifconfig zyd0 up" -ed it, the machine crashed. Here > is the backtrace of it: > > ==== > Picasso# kgdb -q kernel.debug /var/crash/vmcore.0 > [GDB will not be able to debug user-mode > threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > Unread portion of the kernel message buffer: > panic: Bad list head 0xc519a6bc first->prev != head > cpuid = 1 > KDB: enter: panic > Physical memory: 2009 MB > Dumping 76 MB: 61 45 29 13 > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc048cd99 in db_fncall (dummy1=-444823224, dummy2=0, dummy3=70, > dummy4=0xe57c88b4 "@ðHÀ") > at /usr/src/sys/ddb/db_command.c:486 > #2 0xc048d305 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:401 > #3 0xc048ea75 in db_trap (type=3, code=0) > at /usr/src/sys/ddb/db_main.c:222 > #4 0xc07776d6 in kdb_trap (type=3, code=0, tf=0xe57c8a5c) > at /usr/src/sys/kern/subr_kdb.c:502 > #5 0xc0a0348b in trap (frame=0xe57c8a5c) > at /usr/src/sys/i386/i386/trap.c:621 > #6 0xc09e8eab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0777852 in kdb_enter (msg=0xc0a9b2f4 "panic") at cpufunc.h:60 > #8 0xc0750a04 in panic (fmt=0xc0a55da3 "Bad list head %p > first->prev != head") > at /usr/src/sys/kern/kern_shutdown.c:547 > #9 0xc06a30aa in ehci_device_intr_start (xfer=0xc55b7e00) > at /usr/src/sys/dev/usb/ehci.c:3266 > #10 0xc06a3143 in ehci_device_intr_transfer (xfer=0xc55b7e00) > at /usr/src/sys/dev/usb/ehci.c:3184 > #11 0xc06d1d5b in usbd_start_transfer (arg=0xc55b7e00, segs=0xc5212800, > nseg=1, error=0) > at /usr/src/sys/dev/usb/usbdi.c:388 > #12 0xc09e6155 in bus_dmamap_load (dmat=0xc51e7480, map=0xc0c182c0, > buf=0xe57c8c0a, buflen=0, > callback=0xc06d1be0 , callback_arg=0xc55b7e00, > flags=0) > at /usr/src/sys/i386/i386/busdma_machdep.c:765 > #13 0xc06d22a4 in usbd_transfer (xfer=0xc55b7e00) > at /usr/src/sys/dev/usb/usbdi.c:312 > #14 0xc06b599f in zyd_cmd (sc=0xc5ac3000, code=Variable "code" is not > available. > ) at /usr/src/sys/dev/usb/if_zyd.c:775 > #15 0xc06b5d44 in zyd_read32 (sc=Variable "sc" is not available. > ) at /usr/src/sys/dev/usb/if_zyd.c:819 > #16 0xc06b5dc6 in zyd_lock_phy (sc=0xc5ac3000) > at /usr/src/sys/dev/usb/if_zyd.c:876 > #17 0xc06b7f7a in zyd_set_chan (sc=0xc5ac3000, c=0xc5ac33fc) > at /usr/src/sys/dev/usb/if_zyd.c:1716 > #18 0xc06b8206 in zyd_scantask (arg=0xc5ac3000) > at /usr/src/sys/dev/usb/if_zyd.c:2675 > #19 0xc06ce68a in usb_task_thread (arg=0xc0bafab4) > at /usr/src/sys/dev/usb/usb.c:483 > #20 0xc0732888 in fork_exit (callout=0xc06ce5c0 , > arg=0xc0bafab4, > frame=0xe57c8d38) at /usr/src/sys/kern/kern_fork.c:797 > #21 0xc09e8f20 in fork_trampoline () > at /usr/src/sys/i386/i386/exception.s:205 > (kgdb) > > ==== > > By the way, If I boot the machine with the stick pushed in the > USB-slot, I get the next error message: > > ==== > zyd0: on > uhub2 zyd0: setting config no failed > device_attach: zyd0 attach returned 6 > ==== > > And of course, there won't be a zyd0 interface. > > Can anybody help me to use it? From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 07:34:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFCFD16A46D; Sat, 15 Sep 2007 07:34:45 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE4213C481; Sat, 15 Sep 2007 07:34:45 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JOE00LY6EB4ME30@mta-1.ms.rz.RWTH-Aachen.de>; Sat, 15 Sep 2007 09:04:16 +0200 (CEST) Received: from talos.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.3.22]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sat, 15 Sep 2007 09:04:16 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.8/1) with ESMTP id l8F74Fpl012963; Sat, 15 Sep 2007 09:04:15 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IWRhP-0004h8-HY; Sat, 15 Sep 2007 09:04:15 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 36A653F433; Sat, 15 Sep 2007 09:04:10 +0200 (CEST) Date: Sat, 15 Sep 2007 09:04:10 +0200 From: Christian Brueffer In-reply-to: <46E615C4.1010605@samsco.org> To: Scott Long Message-id: <20070915070409.GA1893@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=qMm9M+Fa2AknHoGS Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.20,258,1186351200"; d="scan'208";a="22687194" X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <46E615C4.1010605@samsco.org> User-Agent: Mutt/1.5.11 Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 07:34:46 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2007 at 10:12:52PM -0600, Scott Long wrote: > All, >=20 > The attached patch should make CAM behave properly with regard to > probing device serial numbers only when the device advertises that > it supports it. It will hopefully eliminate the need for the=20 > CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated=20 > legacy problem that may or may not be possible to fix). This should > especially benefit USB-UMASS devices, where the console output should > be less noisy. It might even make more devices work out-of-the-box. > So please focus testing on USB, but I'd also ask that people test > the following devices as well as any firewire devices: >=20 > * Western Digital My Book 250GB (USB) > * Maxtor Personal Storage 3000XT (Firewire) >=20 Works fine with an external FireWire enclosure here: da0: Fixed Simplified Direct Access SCSI-4= device - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFG64PpbHYXjKDtmC0RAl7CAKCSxJguIbdhqFoczEcpMcY4NMoVcwCg6mCE Tstsmrw7ZYXLjBDxEcBlaU4= =+EM3 -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 07:48:01 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E3516A417; Sat, 15 Sep 2007 07:48:01 +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 5017B13C45E; Sat, 15 Sep 2007 07:48:00 +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 l8F7ldBJ068919; Sat, 15 Sep 2007 01:47:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46EB8E19.6080909@samsco.org> Date: Sat, 15 Sep 2007 01:47:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Krassimir Slavchev References: <46E615C4.1010605@samsco.org> <46EA7077.8010200@bulinfo.net> In-Reply-To: <46EA7077.8010200@bulinfo.net> 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]); Sat, 15 Sep 2007 01:47: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-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 07:48:01 -0000 Thanks a lot for the report, this is very interesting. Scott Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > This patch solves problems with one of my memory sticks: > > http://lists.freebsd.org/pipermail/freebsd-arm/2007-August/000704.html > > Now: > > umass0: on uhub0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 1.000MB/s transfers > da0: 967MB (1981440 512 byte sectors: 64H 32S/T 967C) > > umass0: at uhub0 port 1 (addr 2) disconnected > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > umass0: detached > > > Best Regards > > Scott Long wrote: >> All, >> >> The attached patch should make CAM behave properly with regard to >> probing device serial numbers only when the device advertises that >> it supports it. It will hopefully eliminate the need for the >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated >> legacy problem that may or may not be possible to fix). This should >> especially benefit USB-UMASS devices, where the console output should >> be less noisy. It might even make more devices work out-of-the-box. >> So please focus testing on USB, but I'd also ask that people test >> the following devices as well as any firewire devices: >> >> * Western Digital My Book 250GB (USB) >> * Maxtor Personal Storage 3000XT (Firewire) >> >> Thanks, >> >> Scott >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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" > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFG6nB2xJBWvpalMpkRAgSWAJ9BuFERvPQmWWod6fud9T2lSJpCsACfXhoO > mJVa3xaAmWDYwvtReWZl51I= > =7J6C > -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 08:15:41 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9E816A420; Sat, 15 Sep 2007 08:15:41 +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 6036213C461; Sat, 15 Sep 2007 08:15:41 +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 l8F7kWc5068912; Sat, 15 Sep 2007 01:46:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46EB8DD6.7010103@samsco.org> Date: Sat, 15 Sep 2007 01:46:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Christian Brueffer References: <46E615C4.1010605@samsco.org> <20070915070409.GA1893@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20070915070409.GA1893@haakonia.hitnet.RWTH-Aachen.DE> 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]); Sat, 15 Sep 2007 01:46:32 -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, njl@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 08:15:42 -0000 Christian Brueffer wrote: > On Mon, Sep 10, 2007 at 10:12:52PM -0600, Scott Long wrote: >> All, >> >> The attached patch should make CAM behave properly with regard to >> probing device serial numbers only when the device advertises that >> it supports it. It will hopefully eliminate the need for the >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated >> legacy problem that may or may not be possible to fix). This should >> especially benefit USB-UMASS devices, where the console output should >> be less noisy. It might even make more devices work out-of-the-box. >> So please focus testing on USB, but I'd also ask that people test >> the following devices as well as any firewire devices: >> >> * Western Digital My Book 250GB (USB) >> * Maxtor Personal Storage 3000XT (Firewire) >> > > Works fine with an external FireWire enclosure here: > > da0: Fixed Simplified Direct Access SCSI-4 device > > - Christian > Thanks for testing! Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 09:28:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F5F16A419 for ; Sat, 15 Sep 2007 09:28:28 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2D28213C465 for ; Sat, 15 Sep 2007 09:28:27 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so817740rvb for ; Sat, 15 Sep 2007 02:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=iUIe4OIpsNO5BzRMK5hA70Uc2fL4jZr3zc+qsImIWQU=; b=NNJ107UUm93mF67Mxuf/NEXW2g5hEJOrfbwM643WDlauE7C2B+NRkEZRF8WauTSbRV5b8FrbBKLe5CWYALV6hvdJwQN7e7s7hLD8RcJiLesfCCnvNeSmuFfgvpgN+vmHiHhhEG5Olj/e5B8pPFXvWpntxrtzMMHCs5c7KyLJRCg= 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=OueSqZnTfQD5mQr9J1EW0S3Jc36iJJq6Zr22assGbR+MR2iZdwzqUvYvfEq2MDQdk/YSDgWzWw9OGb/PjY9OPPrYDakc+YvXFoFOKjKO1gYcMsvXglmIWn3GGztSOzgeRrPuYspoGAG8xHacGo3suWuWPKdrLoILPL7J5y391vM= Received: by 10.141.42.10 with SMTP id u10mr183259rvj.1189846782425; Sat, 15 Sep 2007 01:59:42 -0700 (PDT) Received: by 10.141.74.5 with HTTP; Sat, 15 Sep 2007 01:59:42 -0700 (PDT) Message-ID: <2fd864e0709150159p6c78e7e3m3d1f9139c82aa9f5@mail.gmail.com> Date: Sat, 15 Sep 2007 03:59:42 -0500 From: Astrodog To: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <46EB8DD6.7010103@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E615C4.1010605@samsco.org> <20070915070409.GA1893@haakonia.hitnet.RWTH-Aachen.DE> <46EB8DD6.7010103@samsco.org> Cc: Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 09:28:28 -0000 Tested here with a Seagate, Maxtor, and WD USB HDDs, and a Sandisk USB key. Works fine. --- Harrison From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 10:19:58 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C6116A421 for ; Sat, 15 Sep 2007 10:19:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id E71D913C428 for ; Sat, 15 Sep 2007 10:19:57 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so822068rvb for ; Sat, 15 Sep 2007 03:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=mMx/P2ZWJQkhk5Q2f7i9jCT3b0WMJeMfYQfFYNnddiw=; b=jcRd20VwvT8uxM1Qz+oPU4XWesiD3fo3vAM8JXFlQL9dawxs0rN57qcwGmvAP9l67o/iJuuAfZCrWFEgQhiVG6NNXzQXIekuBw5pRbQpEjTXw0H//kjL2hNVDafZI53aAO+ZpdcxqANXGhlt8iTN4pfZmmh1m3yG9BUFC613XTY= 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=JdHXoghDdvVrxS+YZdcawYIszN3J7MZ/gF7DeHi3ted3Ifd1lz+cDk2ZSt9cwh0i8swd7Xc4CpR9p6wDJSWNl79+EB2Ie8NS+eVVYFjsSgMb5XZ9OlkdAoCYQX89Jn6zCiB7HpcDAhnIbhFK/2kyvYHh6gxBapejAQA/XrOcWD8= Received: by 10.140.147.5 with SMTP id u5mr198142rvd.1189851597527; Sat, 15 Sep 2007 03:19:57 -0700 (PDT) Received: by 10.141.86.8 with HTTP; Sat, 15 Sep 2007 03:19:57 -0700 (PDT) Message-ID: Date: Sat, 15 Sep 2007 14:19:57 +0400 From: pluknet To: "Michael Butler" In-Reply-To: <46E993C2.7020700@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E993C2.7020700@protected-networks.net> Cc: current@freebsd.org Subject: Re: apache start-up issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 10:19:58 -0000 On 13/09/2007, Michael Butler wrote: > This is weird .. any ideas? > > imb@mail:/home/imb> sudo /usr/local/etc/rc.d/apache.sh restart > apache not running? (check /var/run/httpd.pid). > Starting apache. > Syntax error on line 205 of /usr/local/etc/apache/httpd.conf: > Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: > /usr/local/libexec/apache/mod_mmap_static.so: Undefined symbol > "ap_null_cleanup" > > .. yet .. > > imb@mail:/home/imb> nm /usr/local/sbin/httpd | grep ap_null_cleanup > 0804b290 T ap_null_cleanup > Hello. An --export-dynamic flag passed to the linker helped me to avoid this issue. wbr, pluknet > Michael From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 13:47:53 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F5616A418 for ; Sat, 15 Sep 2007 13:47:53 +0000 (UTC) (envelope-from kpeter@melbpc.org.au) Received: from vscan01.westnet.com.au (vscan01.westnet.com.au [203.10.1.131]) by mx1.freebsd.org (Postfix) with ESMTP id 1489513C45D for ; Sat, 15 Sep 2007 13:47:53 +0000 (UTC) (envelope-from kpeter@melbpc.org.au) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72CF1761FE4 for ; Sat, 15 Sep 2007 21:20:49 +0800 (WST) Received: from vscan01.westnet.com.au ([127.0.0.1]) by localhost (vscan01.westnet.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07001-18 for ; Sat, 15 Sep 2007 21:20:49 +0800 (WST) Received: from baron.from.hell (dsl-124-150-125-77.vic.westnet.com.au [124.150.125.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vscan01.westnet.com.au (Postfix) with ESMTP id 2B1EC761375 for ; Sat, 15 Sep 2007 21:20:48 +0800 (WST) Message-ID: <46EBDC2F.3070008@melbpc.org.au> Date: Sat, 15 Sep 2007 23:20:47 +1000 From: Peter Kostouros Organization: Melbourne PC User Group User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Intermittent non-responsiveness of system 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: Sat, 15 Sep 2007 13:47:53 -0000 Hi Over about a month I have experienced occasional non-responsiveness from my system (which is cvsup'ed and built roughly weekly). Whereas previously I thought the system had hung, today my system resumed from where it left off after about 10 minutes (on two occasions). During this period of inactivity I was able to ping the nics on the BSD box from another machine on the network, but was unable to ssh into it. Note, I have only noticed this behaviour when I am running X. Is there anything I can do to help resolve the problem? -- Regards Peter As always the organisation disavows knowledge of this email From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 13:53:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3733816A418 for ; Sat, 15 Sep 2007 13:53:20 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id BE45B13C483 for ; Sat, 15 Sep 2007 13:53:19 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l8FDrJi2083502; Sat, 15 Sep 2007 10:53:19 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Andrew Thompson Date: Sat, 15 Sep 2007 10:52:11 -0300 User-Agent: KMail/1.9.7 References: <200708251905.18834.joao@matik.com.br> <20070914223920.GB78224@heff.fud.org.nz> In-Reply-To: <20070914223920.GB78224@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709151052.11939.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: if_wi channel set 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: Sat, 15 Sep 2007 13:53:20 -0000 On Friday 14 September 2007 19:39:20 Andrew Thompson wrote: > On Sat, Aug 25, 2007 at 07:05:18PM -0300, JoaoBR wrote: > > Hi > > > > I sent this some time ago but nothing changed. > > > > Whatever channel I try to set on a wi card it stays at channel 3, I use > > hostap > > > > Even hardcoding the default channel in if_wi.c does not help, it is not > > possible setting the channel to anything else as channel 3 which it is > > already when the driver comes up > > > > somebody has a help for me? > > Can you please test this patch. > Well done! works fine thank's for your help =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 14:53:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1447916A417; Sat, 15 Sep 2007 14:53:30 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id E284513C442; Sat, 15 Sep 2007 14:53:29 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from gotou-daichi-nokonpyuta.local (unknown [192.38.9.151]) by natial.ongs.co.jp (Postfix) with ESMTP id 28CB3244C19; Sat, 15 Sep 2007 23:20:19 +0900 (JST) Message-ID: <46EBEA18.3080800@ongs.co.jp> Date: Sat, 15 Sep 2007 16:20:08 +0200 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Robert Watson References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> In-Reply-To: <20070914110024.G14481@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Harald Schmalzbauer Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 14:53:30 -0000 Robert Watson wrote: > > On Fri, 14 Sep 2007, Harald Schmalzbauer wrote: > >> the first thing I have to do after a csup is to apply the unionfs >> patchset-19-20070504. Is there any chance to get it commited before >> RELENG_7? It fixes at least one nasty bug for me and I haven't had any >> problems with unionfs so far (although constantly, but not heavily used). > > RE has handed this off to Jeff Roberson for some review, and I think I > saw that last week he sent out some questions to Goto-san. As I saw > Goto-san at the front of the room in the first session at EuroBSDCon > this morning, he may be delayed in responding a bit longer. :-) I have sent a answer mail to jeff already, now waiting for his response :) perhaps he is busy. I have a big hope to get merged into FreeBSD until 7-RELEASE. Progress is step by step slowly, but going forward absolutely. If you have interest in unionfs improvements, push your passion to re@ and fs@ committers ;-) > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 Sat Sep 15 17:00:35 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A8B16A419 for ; Sat, 15 Sep 2007 17:00:35 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3D013C442 for ; Sat, 15 Sep 2007 17:00:35 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from [10.0.10.13] (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 0573030122 for ; Sat, 15 Sep 2007 18:00:30 +0100 (BST) Message-ID: <46EC0F32.7020104@cran.org.uk> Date: Sat, 15 Sep 2007 17:58:26 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 17:00:35 -0000 I have a Dell USB keyboard that I'm using with my Athlon XP desktop machine. It works fine on -CURRENT with the exception that the indicator lights don't work as expected. At bootup only the num lock indicator is on, as expected; however, if I press the num lock key the other two indicators come on, and further presses of either num lock or caps lock change the state the keyboard's in but the indicator lights remain lit all the time. Pressing scroll lock toggles all 3 indicator lights on/off. Has anyone else seen this problem? uname -a: FreeBSD tau.draftnet 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Sep 15 12:44:19 BST 2007 brucec@tau.draftnet:/usr/obj/usr/src/sys/MYKERNEL i386 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ums0: on uhub3 ukbd0: on uhub3 kbd2 at ukbd0 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 17:17:43 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 831EE16A417 for ; Sat, 15 Sep 2007 17:17:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAE313C4CB for ; Sat, 15 Sep 2007 17:17:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IWbH4-000339-4y for freebsd-current@FreeBSD.org; Sat, 15 Sep 2007 21:17:42 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IWbIL-0002wp-Ct for freebsd-current@FreeBSD.org; Sat, 15 Sep 2007 21:19:01 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Sat, 15 Sep 2007 21:19:01 +0400 Message-ID: <77319690@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: incorrect mount order X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 17:17:43 -0000 Hi! This seems to be not correct (nullfs is probing/mounting before apropriate filesystem when booting but mount -a is OK): ----- Trying to mount root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init Loading configuration files. kernel dumps on /dev/mirror/gm0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/mirror/gm0s1b as swap device Starting file system checks: /dev/mirror/gm0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0s1a: clean, 59945 free (1377 frags, 7321 blocks, 0.5% fragmentation) fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory /dev/da1: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da1: clean, 236247212 free (836 frags, 29530797 blocks, 0.0% fragmentation) /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1d: clean, 443939667 free (202715 frags, 55467119 blocks, 0.0% fragmentation) /dev/mirror/gm0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0s1e: clean, 253809 free (33 frags, 31722 blocks, 0.0% fragmentation) /dev/mirror/gm0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0s1f: clean, 8615465 free (46793 frags, 1071084 blocks, 0.4% fragmentation) /dev/mirror/gm0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0s1d: clean, 4532467 free (315 frags, 566519 blocks, 0.0% fragmentation) THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: nullfs: /s/usr/ports/distfiles (/var/ftp/pub/FreeBSD/ports/distfiles) Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! SEnter full pathname of shell or RETURN for /bin/sh: # kldstat Id Refs Address Size Name 1 3 0xffffffff80100000 aa4cd0 kernel 2 1 0xffffffff80ba5000 56e8 nullfs.ko 3 1 0xffffffff80bab000 20628 geom_mirror.ko # mount /dev/mirror/gm0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) # mount -a # mount /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) /dev/da0s1d on /ms (ufs, local, soft-updates) /dev/da1 on /s (ufs, local, soft-updates) /s/usr/ports/distfiles on /var/ftp/pub/FreeBSD/ports/distfiles (nullfs, local) # uname -a FreeBSD amd.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Sep 14 12:16:31 MSD 2007 bsam@amd.ipt.ru:/usr/obj/usr/src/sys/GENERIC amd64 ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 17:34:26 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDA316A419 for ; Sat, 15 Sep 2007 17:34:26 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFF213C428 for ; Sat, 15 Sep 2007 17:34:26 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1IWbXF-0004oY-Bc; Sat, 15 Sep 2007 13:34:25 -0400 Date: Sat, 15 Sep 2007 13:34:25 -0400 From: Gary Palmer To: Boris Samorodov Message-ID: <20070915173425.GB927@in-addr.com> Mail-Followup-To: Boris Samorodov , freebsd-current@FreeBSD.org References: <77319690@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77319690@srv.sem.ipt.ru> Cc: freebsd-current@FreeBSD.org Subject: Re: incorrect mount order X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 17:34:26 -0000 On Sat, Sep 15, 2007 at 09:19:01PM +0400, Boris Samorodov wrote: > Hi! > > > This seems to be not correct (nullfs is probing/mounting before > apropriate filesystem when booting but mount -a is OK): > ----- > Trying to mount root from ufs:/dev/mirror/gm0s1a > start_init: trying /sbin/init > Loading configuration files. > kernel dumps on /dev/mirror/gm0s1b > Entropy harvesting: interrupts ethernet point_to_point kickstart. > swapon: adding /dev/mirror/gm0s1b as swap device > Starting file system checks: > /dev/mirror/gm0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0s1a: clean, 59945 free (1377 frags, 7321 blocks, 0.5% fragmentation) > fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory > fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory Are you really sure that you want to try and fsck a nullfs mount? Surely the pass field in the fstab should be '0'? Gary > /dev/da1: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da1: clean, 236247212 free (836 frags, 29530797 blocks, 0.0% fragmentation) > /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1d: clean, 443939667 free (202715 frags, 55467119 blocks, 0.0% fragmentation) > /dev/mirror/gm0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0s1e: clean, 253809 free (33 frags, 31722 blocks, 0.0% fragmentation) > /dev/mirror/gm0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0s1f: clean, 8615465 free (46793 frags, 1071084 blocks, 0.4% fragmentation) > /dev/mirror/gm0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0s1d: clean, 4532467 free (315 frags, 566519 blocks, 0.0% fragmentation) > THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: > nullfs: /s/usr/ports/distfiles (/var/ftp/pub/FreeBSD/ports/distfiles) > Unknown error; help! > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > SEnter full pathname of shell or RETURN for /bin/sh: > # kldstat > Id Refs Address Size Name > 1 3 0xffffffff80100000 aa4cd0 kernel > 2 1 0xffffffff80ba5000 56e8 nullfs.ko > 3 1 0xffffffff80bab000 20628 geom_mirror.ko > # mount > /dev/mirror/gm0s1a on / (ufs, local, read-only) > devfs on /dev (devfs, local) > # mount -a > # mount > /dev/mirror/gm0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) > /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) > /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) > /dev/da0s1d on /ms (ufs, local, soft-updates) > /dev/da1 on /s (ufs, local, soft-updates) > /s/usr/ports/distfiles on /var/ftp/pub/FreeBSD/ports/distfiles (nullfs, local) > # uname -a > FreeBSD amd.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Sep 14 12:16:31 MSD 2007 bsam@amd.ipt.ru:/usr/obj/usr/src/sys/GENERIC amd64 > ----- > > > WBR > -- > Boris Samorodov (bsam) > Research Engineer, http://www.ipt.ru Telephone & Internet SP > FreeBSD committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > 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 Sat Sep 15 17:42:45 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A5B116A419 for ; Sat, 15 Sep 2007 17:42:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 40A5013C46B for ; Sat, 15 Sep 2007 17:42:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IWbfH-00036E-PO for freebsd-current@FreeBSD.org; Sat, 15 Sep 2007 21:42:43 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IWbgZ-0002xl-34 for freebsd-current@FreeBSD.org; Sat, 15 Sep 2007 21:44:03 +0400 To: freebsd-current@FreeBSD.org References: <77319690@srv.sem.ipt.ru> <20070915173425.GB927@in-addr.com> From: Boris Samorodov Date: Sat, 15 Sep 2007 21:44:03 +0400 In-Reply-To: <20070915173425.GB927@in-addr.com> (Gary Palmer's message of "Sat\, 15 Sep 2007 13\:34\:25 -0400") Message-ID: <11238188@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: incorrect mount order X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 17:42:45 -0000 Hello Gary, On Sat, 15 Sep 2007 13:34:25 -0400 Gary Palmer wrote: > > fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory > > fsck: exec fsck_nullfs for /s/usr/ports/distfiles in /sbin:/usr/sbin: No such file or directory > Are you really sure that you want to try and fsck a nullfs mount? Surely I'm sure I don't want. ;-) > the pass field in the fstab should be '0'? Yes, thanks for the pointer. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 19:24:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D4416A417 for ; Sat, 15 Sep 2007 19:24:03 +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 DD65F13C48A for ; Sat, 15 Sep 2007 19:24:02 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 15 Sep 2007 18:57:21 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO [192.168.0.101]) [81.217.94.222] by mail.gmx.net (mp035) with SMTP; 15 Sep 2007 20:57:21 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1/sjj195BbswvszJt9IwqfRXKOmHTkhJnTUvgNhQb Ku5wJhDA2WCrdK From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sat, 15 Sep 2007 20:57:18 +0200 User-Agent: KMail/1.9.7 References: <46EC0F32.7020104@cran.org.uk> In-Reply-To: <46EC0F32.7020104@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709152057.19019.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Bruce Cran Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 19:24:03 -0000 On Saturday 15 September 2007 18:58:26 Bruce Cran wrote: > I have a Dell USB keyboard that I'm using with my Athlon XP desktop > machine. It works fine on -CURRENT with the exception that the > indicator lights don't work as expected. At bootup only the num lock > indicator is on, as expected; however, if I press the num lock key the > other two indicators come on, and further presses of either num lock or > caps lock change the state the keyboard's in but the indicator lights > remain lit all the time. Pressing scroll lock toggles all 3 indicator > lights on/off. Has anyone else seen this problem? I have similar issues here. In X, the indicators don't change at all, in the console behaviour isn't quite right either. But it never bothered me enough to actually report it. uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ukbd0: on uhub2 kbd2 at ukbd0 From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 20:06:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB74E16A417 for ; Sat, 15 Sep 2007 20:06:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 39FD013C45E for ; Sat, 15 Sep 2007 20:06:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 4779 invoked by uid 399); 15 Sep 2007 20:06:05 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 15 Sep 2007 20:06:05 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 15 Sep 2007 13:06:03 -0700 (PDT) From: Doug Barton To: Justin Smith In-Reply-To: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> Message-ID: References: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Lawsuit over ZFS - any impact for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 20:06:06 -0000 On Thu, 6 Sep 2007, Justin Smith wrote: > FYI: > > Network Appliance suing Sun over ZFS > > http://blogs.netapp.com/dave/2007/09/netapp-sues-sun.html Please note, I am not a lawyer, and if your business depends on ZFS you should contact a competent attorney if you have legal concerns. Both sides are suing each other, and the _likely_ outcome will be that they come to some sort of agreement, which will probably involve licensing, and some money changing hands. The URL below has a pretty good analysis of both the current, and the ongoing legal issues around ZFS and WAFL. hth, Doug http://www.eweek.com/article2/0,1759,2179693,00.asp -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 21:52:06 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEBEC16A418 for ; Sat, 15 Sep 2007 21:52:06 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0A713C45B for ; Sat, 15 Sep 2007 21:52:06 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l8FLq1i2075897; Sat, 15 Sep 2007 16:52:02 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sat, 15 Sep 2007 16:52:01 -0500 (CDT) From: "Sean C. Farley" To: "YAMAMOTO, Taku" In-Reply-To: <20070910081425.3c45bca7.taku@tackymt.homeip.net> Message-ID: References: <20070910081425.3c45bca7.taku@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: freebsd-current@FreeBSD.org Subject: Re: setenv() doesn't export unsetenv()ed variables to environ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 21:52:07 -0000 On Mon, 10 Sep 2007, YAMAMOTO, Taku wrote: > Greetings, > > I found a regression in src/lib/libc/stdlib/getenv.c during tracking > strange behaviour of the sshguard-pf. > > In short, setenv() doesn't add an entry to environ[] if the name was > once removed by unsetenv(). > > I'm suspecting the function __setenv() lacks care of the case to reuse > a deactivated entry and it needs the following change: I just committed the patch. Thank you. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 21:59:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86F4D16A46C for ; Sat, 15 Sep 2007 21:59:42 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2F113C4DB for ; Sat, 15 Sep 2007 21:59:42 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 17347 invoked from network); 15 Sep 2007 21:59:41 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Sep 2007 21:59:41 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8FLxfwu008170 for ; Sat, 15 Sep 2007 14:59:41 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8FLxfha008167; Sat, 15 Sep 2007 14:59:41 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 14:59:41 -0700 (PDT) Message-Id: <200709152159.l8FLxfha008167@dv6000.tddhome> From: "Thomas D. Dean" To: freebsd-current@freebsd.org Subject: Compiler 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: Sat, 15 Sep 2007 21:59:42 -0000 I believe we may have a compiler problem with gcc42, and, possiblly 4.1. I point out gcc42 because of the below problem which is a seemingly disconnect with an application and xorg. I have some problems with -current that may also be a disconnect between an application and xorg. I had a problem with scilab under both -stable and -current. I installed the port with the default make files. I saw no errors during build/install. Scilab failed at run time. ports/116378 and earlier kern/116166 which was changed to ports. Math/scilab uses math/lapack and math/blas and builds everything with gcc42 and gfortran42. I distrust things which do not use the default system build tools. All three ports were up-to-date as of yesterday. Running -stable, # uname -a FreeBSD dv6000.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #2: \ Sat Sep 15 11:31:41 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP i386 I deinstalled scilab, blas, and, lapack. I rebuilt them with the default system compilers, g77 and cc. The problem went away. Scilab uses two gfortran specific calls in routines/os_specific/getarg.c. Fixing these and changing the makefiles fixed the problem. Scilab. Changed Makefile to use g77, cc, c++ USE_FORTRAN= g77 CC=cc CXX=c++ F77=f77 build lapack with g77 USE_FORTRAN=g77 build blas with g77 USE_FORTRAN=g77 Removed gfortran from /scratch/obj/ports/usr/ports/math/scilab/work/scilab-4.1.1/routines/os_specific/getarg.c By using the default call in the #if..else statement. tomdean From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 22:04:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 863F716A420 for ; Sat, 15 Sep 2007 22:04:41 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3A013C45D for ; Sat, 15 Sep 2007 22:04:41 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so932216wxd for ; Sat, 15 Sep 2007 15:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=rp/7rf23ZlM9VO8QBoNYTAlZoDNrrRlUp4aop2IiZos=; b=eyO0sATh2zPpTOtcsiF6lNZqJ7wndOvcQm/gXN+nKRk3XG5m+D/nEhJQ5TS63Mo62rDcuakIJSd8IoB41XHgZvD+eaO5rLHgmmXwKuQ3+LJkhUqAaH7LU82YY3lkMhcWL3IkCfMCQmFQdEeBtSti5AtD74YT8G0qyCZmfszIYgk= 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=rI+ASl1erTEw/F1Gnaohv1bvqtICYbkQ+3qbQNrsO0e195HoprvSyOeaeL9Xiaf/+dbPltJkL8Z4nVOXCQCAkx3yHHg+syHaTxyInApxeKYI7KMrqcJiWvmFpvxbc4Iz6RA17CXzbq3Ka56arbQuMDO42vauxvxXO24GPVz0W+E= Received: by 10.90.30.13 with SMTP id d13mr1389639agd.1189892335335; Sat, 15 Sep 2007 14:38:55 -0700 (PDT) Received: by 10.90.78.14 with HTTP; Sat, 15 Sep 2007 14:38:55 -0700 (PDT) Message-ID: Date: Sat, 15 Sep 2007 17:38:55 -0400 From: "Constantine A. Murenin" To: "Doug Barton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <965aa1910709060001k3e0fc1b9sf15867302496b388@mail.gmail.com> Cc: freebsd-current@freebsd.org, Justin Smith Subject: Re: Lawsuit over ZFS - any impact for FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 22:04:41 -0000 On 15/09/2007, Doug Barton wrote: > On Thu, 6 Sep 2007, Justin Smith wrote: > > > FYI: > > > > Network Appliance suing Sun over ZFS > > > > http://blogs.netapp.com/dave/2007/09/netapp-sues-sun.html > > Please note, I am not a lawyer, and if your business depends on ZFS you > should contact a competent attorney if you have legal concerns. > > Both sides are suing each other, and the _likely_ outcome will be that > they come to some sort of agreement, which will probably involve > licensing, and some money changing hands. Yes, cross-licensing is what this is likely all about. Richard Stallman's "The Dangers of Software Patents" speech comes to mind: http://video.google.com/videoplay?docid=6390784544771380326&q=cuug C. From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 22:24:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 199F916A419 for ; Sat, 15 Sep 2007 22:24:52 +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 C69AC13C45B for ; Sat, 15 Sep 2007 22:24:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l8FMOM9H004519; Sat, 15 Sep 2007 15:24:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l8FMOMp3004518; Sat, 15 Sep 2007 15:24:22 -0700 (PDT) (envelope-from sgk) Date: Sat, 15 Sep 2007 15:24:22 -0700 From: Steve Kargl To: "Thomas D. Dean" Message-ID: <20070915222422.GA4487@troutmask.apl.washington.edu> References: <200709152159.l8FLxfha008167@dv6000.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709152159.l8FLxfha008167@dv6000.tddhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Compiler 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: Sat, 15 Sep 2007 22:24:52 -0000 On Sat, Sep 15, 2007 at 02:59:41PM -0700, Thomas D. Dean wrote: > > Math/scilab uses math/lapack and math/blas and builds everything with > gcc42 and gfortran42. I distrust things which do not use the default > system build tools. You did not actually show any information that shows gfortran is a problem. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 22:55:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48EF016A41B for ; Sat, 15 Sep 2007 22:55:23 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 10BF513C45E for ; Sat, 15 Sep 2007 22:55:23 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 11498 invoked from network); 15 Sep 2007 22:55:22 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Sep 2007 22:55:22 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8FMtMmI008384; Sat, 15 Sep 2007 15:55:22 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8FMtMSD008381; Sat, 15 Sep 2007 15:55:22 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 15:55:22 -0700 (PDT) Message-Id: <200709152255.l8FMtMSD008381@dv6000.tddhome> From: "Thomas D. Dean" To: sgk@troutmask.apl.washington.edu In-reply-to: <20070915222422.GA4487@troutmask.apl.washington.edu> (message from Steve Kargl on Sat, 15 Sep 2007 15:24:22 -0700) References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Compiler 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: Sat, 15 Sep 2007 22:55:23 -0000 Please read the entire message. Same OS, same hardware, same port source code. port == math/scilab w/ math/lapack and math/blas I build the port with gfortran42 and it failed at run time. I build the port with g77 - GNU Fortran (GCC) 3.4.6 and it works. tomdean From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 23:15:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0922E16A420 for ; Sat, 15 Sep 2007 23:15: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 B202E13C46B for ; Sat, 15 Sep 2007 23:15:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l8FNFQZW004809; Sat, 15 Sep 2007 16:15:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l8FNFQxD004808; Sat, 15 Sep 2007 16:15:26 -0700 (PDT) (envelope-from sgk) Date: Sat, 15 Sep 2007 16:15:26 -0700 From: Steve Kargl To: "Thomas D. Dean" Message-ID: <20070915231526.GA4788@troutmask.apl.washington.edu> References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709152255.l8FMtMSD008381@dv6000.tddhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Compiler 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: Sat, 15 Sep 2007 23:15:57 -0000 On Sat, Sep 15, 2007 at 03:55:22PM -0700, Thomas D. Dean wrote: > Please read the entire message. > > Same OS, same hardware, same port source code. > > port == math/scilab w/ math/lapack and math/blas > > I build the port with gfortran42 and it failed at run time. > How does it fail? Use gdb. What compiler options? I just build scilab and it works as expected. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 23:28:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA47C16A420 for ; Sat, 15 Sep 2007 23:28:07 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9624E13C457 for ; Sat, 15 Sep 2007 23:28:07 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with SMTP id <0JOF00G8EN5TZ230@smtp5.clear.net.nz> for freebsd-current@freebsd.org; Sun, 16 Sep 2007 11:13:05 +1200 (NZST) Date: Sun, 16 Sep 2007 11:13:05 +1200 From: Sam Banks Sender: w0lfie@clear.net.nz To: freebsd-current@freebsd.org Message-id: <46ec6701.2e5.579b.9680@clear.net.nz> X-Mailer: CLEAR Net WebMail; webmail.clear.net.nz; user: w0lfie; ip: 121.73.22.121 Priority: normal Cc: Bruce Cran , Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: w0lfie@clear.net.nz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 23:28:07 -0000 >From the output you've both pasted, it appears that each of these keyboards have a built in two port hub. Is this correct? I have a hub built into my keyboard and also experience the same issues with the exception of no LEDs ever lighting up. If this is the case, it would appear that FreeBSD has issues dealing with changing the LEDs on keyboards that contain hubs. I will have a look into it but can't guarantee anything :) Sam. ----- Original Message Follows ----- > On Saturday 15 September 2007 18:58:26 Bruce Cran wrote: > > I have a Dell USB keyboard that I'm using with my Athlon > > XP desktop machine. It works fine on -CURRENT with the > > exception that the indicator lights don't work as > > expected. At bootup only the num lock indicator is on, > > as expected; however, if I press the num lock key the > other two indicators come on, and further presses of > > either num lock or caps lock change the state the > > keyboard's in but the indicator lights remain lit all > > the time. Pressing scroll lock toggles all 3 indicator > lights on/off. Has anyone else seen this problem? > > I have similar issues here. In X, the indicators don't > change at all, in the console behaviour isn't quite right > either. > > But it never bothered me enough to actually report it. > > uhub2: addr 1> on usb2 uhub2: 2 ports with 2 removable, self > powered ukbd0: 2.00/0.26, addr 2> on uhub2 kbd2 at ukbd0 > _______________________________________________ > 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 Sat Sep 15 23:39:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A3C516A418 for ; Sat, 15 Sep 2007 23:39:37 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 608C313C458 for ; Sat, 15 Sep 2007 23:39:37 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 26272 invoked from network); 15 Sep 2007 23:39:32 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Sep 2007 23:39:31 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8FNdVjf008561; Sat, 15 Sep 2007 16:39:31 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8FNdVK1008558; Sat, 15 Sep 2007 16:39:31 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 16:39:31 -0700 (PDT) Message-Id: <200709152339.l8FNdVK1008558@dv6000.tddhome> From: "Thomas D. Dean" To: sgk@troutmask.apl.washington.edu In-reply-to: <20070915231526.GA4788@troutmask.apl.washington.edu> (message from Steve Kargl on Sat, 15 Sep 2007 16:15:26 -0700) References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Compiler 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: Sat, 15 Sep 2007 23:39:37 -0000 > How does it fail? Use gdb. What compiler options? When I speak of the scilab port, I mean scilab and the depends, lapack and blas. There are two cases. 1. the port as cvsup'd. 2. the port modified to use cc and f77 of 6.2-stable. In the fail mode, scilab does not return to gdb. I used the default scilab/lapack/blas compiler options. The only change I made was to switch compilers. Case 1: On -stable, 'scilab -debug', built with with the port as cvsup'd, hangs using 90% of one cpu. 'scilab -debug' starts scilab in gdb. The scilab display is frozen. If I drag a window across the scilab window, it does not refresh. I let it run for 10 minutes. It never returns to the gdb prompt. On the console, I saw # scilab (menubar -> demos -> signal processing -> bode plots) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Case 2: On -stable, scilab, built with cc 3.4.6 and f77 3.4.6, the same sequence of actions produces the bad window messages, but, does not hang. Scilab produces the plots, responds to prompts, etc. Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 23:42:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B6016A419 for ; Sat, 15 Sep 2007 23:42:36 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 764F413C45A for ; Sat, 15 Sep 2007 23:42:36 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id CCA0630122; Sun, 16 Sep 2007 00:42:34 +0100 (BST) Message-ID: <46EC6D6C.6020500@cran.org.uk> Date: Sun, 16 Sep 2007 00:40:28 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: w0lfie@clear.net.nz References: <46ec6701.2e5.579b.9680@clear.net.nz> In-Reply-To: <46ec6701.2e5.579b.9680@clear.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 23:42:36 -0000 Sam Banks wrote: > From the output you've both pasted, it appears that each of > these keyboards have a built in two port hub. Is this > correct? > > I have a hub built into my keyboard and also experience the > same issues with the exception of no LEDs ever lighting up. > > If this is the case, it would appear that FreeBSD has issues > dealing with changing the LEDs on keyboards that contain > hubs. I will have a look into it but can't guarantee > anything :) > My keyboard doesn't have any USB ports - the hub in the dmesg is the one on my PC. The Dell keyboard I've got is http://accessories.euro.dell.com/sna/productdetail.aspx?c=uk&l=en&s=dhs&cs=ukdhs1&sku=580-12641 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 23:58:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58DC116A417 for ; Sat, 15 Sep 2007 23:58:22 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id BDB5713C46C for ; Sat, 15 Sep 2007 23:58:21 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from akima.flintsbach.schmalzbauer.de (akima.flintsbach.schmalzbauer.de [172.21.1.35]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8FNwJ6X025660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Sep 2007 01:58:19 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 16 Sep 2007 01:58:14 +0200 User-Agent: KMail/1.9.7 References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> In-Reply-To: <46EBEA18.3080800@ongs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709160158.15519.h.schmalzbauer@omnisec.de> Cc: Daichi GOTO Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Sep 2007 23:58:22 -0000 Am Samstag, 15. September 2007 16:20:08 schrieb Daichi GOTO: > Robert Watson wrote: > > On Fri, 14 Sep 2007, Harald Schmalzbauer wrote: > >> the first thing I have to do after a csup is to apply the unionfs > >> patchset-19-20070504. Is there any chance to get it commited before > >> RELENG_7? It fixes at least one nasty bug for me and I haven't had any > >> problems with unionfs so far (although constantly, but not heavily > >> used). > > > > RE has handed this off to Jeff Roberson for some review, and I think I > > saw that last week he sent out some questions to Goto-san. As I saw > > Goto-san at the front of the room in the first session at EuroBSDCon > > this morning, he may be delayed in responding a bit longer. :-) > > I have sent a answer mail to jeff already, now waiting for > his response :) perhaps he is busy. > > I have a big hope to get merged into FreeBSD until > 7-RELEASE. Progress is step by step slowly, but going > forward absolutely. If you have interest in unionfs > improvements, push your passion to re@ and fs@ committers ;-) First I think I should thank the active developers :) Thank you! I'd love to see it in RELENG_7 but if it can't be accomplished I'm still glad that there's this nice patch. It's all I need and I don't have the skills to help out, so I'll better keep calm... Kind regards, -Harry From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 23:59:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B998B16A46E for ; Sat, 15 Sep 2007 23:59:20 +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 6FEA613C468 for ; Sat, 15 Sep 2007 23:59:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l8FNwqWx005121; Sat, 15 Sep 2007 16:58:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l8FNwqB5005120; Sat, 15 Sep 2007 16:58:52 -0700 (PDT) (envelope-from sgk) Date: Sat, 15 Sep 2007 16:58:52 -0700 From: Steve Kargl To: "Thomas D. Dean" Message-ID: <20070915235852.GB4998@troutmask.apl.washington.edu> References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709152339.l8FNdVK1008558@dv6000.tddhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Compiler 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: Sat, 15 Sep 2007 23:59:20 -0000 On Sat, Sep 15, 2007 at 04:39:31PM -0700, Thomas D. Dean wrote: > > How does it fail? Use gdb. What compiler options? > > On -stable, 'scilab -debug', built with with the port as cvsup'd, > hangs using 90% of one cpu. 'scilab -debug' starts scilab in gdb. The > scilab display is frozen. If I drag a window across the scilab > window, it does not refresh. I let it run for 10 minutes. It never > returns to the gdb prompt. On the console, I saw Are you by any chance using tcsh and is tcsh version 6.15.0? Did you build scilab with pvm support? > Scilab : X error trapped - error message follows: > BadWindow (invalid Window parameter) > Scilab : X error trapped - error message follows: > BadWindow (invalid Window parameter) > Scilab : X error trapped - error message follows: > BadWindow (invalid Window parameter) I don't see any of this. :-/ -- Steve