From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 00:14:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAFEC16A412; Sun, 12 Nov 2006 00:14:04 +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 102D943D64; Sun, 12 Nov 2006 00:13:46 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAC0DkDa050984; Sat, 11 Nov 2006 19:13:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC0Dkjw070519; Sat, 11 Nov 2006 19:13:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CAAC673068; Sat, 11 Nov 2006 19:13:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112001345.CAAC673068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 19:13:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 00:14:04 -0000 TB --- 2006-11-11 22:59:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-11 22:59:50 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-11-11 22:59:50 - cleaning the object tree TB --- 2006-11-11 23:00:18 - checking out the source tree TB --- 2006-11-11 23:00:18 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-11-11 23:00:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-11 23:10:21 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-11 23:10:21 - cd /src TB --- 2006-11-11 23:10:21 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 11 23:10:22 UTC 2006 >>> 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 Nov 12 00:06:46 UTC 2006 TB --- 2006-11-12 00:06:46 - generating LINT kernel config TB --- 2006-11-12 00:06:46 - cd /src/sys/sparc64/conf TB --- 2006-11-12 00:06:46 - /usr/bin/make -B LINT TB --- 2006-11-12 00:06:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 00:06:46 - cd /src TB --- 2006-11-12 00:06:46 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 00:06:46 UTC 2006 >>> 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 [...] /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: At top level: /src/sys/sys/sched.h:166: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:167: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:171: warning: "struct ksegrp" declared inside parameter list *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 00:13:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 00:13:45 - ERROR: failed to build lint kernel TB --- 2006-11-12 00:13:45 - tinderbox aborted TB --- 0.52 user 1.95 system 4435.20 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 00:56:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD47616A403; Sun, 12 Nov 2006 00:56:15 +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 72D1343D58; Sun, 12 Nov 2006 00:56:15 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC0uD9V084277; Sat, 11 Nov 2006 19:56:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC0uBBE075249; Sat, 11 Nov 2006 19:56:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 13AD973068; Sat, 11 Nov 2006 19:56:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112005611.13AD973068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 19:56:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 00:56:16 -0000 TB --- 2006-11-11 23:51:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-11 23:51:05 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-11-11 23:51:05 - cleaning the object tree TB --- 2006-11-11 23:51:31 - checking out the source tree TB --- 2006-11-11 23:51:31 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-11-11 23:51:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 00:01:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 00:01:53 - cd /src TB --- 2006-11-12 00:01:53 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 00:01:54 UTC 2006 >>> 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 Nov 12 00:50:01 UTC 2006 TB --- 2006-11-12 00:50:01 - generating LINT kernel config TB --- 2006-11-12 00:50:01 - cd /src/sys/sun4v/conf TB --- 2006-11-12 00:50:01 - /usr/bin/make -B LINT TB --- 2006-11-12 00:50:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 00:50:01 - cd /src TB --- 2006-11-12 00:50:01 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 00:50:02 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/posix4_mib.c In file included from /src/sys/sys/posix4.h:40, from /src/sys/kern/posix4_mib.c:42: /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 00:56:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 00:56:10 - ERROR: failed to build lint kernel TB --- 2006-11-12 00:56:10 - tinderbox aborted TB --- 0.54 user 1.85 system 3905.10 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 01:29:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F50816A403; Sun, 12 Nov 2006 01:29:28 +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 3047043D53; Sun, 12 Nov 2006 01:29:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC1TRtn087391; Sat, 11 Nov 2006 20:29:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC1TRoI065805; Sat, 11 Nov 2006 20:29:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5335373068; Sat, 11 Nov 2006 20:29:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112012927.5335373068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 20:29:27 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 01:29:28 -0000 TB --- 2006-11-12 01:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 01:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 01:00:00 - cleaning the object tree TB --- 2006-11-12 01:00:20 - checking out the source tree TB --- 2006-11-12 01:00:20 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 01:00:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 01:11:44 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 01:11:44 - cd /src TB --- 2006-11-12 01:11:44 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 01:11:45 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 01:29:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 01:29:27 - ERROR: failed to build world TB --- 2006-11-12 01:29:27 - tinderbox aborted TB --- 0.21 user 0.61 system 1766.83 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 02:39:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9A1816A407; Sun, 12 Nov 2006 02:39:57 +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 6DAEE43D64; Sun, 12 Nov 2006 02:39:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC2duKd093714; Sat, 11 Nov 2006 21:39:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC2dul6093441; Sat, 11 Nov 2006 21:39:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5C51973068; Sat, 11 Nov 2006 21:39:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112023956.5C51973068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 21:39:56 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 02:39:58 -0000 TB --- 2006-11-12 01:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 01:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-11-12 01:00:00 - cleaning the object tree TB --- 2006-11-12 01:00:37 - checking out the source tree TB --- 2006-11-12 01:00:37 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-11-12 01:00:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 01:11:44 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 01:11:44 - cd /src TB --- 2006-11-12 01:11:44 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 01:11:45 UTC 2006 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Nov 12 02:31:18 UTC 2006 TB --- 2006-11-12 02:31:18 - generating LINT kernel config TB --- 2006-11-12 02:31:18 - cd /src/sys/amd64/conf TB --- 2006-11-12 02:31:18 - /usr/bin/make -B LINT TB --- 2006-11-12 02:31:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 02:31:19 - cd /src TB --- 2006-11-12 02:31:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 02:31:19 UTC 2006 >>> 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 [...] /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: At top level: /src/sys/sys/sched.h:166: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:167: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:171: warning: "struct ksegrp" declared inside parameter list *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 02:39:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 02:39:56 - ERROR: failed to build lint kernel TB --- 2006-11-12 02:39:56 - tinderbox aborted TB --- 0.69 user 2.42 system 5995.83 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 02:43:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B19B416A407; Sun, 12 Nov 2006 02:43:05 +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 E6D5E43D5D; Sun, 12 Nov 2006 02:43:04 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC2h4ME093952; Sat, 11 Nov 2006 21:43:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC2h4KE065919; Sat, 11 Nov 2006 21:43:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0FDC773068; Sat, 11 Nov 2006 21:43:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112024304.0FDC773068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 21:43:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 02:43:05 -0000 TB --- 2006-11-12 01:29:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 01:29:27 - starting HEAD tinderbox run for i386/i386 TB --- 2006-11-12 01:29:27 - cleaning the object tree TB --- 2006-11-12 01:29:58 - checking out the source tree TB --- 2006-11-12 01:29:58 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-11-12 01:29:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 01:40:15 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 01:40:15 - cd /src TB --- 2006-11-12 01:40:15 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 01:40:17 UTC 2006 >>> 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 Nov 12 02:34:29 UTC 2006 TB --- 2006-11-12 02:34:29 - generating LINT kernel config TB --- 2006-11-12 02:34:29 - cd /src/sys/i386/conf TB --- 2006-11-12 02:34:29 - /usr/bin/make -B LINT TB --- 2006-11-12 02:34:30 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 02:34:30 - cd /src TB --- 2006-11-12 02:34:30 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 02:34:30 UTC 2006 >>> 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 [...] /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: At top level: /src/sys/sys/sched.h:166: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:167: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:171: warning: "struct ksegrp" declared inside parameter list *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 02:43:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 02:43:03 - ERROR: failed to build lint kernel TB --- 2006-11-12 02:43:03 - tinderbox aborted TB --- 0.57 user 1.76 system 4416.52 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 03:50:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A45616A407; Sun, 12 Nov 2006 03:50:48 +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 9048643D45; Sun, 12 Nov 2006 03:50:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC3okN3099680; Sat, 11 Nov 2006 22:50:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC3oke3051847; Sat, 11 Nov 2006 22:50:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 37FDE73068; Sat, 11 Nov 2006 22:50:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112035046.37FDE73068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 22:50:46 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 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, 12 Nov 2006 03:50:48 -0000 TB --- 2006-11-12 02:39:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 02:39:56 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-11-12 02:39:56 - cleaning the object tree TB --- 2006-11-12 02:40:14 - checking out the source tree TB --- 2006-11-12 02:40:14 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-11-12 02:40:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 02:50:47 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 02:50:47 - cd /src TB --- 2006-11-12 02:50:47 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 02:50:49 UTC 2006 >>> 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 Nov 12 03:43:15 UTC 2006 TB --- 2006-11-12 03:43:15 - generating LINT kernel config TB --- 2006-11-12 03:43:15 - cd /src/sys/pc98/conf TB --- 2006-11-12 03:43:15 - /usr/bin/make -B LINT TB --- 2006-11-12 03:43:16 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 03:43:16 - cd /src TB --- 2006-11-12 03:43:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 03:43:16 UTC 2006 >>> 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 [...] /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: At top level: /src/sys/sys/sched.h:166: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:167: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:171: warning: "struct ksegrp" declared inside parameter list *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 03:50:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 03:50:46 - ERROR: failed to build lint kernel TB --- 2006-11-12 03:50:46 - tinderbox aborted TB --- 0.62 user 1.54 system 4249.38 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 04:16:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 978D516A417 for ; Sun, 12 Nov 2006 04:16:08 +0000 (UTC) (envelope-from chinohillsbanditos@yahoo.com) Received: from web34001.mail.mud.yahoo.com (web34001.mail.mud.yahoo.com [66.163.178.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 02EFF43D58 for ; Sun, 12 Nov 2006 04:16:07 +0000 (GMT) (envelope-from chinohillsbanditos@yahoo.com) Received: (qmail 25592 invoked by uid 60001); 12 Nov 2006 04:16:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=bIe0g790BZugdO/mbNHbQn7m9ipilJht63kPtPziTf8vWKZ1rJiTsOZiY6VcmFIIt0BMZWcXr5DIE3M0CtR8DaTIJrDgD+xaA6mvD78M3yWTShTJyxKHZc9jCIceENONR/K0HfYZ3faYwo88GIcsXiAAW2OyWHJDz42ukEuybjQ= ; Message-ID: <20061112041607.25590.qmail@web34001.mail.mud.yahoo.com> Received: from [71.104.224.139] by web34001.mail.mud.yahoo.com via HTTP; Sat, 11 Nov 2006 20:16:07 PST Date: Sat, 11 Nov 2006 20:16:07 -0800 (PST) From: "Mr. Man" To: Steven Hartland , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Dell 1950 & 2950 with Broadcom NetXtreme II BCM5708 1000Base-T X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 04:16:08 -0000 Hmmm...forgive me if i'm totally-off, but why would it have anything to do = with DNS?=0A=0AThe requests do come out to about 4 per second, (I see them = in the logs, no errors). And if its trying to perform a reverse dns, im as= suming it would only need to do a lookup once (but not even take this long)= , then cache the result so the remaining requests would be fast afterwards,= but I just tried it with hostnamelookups Off in Apache and it didn't make = a difference.=0A=0AI'm not sure if I made it clear, but I am running the Be= nchmark from the -same machine- that Apache & MySQL are running on to rule-= out problems.=0A=0AI am seeing the few requests that actually do come throu= gh in httpd-access.log for Apache, they seem fine and, no errors are presen= t in the error log. I did check the netstat -an right after I sent the req= uests and always see a lot of TIME_WAIT's... Im pretty beginner/intermedia= te right now at FreeBSD right now, so im not too sure of any other debug in= fo I could provide.=0A=0A----- Original Message ----=0AFrom: Steven Hartlan= d =0ATo: Mr. Man ; f= reebsd-current@freebsd.org=0ASent: Tuesday, November 7, 2006 3:06:06 PM=0AS= ubject: Re: Dell 1950 & 2950 with Broadcom NetXtreme II BCM5708 1000Base-T= =0A=0ASounds like a DNS, possibly a reverse DNS on authentication=0Atiming = out?=0A=0AMr. Man wrote:=0A> I am benchmarking with ab (apache bench/mark) = to test the speed of a=0A> php file which calls a simple mysql query. When = I configure the php=0A> file to use the ip 127.0.0.1 to connect to mysql, i= t comes out to=0A> about =0A> 700requests/second. But when I point to its L= AN ip 192.168.0.6, it=0A> comes out to 4 requests per second. Thats FOUR...= The benchmark=0A> actually sits for a few extra seconds longer than it sho= uld as if it=0A> froze.=0A=0A=0A=0A=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=0AThis e.mail is private and confidential be= tween Multiplay (UK) Ltd. and the person or entity to whom it is addressed.= In the event of misdirection, the recipient is prohibited from using, copy= ing, printing or otherwise disseminating it or any information contained in= it. =0A=0AIn the event of misdirection, illegible or incomplete transmissi= on please telephone +44 845 868 1337=0Aor return the E.mail to postmaster@m= ultiplay.co.uk.=0A=0A=0A=0A=0A=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 04:17:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0193E16A40F; Sun, 12 Nov 2006 04:17:34 +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 3752C43D45; Sun, 12 Nov 2006 04:17:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC4HVCh001979; Sat, 11 Nov 2006 23:17:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC4HVYP009949; Sat, 11 Nov 2006 23:17:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AED5B73068; Sat, 11 Nov 2006 23:17:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112041730.AED5B73068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 23:17:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 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, 12 Nov 2006 04:17:34 -0000 TB --- 2006-11-12 02:43:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 02:43:04 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-11-12 02:43:04 - cleaning the object tree TB --- 2006-11-12 02:43:36 - checking out the source tree TB --- 2006-11-12 02:43:36 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-11-12 02:43:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 02:50:47 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 02:50:47 - cd /src TB --- 2006-11-12 02:50:47 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 02:50:49 UTC 2006 >>> 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 Nov 12 04:07:13 UTC 2006 TB --- 2006-11-12 04:07:13 - generating LINT kernel config TB --- 2006-11-12 04:07:13 - cd /src/sys/ia64/conf TB --- 2006-11-12 04:07:13 - /usr/bin/make -B LINT TB --- 2006-11-12 04:07:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 04:07:13 - cd /src TB --- 2006-11-12 04:07:13 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 04:07:13 UTC 2006 >>> 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 [...] /src/sys/sys/sched.h: In function `sched_pin': /src/sys/sys/sched.h:154: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: In function `sched_unpin': /src/sys/sys/sched.h:160: error: dereferencing pointer to incomplete type /src/sys/sys/sched.h: At top level: /src/sys/sys/sched.h:166: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:167: warning: "struct ksegrp" declared inside parameter list /src/sys/sys/sched.h:171: warning: "struct ksegrp" declared inside parameter list *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 04:17:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 04:17:29 - ERROR: failed to build lint kernel TB --- 2006-11-12 04:17:29 - tinderbox aborted TB --- 0.43 user 1.65 system 5665.74 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 04:01:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A981616A407; Sun, 12 Nov 2006 04:01:10 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1460F43D53; Sun, 12 Nov 2006 04:01:09 +0000 (GMT) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (cpe-24-210-75-119.columbus.res.rr.com [24.210.75.119]) (authenticated bits=0) by mail.united-ware.com (8.13.6/8.13.6) with ESMTP id kAC4KmWT087862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 23:20:55 -0500 (EST) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-current@freebsd.org Date: Sat, 11 Nov 2006 23:02:13 -0500 User-Agent: KMail/1.9.4 References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> In-Reply-To: <45560FB8.1040607@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1241153.xUBksLBTLO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611112302.23508.amistry@am-productions.biz> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_50,MYFREEBSD2, MYFREEBSD3,RCVD_IN_NJABL_DUL,SPF_SOFTFAIL autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.5/2187/Sat Nov 11 11:49:23 2006 on mail.united-ware.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 12 Nov 2006 05:06:48 +0000 Cc: Andre Oppermann , current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 04:01:11 -0000 --nextPart1241153.xUBksLBTLO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 November 2006 13:00, Andre Oppermann wrote: > Pawel Worach wrote: > > Andre Oppermann wrote: > >> I'm looking into the problem. Please try a binary FTP transfer > >> as well and check if the checksums match. ftpd uses sendfile(2) > >> as well but w/o headers or trailers and does the send in one > >> swoop. > > > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file > > does not trash it. Meanwhile a couple of other things where > > tested, SMP disabled (removed from kernel config), added some > > printf's which when printing to a serial console moves the offset > > where the breakage begins to 0x01000000, sometimes. > > I tried to reproduce the problem with lighttpd w/o success. > > My guess is that something gets wrong when using non-blocking > sockets and the http headers. Could you obtain the truss of the > sendfile(2) calls so I get the input parameters to it? A visual > inspection of a corruptly transferred text file would be helpful > too. This should give more hints what happens, like duplicated or > missing pages, etc. =46or me I'm seeing 3 different behaviors. 1) The file is just truncated after a few KB. 2) A section of the file is just missing. eg. A small section of the=20 file in the middle is just gone. 3) The data is sent before the headers. eg. a portion of the html is=20 sent, and then you see The following shows 1) and 2). http://am-productions.biz/docs/no-menu-default.css.bad http://am-productions.biz/docs/no-menu-default.css =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart1241153.xUBksLBTLO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFVpzPxqA5ziudZT0RAqHpAJ4xT04UksCE6sRsnFy+1hinBnuZPwCglxsj 9YKUDhJQFSACHz24dK+lInE= =Ao4E -----END PGP SIGNATURE----- --nextPart1241153.xUBksLBTLO-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 04:01:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A981616A407; Sun, 12 Nov 2006 04:01:10 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1460F43D53; Sun, 12 Nov 2006 04:01:09 +0000 (GMT) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (cpe-24-210-75-119.columbus.res.rr.com [24.210.75.119]) (authenticated bits=0) by mail.united-ware.com (8.13.6/8.13.6) with ESMTP id kAC4KmWT087862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 23:20:55 -0500 (EST) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-current@freebsd.org Date: Sat, 11 Nov 2006 23:02:13 -0500 User-Agent: KMail/1.9.4 References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> In-Reply-To: <45560FB8.1040607@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1241153.xUBksLBTLO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611112302.23508.amistry@am-productions.biz> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_50,MYFREEBSD2, MYFREEBSD3,RCVD_IN_NJABL_DUL,SPF_SOFTFAIL autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88.5/2187/Sat Nov 11 11:49:23 2006 on mail.united-ware.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 12 Nov 2006 05:07:00 +0000 Cc: Andre Oppermann , current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 04:01:11 -0000 --nextPart1241153.xUBksLBTLO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 November 2006 13:00, Andre Oppermann wrote: > Pawel Worach wrote: > > Andre Oppermann wrote: > >> I'm looking into the problem. Please try a binary FTP transfer > >> as well and check if the checksums match. ftpd uses sendfile(2) > >> as well but w/o headers or trailers and does the send in one > >> swoop. > > > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file > > does not trash it. Meanwhile a couple of other things where > > tested, SMP disabled (removed from kernel config), added some > > printf's which when printing to a serial console moves the offset > > where the breakage begins to 0x01000000, sometimes. > > I tried to reproduce the problem with lighttpd w/o success. > > My guess is that something gets wrong when using non-blocking > sockets and the http headers. Could you obtain the truss of the > sendfile(2) calls so I get the input parameters to it? A visual > inspection of a corruptly transferred text file would be helpful > too. This should give more hints what happens, like duplicated or > missing pages, etc. =46or me I'm seeing 3 different behaviors. 1) The file is just truncated after a few KB. 2) A section of the file is just missing. eg. A small section of the=20 file in the middle is just gone. 3) The data is sent before the headers. eg. a portion of the html is=20 sent, and then you see The following shows 1) and 2). http://am-productions.biz/docs/no-menu-default.css.bad http://am-productions.biz/docs/no-menu-default.css =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart1241153.xUBksLBTLO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFVpzPxqA5ziudZT0RAqHpAJ4xT04UksCE6sRsnFy+1hinBnuZPwCglxsj 9YKUDhJQFSACHz24dK+lInE= =Ao4E -----END PGP SIGNATURE----- --nextPart1241153.xUBksLBTLO-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 05:07:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A08A16A615; Sun, 12 Nov 2006 05:07:06 +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 CC1A943D53; Sun, 12 Nov 2006 05:07:05 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAC575Ji068058; Sun, 12 Nov 2006 00:07:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC574u4006208; Sun, 12 Nov 2006 00:07:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6655773068; Sun, 12 Nov 2006 00:07:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112050704.6655773068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 00:07:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 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, 12 Nov 2006 05:07:06 -0000 TB --- 2006-11-12 03:50:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 03:50:46 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2006-11-12 03:50:46 - cleaning the object tree TB --- 2006-11-12 03:51:08 - checking out the source tree TB --- 2006-11-12 03:51:08 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2006-11-12 03:51:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 04:00:22 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 04:00:22 - cd /src TB --- 2006-11-12 04:00:22 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 04:00:24 UTC 2006 >>> 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 Nov 12 05:00:39 UTC 2006 TB --- 2006-11-12 05:00:39 - generating LINT kernel config TB --- 2006-11-12 05:00:39 - cd /src/sys/powerpc/conf TB --- 2006-11-12 05:00:39 - /usr/bin/make -B LINT TB --- 2006-11-12 05:00:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 05:00:39 - cd /src TB --- 2006-11-12 05:00:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 05:00:39 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/subr_kobj.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/subr_lock.c /src/sys/kern/subr_lock.c: In function `dump_lock_prof_stats': /src/sys/kern/subr_lock.c:150: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_update_wait': /src/sys/kern/subr_lock.c:309: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_release_lock': /src/sys/kern/subr_lock.c:371: error: structure has no member named `type' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 05:07:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 05:07:04 - ERROR: failed to build lint kernel TB --- 2006-11-12 05:07:04 - tinderbox aborted TB --- 0.49 user 1.88 system 4577.80 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 05:32:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15DD16A403; Sun, 12 Nov 2006 05:32:29 +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 6E6C143D45; Sun, 12 Nov 2006 05:32:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC5WS0a007169; Sun, 12 Nov 2006 00:32:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC5WSgS024735; Sun, 12 Nov 2006 00:32:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9473973068; Sun, 12 Nov 2006 00:32:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112053228.9473973068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 00:32:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 05:32:29 -0000 TB --- 2006-11-12 04:17:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 04:17:31 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-11-12 04:17:31 - cleaning the object tree TB --- 2006-11-12 04:18:00 - checking out the source tree TB --- 2006-11-12 04:18:00 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-11-12 04:18:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 04:28:49 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 04:28:49 - cd /src TB --- 2006-11-12 04:28:49 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 04:28:50 UTC 2006 >>> 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 Nov 12 05:25:29 UTC 2006 TB --- 2006-11-12 05:25:29 - generating LINT kernel config TB --- 2006-11-12 05:25:29 - cd /src/sys/sparc64/conf TB --- 2006-11-12 05:25:29 - /usr/bin/make -B LINT TB --- 2006-11-12 05:25:29 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 05:25:29 - cd /src TB --- 2006-11-12 05:25:29 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 05:25:29 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/subr_kobj.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/subr_lock.c /src/sys/kern/subr_lock.c: In function `dump_lock_prof_stats': /src/sys/kern/subr_lock.c:150: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_update_wait': /src/sys/kern/subr_lock.c:309: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_release_lock': /src/sys/kern/subr_lock.c:371: error: structure has no member named `type' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 05:32:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 05:32:28 - ERROR: failed to build lint kernel TB --- 2006-11-12 05:32:28 - tinderbox aborted TB --- 0.66 user 1.91 system 4496.79 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 05:41:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B999F16A40F for ; Sun, 12 Nov 2006 05:41:54 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CE843D86 for ; Sun, 12 Nov 2006 05:41:49 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (c-24-118-173-219.hsd1.mn.comcast.net[24.118.173.219]) by comcast.net (sccrmhc12) with ESMTP id <2006111205414801200orbt9e>; Sun, 12 Nov 2006 05:41:48 +0000 From: Josh Paetzel To: freebsd-current@freebsd.org Date: Sun, 12 Nov 2006 00:41:38 -0500 User-Agent: KMail/1.9.3 References: <20061112041607.25590.qmail@web34001.mail.mud.yahoo.com> In-Reply-To: <20061112041607.25590.qmail@web34001.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611112341.38581.josh@tcbug.org> Cc: "Mr. Man" Subject: Re: Dell 1950 & 2950 with Broadcom NetXtreme II BCM5708 1000Base-T X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 05:41:54 -0000 On Saturday 11 November 2006 22:16, Mr. Man wrote: > Hmmm...forgive me if i'm totally-off, but why would it have > anything to do with DNS? > > The requests do come out to about 4 per second, (I see them in the > logs, no errors). And if its trying to perform a reverse dns, im > assuming it would only need to do a lookup once (but not even take > this long), then cache the result so the remaining requests would > be fast afterwards, but I just tried it with hostnamelookups Off in > Apache and it didn't make a difference. > > I'm not sure if I made it clear, but I am running the Benchmark > from the -same machine- that Apache & MySQL are running on to > rule-out problems. > > I am seeing the few requests that actually do come through in > httpd-access.log for Apache, they seem fine and, no errors are > present in the error log. I did check the netstat -an right after > I sent the requests and always see a lot of TIME_WAIT's... Im > pretty beginner/intermediate right now at FreeBSD right now, so im > not too sure of any other debug info I could provide. > The bce driver in 6.1-R or earlier is really really buggy in PE 1950/2950 machines. Buggy enough that it's actually unusable. There is a driver that works better in -STABLE although they still haven't ironed all of the issues out of it. -- Thanks, Josh Paetzel From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 06:12:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2603216A40F; Sun, 12 Nov 2006 06:12:47 +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 D335E43D49; Sun, 12 Nov 2006 06:12:46 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC6CkIE009662; Sun, 12 Nov 2006 01:12:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC6CkfX004504; Sun, 12 Nov 2006 01:12:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D453B73068; Sun, 12 Nov 2006 01:12:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112061245.D453B73068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 01:12:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 06:12:47 -0000 TB --- 2006-11-12 05:07:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 05:07:04 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-11-12 05:07:04 - cleaning the object tree TB --- 2006-11-12 05:07:35 - checking out the source tree TB --- 2006-11-12 05:07:35 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-11-12 05:07:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 05:17:29 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 05:17:29 - cd /src TB --- 2006-11-12 05:17:29 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 05:17:31 UTC 2006 >>> 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 Nov 12 06:06:32 UTC 2006 TB --- 2006-11-12 06:06:32 - generating LINT kernel config TB --- 2006-11-12 06:06:32 - cd /src/sys/sun4v/conf TB --- 2006-11-12 06:06:32 - /usr/bin/make -B LINT TB --- 2006-11-12 06:06:32 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-12 06:06:32 - cd /src TB --- 2006-11-12 06:06:32 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 12 06:06:32 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/subr_kobj.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/subr_lock.c /src/sys/kern/subr_lock.c: In function `dump_lock_prof_stats': /src/sys/kern/subr_lock.c:150: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_update_wait': /src/sys/kern/subr_lock.c:309: error: structure has no member named `type' /src/sys/kern/subr_lock.c: In function `_lock_profile_release_lock': /src/sys/kern/subr_lock.c:371: error: structure has no member named `type' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 06:12:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 06:12:45 - ERROR: failed to build lint kernel TB --- 2006-11-12 06:12:45 - tinderbox aborted TB --- 0.56 user 1.80 system 3941.10 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 06:44:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2ED516A583; Sun, 12 Nov 2006 06:44:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5793743D46; Sun, 12 Nov 2006 06:44:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAC6if11073349; Sun, 12 Nov 2006 01:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC6ifAT073432; Sun, 12 Nov 2006 01:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 28C6473068; Sun, 12 Nov 2006 01:44:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112064441.28C6473068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 01:44:40 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 06:44:42 -0000 TB --- 2006-11-12 06:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 06:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 06:15:00 - cleaning the object tree TB --- 2006-11-12 06:15:24 - checking out the source tree TB --- 2006-11-12 06:15:24 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 06:15:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 06:26:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 06:26:53 - cd /src TB --- 2006-11-12 06:26:53 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 06:26:54 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 06:44:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 06:44:40 - ERROR: failed to build world TB --- 2006-11-12 06:44:40 - tinderbox aborted TB --- 0.16 user 0.65 system 1779.74 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 09:59:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D5416A4AB for ; Sun, 12 Nov 2006 09:59:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1927E43D4C for ; Sun, 12 Nov 2006 09:59:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 73488 invoked from network); 12 Nov 2006 09:52:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 09:52:39 -0000 Message-ID: <4556F086.7050201@freebsd.org> Date: Sun, 12 Nov 2006 10:59:34 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Anish Mistry References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> <200611112302.23508.amistry@am-productions.biz> In-Reply-To: <200611112302.23508.amistry@am-productions.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 09:59:36 -0000 Anish Mistry wrote: > On Saturday 11 November 2006 13:00, Andre Oppermann wrote: >> Pawel Worach wrote: >>> Andre Oppermann wrote: >>>> I'm looking into the problem. Please try a binary FTP transfer >>>> as well and check if the checksums match. ftpd uses sendfile(2) >>>> as well but w/o headers or trailers and does the send in one >>>> swoop. >>> Oh, didn't think of that, ftpd is ok, transferring a 64MB file >>> does not trash it. Meanwhile a couple of other things where >>> tested, SMP disabled (removed from kernel config), added some >>> printf's which when printing to a serial console moves the offset >>> where the breakage begins to 0x01000000, sometimes. >> I tried to reproduce the problem with lighttpd w/o success. >> >> My guess is that something gets wrong when using non-blocking >> sockets and the http headers. Could you obtain the truss of the >> sendfile(2) calls so I get the input parameters to it? A visual >> inspection of a corruptly transferred text file would be helpful >> too. This should give more hints what happens, like duplicated or >> missing pages, etc. > For me I'm seeing 3 different behaviors. > 1) The file is just truncated after a few KB. > 2) A section of the file is just missing. eg. A small section of the > file in the middle is just gone. > 3) The data is sent before the headers. eg. a portion of the html is > sent, and then you see What webserver are you running? > The following shows 1) and 2). > http://am-productions.biz/docs/no-menu-default.css.bad > http://am-productions.biz/docs/no-menu-default.css -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 09:59:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABCB116A4B3 for ; Sun, 12 Nov 2006 09:59:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18D8343D46 for ; Sun, 12 Nov 2006 09:59:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 73488 invoked from network); 12 Nov 2006 09:52:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 09:52:39 -0000 Message-ID: <4556F086.7050201@freebsd.org> Date: Sun, 12 Nov 2006 10:59:34 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Anish Mistry References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> <200611112302.23508.amistry@am-productions.biz> In-Reply-To: <200611112302.23508.amistry@am-productions.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 09:59:36 -0000 Anish Mistry wrote: > On Saturday 11 November 2006 13:00, Andre Oppermann wrote: >> Pawel Worach wrote: >>> Andre Oppermann wrote: >>>> I'm looking into the problem. Please try a binary FTP transfer >>>> as well and check if the checksums match. ftpd uses sendfile(2) >>>> as well but w/o headers or trailers and does the send in one >>>> swoop. >>> Oh, didn't think of that, ftpd is ok, transferring a 64MB file >>> does not trash it. Meanwhile a couple of other things where >>> tested, SMP disabled (removed from kernel config), added some >>> printf's which when printing to a serial console moves the offset >>> where the breakage begins to 0x01000000, sometimes. >> I tried to reproduce the problem with lighttpd w/o success. >> >> My guess is that something gets wrong when using non-blocking >> sockets and the http headers. Could you obtain the truss of the >> sendfile(2) calls so I get the input parameters to it? A visual >> inspection of a corruptly transferred text file would be helpful >> too. This should give more hints what happens, like duplicated or >> missing pages, etc. > For me I'm seeing 3 different behaviors. > 1) The file is just truncated after a few KB. > 2) A section of the file is just missing. eg. A small section of the > file in the middle is just gone. > 3) The data is sent before the headers. eg. a portion of the html is > sent, and then you see What webserver are you running? > The following shows 1) and 2). > http://am-productions.biz/docs/no-menu-default.css.bad > http://am-productions.biz/docs/no-menu-default.css -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 10:06:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2AD16A412 for ; Sun, 12 Nov 2006 10:06:31 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCD1E43D69 for ; Sun, 12 Nov 2006 10:06:30 +0000 (GMT) (envelope-from freebsd.ruomad@free.fr) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp2-g19.free.fr (Postfix) with ESMTP id 166237D35 for ; Sun, 12 Nov 2006 11:06:29 +0100 (CET) Message-ID: <4556F224.3050501@free.fr> Date: Sun, 12 Nov 2006 11:06:28 +0100 From: Bruno Damour User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: wpa-psk help with output of ifconfig ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 10:06:31 -0000 Hello, I'm trying to debug some problems using WPA-PSK with ral driver. Connection is often hanging after a while, network down. netstat -r takes a very long time, ping doesnt respond, etc... it works if I reset everything with netif restart. I saw a difference in the output of ifconfig that seems to be connected : working state : ral0: flags=8843 mtu 1500 inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:16:b6:5d:93:f9 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 100 bmiss 7 protmode CTS roaming MANUAL bintval 100 not working : ral0: flags=8843 mtu 1500 inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:16:b6:5d:93:f9 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpowmax 100 bmiss 7 protmode CTS roaming MANUAL bintval 100 The issue seems to be the TKIP 2:128-bit TKIP 3:128-bit (two items) when prevously there was only one... Does anyone know what this output means ? Thanks in advance bruno From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 10:01:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CB516A54D for ; Sun, 12 Nov 2006 10:01:05 +0000 (UTC) (envelope-from roundup@ruomad.net) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 537A543D67 for ; Sun, 12 Nov 2006 10:01:00 +0000 (GMT) (envelope-from roundup@ruomad.net) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp6-g19.free.fr (Postfix) with ESMTP id C690E43890 for ; Sun, 12 Nov 2006 11:00:58 +0100 (CET) Message-ID: <4556F0D8.2030106@ruomad.net> Date: Sun, 12 Nov 2006 11:00:56 +0100 From: Bruno Damour User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Nov 2006 12:38:33 +0000 Subject: wpa-psk help with output of ifconfig ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 10:01:05 -0000 Hello, I'm trying to debug some problems using WPA-PSK with ral driver. Connection is often hanging after a while, network down. netstat -r takes a very long time, ping doesnt respond, etc... it works if I reset everything with netif restart. I saw a difference in the output of ifconfig that seems to be connected : working state : ral0: flags=8843 mtu 1500 inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:16:b6:5d:93:f9 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 100 bmiss 7 protmode CTS roaming MANUAL bintval 100 not working : ral0: flags=8843 mtu 1500 inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:16:b6:5d:93:f9 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpowmax 100 bmiss 7 protmode CTS roaming MANUAL bintval 100 The issue seems to be the TKIP 2:128-bit TKIP 3:128-bit (two items) when prevously there was only one... Does anyone know what this output means ? Thanks in advance bruno From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 12:43:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3214A16A403 for ; Sun, 12 Nov 2006 12:43:15 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 754CA43D4C for ; Sun, 12 Nov 2006 12:43:14 +0000 (GMT) (envelope-from freebsd.ruomad@free.fr) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp3-g19.free.fr (Postfix) with ESMTP id D1A284A105 for ; Sun, 12 Nov 2006 13:43:13 +0100 (CET) Message-ID: <455716E1.1030505@free.fr> Date: Sun, 12 Nov 2006 13:43:13 +0100 From: Bruno Damour User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4556F0D8.2030106@ruomad.net> In-Reply-To: <4556F0D8.2030106@ruomad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: wpa-psk help with output of ifconfig ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 12:43:15 -0000 Sorry for suplicate... wrong manipulation Bruno Bruno Damour wrote: > Hello, From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 13:03:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75A5716A40F for ; Sun, 12 Nov 2006 13:03:41 +0000 (UTC) (envelope-from regnier.olivier@gmail.com) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E54D43D72 for ; Sun, 12 Nov 2006 13:03:40 +0000 (GMT) (envelope-from regnier.olivier@gmail.com) Received: from [127.0.0.1] (mac76-2-82-241-6-173.fbx.proxad.net [82.241.6.173]) by smtp5-g19.free.fr (Postfix) with ESMTP id 60A8527B11 for ; Sun, 12 Nov 2006 14:03:38 +0100 (CET) Message-ID: <45571BD1.2030805@gmail.com> Date: Sun, 12 Nov 2006 14:04:17 +0100 From: =?ISO-8859-1?Q?Olivier_R=E9gnier?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Slimtype DVDRW SOSw-833S/VRS2 ATA/ATAPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: regnier.olivier@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: Sun, 12 Nov 2006 13:03:41 -0000 Hello, I'm running on FreeBSD 6.1-RELEASE-p10 and i would like to listen a music cd, to look a dvd film or to burn a cd data but i can't do that. The material is new. Here some information about it: - Acer Aspire 3002WLMI - Mobile AMD Sempron processor 2800+ - 15.4 WXGA wide TFT LCD - 60GB HDD - DVD-Dual (Support DVD+R Double Layer/DVD+RW) - 512MB DDR - 802.11b/g wireless LAN To use my DVD/CD burner, i compiled my kernel with these parameters: # --------------- # Kernel. # --------------- # Options options CD9660 # ISO 9660 Filesystem # ATA and ATAPI devices device atapicd # ATAPI CDROM drives # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) # ATAPI/CAM device atapicam if you looks the dmesg file, i obtain these lines: acd0: DVDR at ata1-master UDMA33 acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - PREVENT_ALLOW timed out acd0: FAILURE - READ_SUBCHANNEL timed out acd0: FAILURE - PAUSE ILLEGAL REQUEST asc=0xb9 ascq=0x00 Well, after i activated the dma for the dvd/cd burner with this line in my loader.conf: hw.ata.atapi_dma="1" After the new kernel is installed, and the system is rebooted, i modified my devfs.conf file with the good permissions, i think: perm pass0 0666 perm xpt0 0666 perm acd0 0666 perm cd0 0666 link acd0 cdrom link acd0 dvd link acd0 dvdr then, i tested my dvd/cd burner with xmms. I push on the play button, the cdrom engages and after 1 second, more nothing. Second test, i used mplayer to look my dvd film and nothing. I don't know what happened with it. Perhaps FreeBSD doesn't support my Slimtype DVDRW ? But if i use the atacontrol list command, i have this: ATA channel 1: Master: acd0 ATA/ATAPI revision 5 Slave: no device present It is terrible, when you cannot use your material. With Microsoft Windows, I do not have any problem and on the same laptop. Estranged no ? But i want to stay on FreeBSD to find a solution. My situation is delicate. Could you help me about this ? Thank you very much. Olivier Regnier. From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 13:39:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96A0A16A417; Sun, 12 Nov 2006 13:39:51 +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 4ED3B43DD7; Sun, 12 Nov 2006 13:39:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kACDdU8P055959; Sun, 12 Nov 2006 08:39:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kACDdT5l073883; Sun, 12 Nov 2006 08:39:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9194773068; Sun, 12 Nov 2006 08:39:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112133929.9194773068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 08:39:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 13:39:51 -0000 TB --- 2006-11-12 13:10:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 13:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 13:10:01 - cleaning the object tree TB --- 2006-11-12 13:10:23 - checking out the source tree TB --- 2006-11-12 13:10:23 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 13:10:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 13:21:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 13:21:53 - cd /src TB --- 2006-11-12 13:21:53 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 13:21:55 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 13:39:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 13:39:29 - ERROR: failed to build world TB --- 2006-11-12 13:39:29 - tinderbox aborted TB --- 0.23 user 0.60 system 1768.23 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:00:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14B0F16A4A7; Sun, 12 Nov 2006 14:00:46 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE17643DB3; Sun, 12 Nov 2006 14:00:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 967AC5FA5; Sun, 12 Nov 2006 17:00:06 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 731345EFE; Sun, 12 Nov 2006 17:00:06 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACE0A34049664; Sun, 12 Nov 2006 17:00:10 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:00:10 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox Message-ID: <20061112140010.GA47660@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20061112133929.9194773068@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:00:46 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > >>> stage 4.2: building libraries > [...] > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_getident.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_hash.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_kind.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_memory.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_next.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_rand.c > /src/lib/libelf/elf_rand.c: In function `elf_rand': > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment= of target type > *** Error code 1 >=20 > Stop in /src/lib/libelf. > *** Error code 1 >=20 This looks like a GCC bug to me. The following code snippet, when compiled on FreeBSD/arm, causes a -Wcast-align warning which doesn't look right: %%% $ cat a.c struct foo { char x; }; struct foo * bubu(char *s) { return (struct foo *)s; } $ cc -c -Wcast-align a.c a.c: In function `bubu': a.c:9: warning: cast increases required alignment of target type %%% (None of other supported architecutes see the issue here.) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVyjqqRfpzJluFF4RAp0yAKCF6pdQIMBN4yr4m2Q/OgScVCDwVQCgllwq n83kSLL032PE6a1jzm3VgwQ= =iePk -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:27:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190B716A403; Sun, 12 Nov 2006 14:27:25 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep16-int.chello.at (viefep15-int.chello.at [213.46.255.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2AC43D7B; Sun, 12 Nov 2006 14:27:13 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep16-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20061112142711.UUIZ7276.viefep16-int.chello.at@wombat.fafoe.narf.at>; Sun, 12 Nov 2006 15:27:11 +0100 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 18FD8BC87; Sun, 12 Nov 2006 15:27:11 +0100 (CET) Date: Sun, 12 Nov 2006 15:27:10 +0100 From: Stefan Farfeleder To: Ruslan Ermilov Message-ID: <20061112142710.GE91556@wombat.fafoe.narf.at> Mail-Followup-To: Ruslan Ermilov , FreeBSD Tinderbox , arm@freebsd.org, current@freebsd.org References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112140010.GA47660@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:27:25 -0000 On Sun, Nov 12, 2006 at 05:00:10PM +0300, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > > >>> stage 4.2: building libraries > > [...] > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type > > *** Error code 1 > > > > Stop in /src/lib/libelf. > > *** Error code 1 > > > This looks like a GCC bug to me. The following code snippet, > when compiled on FreeBSD/arm, causes a -Wcast-align warning > which doesn't look right: > > %%% > $ cat a.c > struct foo { > char x; > }; > > struct foo * > bubu(char *s) > { > > return (struct foo *)s; > } > $ cc -c -Wcast-align a.c > a.c: In function `bubu': > a.c:9: warning: cast increases required alignment of target type > %%% > > (None of other supported architecutes see the issue here.) What is sizeof(struct foo)? If it's > 1 it makes sense. Stefan From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:43:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2299116A4EB; Sun, 12 Nov 2006 14:43:12 +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 4E43843D67; Sun, 12 Nov 2006 14:43:09 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACEgaQF032664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 16:42:45 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACEgVcj002729; Sun, 12 Nov 2006 15:42:31 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACEgUMi002728; Sun, 12 Nov 2006 15:42:30 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 15:42:30 +0100 From: Giorgos Keramidas To: Ruslan Ermilov , arm@freebsd.org, current@freebsd.org Message-ID: <20061112144230.GC2331@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112140010.GA47660@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, AWL 0.00, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:43:12 -0000 On 2006-11-12 17:00, Ruslan Ermilov wrote: > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type > > *** Error code 1 > > > > Stop in /src/lib/libelf. > > *** Error code 1 > > This looks like a GCC bug to me. The following code snippet, > when compiled on FreeBSD/arm, causes a -Wcast-align warning > which doesn't look right: > > %%% > $ cat a.c > struct foo { > char x; > }; > > struct foo * > bubu(char *s) > { > > return (struct foo *)s; > } > $ cc -c -Wcast-align a.c > a.c: In function `bubu': > a.c:9: warning: cast increases required alignment of target type > %%% > > (None of other supported architecutes see the issue here.) You can't cast any random (char *) pointer to a pointer of a type which is (potentially) larger than 1 byte. It's the same sort of warning you will get if you try to: char ch[] = "\x00\x00\x00\x00"; char *p = &(ch[0]); unsigned long *lptr = (unsigned long *)p; You cannot guarantee that `ch' is stored in an address that is properly aligned for (unsigned long), and this is what GCC warns about here. On 2006-11-12 15:27, Stefan Farfeleder wrote: > What is sizeof(struct foo)? If it's > 1 it makes sense. Exactly :) From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:43:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CBB316A40F for ; Sun, 12 Nov 2006 14:43:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F21443D73 for ; Sun, 12 Nov 2006 14:43:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 75956 invoked from network); 12 Nov 2006 14:36:29 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 14:36:29 -0000 Message-ID: <4557330D.3010009@freebsd.org> Date: Sun, 12 Nov 2006 15:43:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Pawel Worach References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> In-Reply-To: <4555BA65.4020603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, amistry@am-productions.biz Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 14:43:28 -0000 Pawel Worach wrote: > Andre Oppermann wrote: > >> >> I'm looking into the problem. Please try a binary FTP transfer as well >> and check if the checksums match. ftpd uses sendfile(2) as well but w/o >> headers or trailers and does the send in one swoop. >> > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file does not > trash it. Meanwhile a couple of other things where tested, SMP disabled > (removed from kernel config), added some printf's which when printing to > a serial console moves the offset where the breakage begins to > 0x01000000, sometimes. OK, I found the bug. The sent byte count reporting was incorrect. While doing the sendfile(2) rewrite I got lost in the mixup of the FreeBSD 4.x bug for bug compatibility. Please try this patch: http://people.freebsd.org/~andre/sendfile_fix-20061112.diff It fixes apache 2.0.59 for me. For some reason lighttpd didn't suffer from this problem, even w/o the fix. Unfortunately that's what I tested the rewrite against. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:46:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C68016A403; Sun, 12 Nov 2006 14:46:19 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F40643D7E; Sun, 12 Nov 2006 14:46:16 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 4D7155F37; Sun, 12 Nov 2006 17:46:15 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 289B95F35; Sun, 12 Nov 2006 17:46:15 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACEkI9M050075; Sun, 12 Nov 2006 17:46:18 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:46:18 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox , arm@freebsd.org, current@freebsd.org Message-ID: <20061112144618.GB49703@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <20061112142710.GE91556@wombat.fafoe.narf.at> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:46:19 -0000 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 03:27:10PM +0100, Stefan Farfeleder wrote: > On Sun, Nov 12, 2006 at 05:00:10PM +0300, Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > > > >>> stage 4.2: building libraries > > > [...] > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_getident.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_hash.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_kind.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_memory.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_next.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -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-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_rand.c > > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required align= ment of target type > > > *** Error code 1 > > >=20 > > > Stop in /src/lib/libelf. > > > *** Error code 1 > > >=20 > > This looks like a GCC bug to me. The following code snippet, > > when compiled on FreeBSD/arm, causes a -Wcast-align warning > > which doesn't look right: > >=20 > > %%% > > $ cat a.c > > struct foo { > > char x; > > }; > >=20 > > struct foo * > > bubu(char *s) > > { > >=20 > > return (struct foo *)s; > > } > > $ cc -c -Wcast-align a.c > > a.c: In function `bubu': > > a.c:9: warning: cast increases required alignment of target type > > %%% > >=20 > > (None of other supported architecutes see the issue here.) >=20 > What is sizeof(struct foo)? If it's > 1 it makes sense. >=20 Yes, it's four bytes on ARM. But why? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVzO6qRfpzJluFF4RAnW8AJ9XPR3d5tGGAHEkD06xWD07Frw2rACghbIi AssHx2oQOJQ9xso6+MNMaTA= =l4T9 -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:47:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E54216A47B for ; Sun, 12 Nov 2006 14:47:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1E5243DB8 for ; Sun, 12 Nov 2006 14:46:57 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 3500 invoked from network); 12 Nov 2006 14:46:54 -0000 Received: from unknown (HELO localhost) (775067@[217.50.200.64]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 14:46:54 -0000 Date: Sun, 12 Nov 2006 15:46:38 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061112154638.495ca09b@localhost> In-Reply-To: <4556F086.7050201@freebsd.org> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <4555BA65.4020603@gmail.com> <45560FB8.1040607@freebsd.org> <200611112302.23508.amistry@am-productions.biz> <4556F086.7050201@freebsd.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_1lYa0smxfG.p.C6FXCWvVwM; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 14:47:28 -0000 --Sig_1lYa0smxfG.p.C6FXCWvVwM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Anish Mistry wrote: > > On Saturday 11 November 2006 13:00, Andre Oppermann wrote: > >> Pawel Worach wrote: > >> I tried to reproduce the problem with lighttpd w/o success. > >> > >> My guess is that something gets wrong when using non-blocking > >> sockets and the http headers. Could you obtain the truss of the > >> sendfile(2) calls so I get the input parameters to it? A visual > >> inspection of a corruptly transferred text file would be helpful > >> too. This should give more hints what happens, like duplicated or > >> missing pages, etc. > > For me I'm seeing 3 different behaviors. > > 1) The file is just truncated after a few KB. > > 2) A section of the file is just missing. eg. A small section of the= =20 > > file in the middle is just gone. > > 3) The data is sent before the headers. eg. a portion of the html is=20 > > sent, and then you see >=20 > What webserver are you running? I was seeing similar problems with Apache/2.0.5[89] and Gatling 0.8. PNG files got corrupted and HTML files contained the last lines twice in some HTTP clients (not tested with Gatling). scp continued to work. After applying Joe's patch the PNG file corruption seems to be gone, but I'm still seeing the HTML corruption with Apache. I'm currently using FreeBSD 7.0-CURRENT #19: Sat Nov 11 13:53:29 CET 2006 I'm seeing the HTML problem at http://tor.fabiankeil.de/ with lynx without proxy or any client chained with Privoxy, but curl without proxy fetches the document intact and doesn't display an error message either. I'm not seeing the problem with Privoxy's integrated documentation web server which doesn't use sendfile. I didn't try this before applying Joe's patch though. Fabian --=20 http://www.fabiankeil.de/ --Sig_1lYa0smxfG.p.C6FXCWvVwM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVzPVBYqIVf93VJ0RAilXAJ9cn5FPZo6gEDbt8x/JCK+45O5CdACfdGZs NOCGNfajJysmtzTICmZAK8o= =4i2W -----END PGP SIGNATURE----- --Sig_1lYa0smxfG.p.C6FXCWvVwM-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:51:50 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BC416A415; Sun, 12 Nov 2006 14:51:50 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B71443D8F; Sun, 12 Nov 2006 14:51:48 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 99F2C5DAE; Sun, 12 Nov 2006 17:51:47 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 533EA5DAB; Sun, 12 Nov 2006 17:51:47 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACEppa0050144; Sun, 12 Nov 2006 17:51:51 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:51:51 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20061112145151.GC49703@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <20061112144230.GC2331@kobe.laptop> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:51:50 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required align= ment of target type > > > *** Error code 1 > > > > > > Stop in /src/lib/libelf. > > > *** Error code 1 > > > > This looks like a GCC bug to me. The following code snippet, > > when compiled on FreeBSD/arm, causes a -Wcast-align warning > > which doesn't look right: > > > > %%% > > $ cat a.c > > struct foo { > > char x; > > }; > > > > struct foo * > > bubu(char *s) > > { > > > > return (struct foo *)s; > > } > > $ cc -c -Wcast-align a.c > > a.c: In function `bubu': > > a.c:9: warning: cast increases required alignment of target type > > %%% > > > > (None of other supported architecutes see the issue here.) >=20 > You can't cast any random (char *) pointer to a pointer of a type which > is (potentially) larger than 1 byte. It's the same sort of warning you > will get if you try to: >=20 > char ch[] =3D "\x00\x00\x00\x00"; > char *p =3D &(ch[0]); > unsigned long *lptr =3D (unsigned long *)p; >=20 > You cannot guarantee that `ch' is stored in an address that is properly > aligned for (unsigned long), and this is what GCC warns about here. >=20 No, your example I perfectly understand but it is completely different. Note that the first (and only) member in my structure is "char", so it doesn't need to be more than sizeof(char) aligned. > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > What is sizeof(struct foo)? If it's > 1 it makes sense. >=20 > Exactly :) >=20 Still doesn't make much sense to me. If all structure members are chars (like is the case with "struct ar_hdr" from which GCC complains about, and in my example, the required alignment shouldn't be more than sizeof(char). What am I missing? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVzUHqRfpzJluFF4RAk/2AJ4/N4i6u2+Zz/RRzNDStRX76CV2fgCfXLiX RuNsL3WxU6JxtoI7ZX+Oi34= =Ibh/ -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 14:53:11 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E6916A403; Sun, 12 Nov 2006 14:53:11 +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 B077F43D8C; Sun, 12 Nov 2006 14:52:52 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACEqUis000662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 16:52:33 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACEqObg002858; Sun, 12 Nov 2006 15:52:25 +0100 (CET) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACEqOXN002857; Sun, 12 Nov 2006 15:52:24 +0100 (CET) (envelope-from keramida@FreeBSD.org) Date: Sun, 12 Nov 2006 15:52:24 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112145223.GE2331@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112144618.GB49703@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112144618.GB49703@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:53:11 -0000 On 2006-11-12 17:46, Ruslan Ermilov wrote: >On Sun, Nov 12, 2006 at 03:27:10PM +0100, Stefan Farfeleder wrote: >>> This looks like a GCC bug to me. The following code snippet, >>> when compiled on FreeBSD/arm, causes a -Wcast-align warning >>> which doesn't look right: >>> >>> %%% >>> $ cat a.c >>> struct foo { >>> char x; >>> }; >>> >>> struct foo * >>> bubu(char *s) >>> { >>> >>> return (struct foo *)s; >>> } >>> $ cc -c -Wcast-align a.c >>> a.c: In function `bubu': >>> a.c:9: warning: cast increases required alignment of target type >>> %%% >>> >>> (None of other supported architecutes see the issue here.) >> >> What is sizeof(struct foo)? If it's > 1 it makes sense. > > Yes, it's four bytes on ARM. But why? Probably because GCC thinks accessing 4-byte quantities is much much cheaper than 1-byte accesses on this ARM board. I'm not sure why GCC thinks so, though. From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 15:11:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CEE16A407 for ; Sun, 12 Nov 2006 15:11:40 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id E250343D83 for ; Sun, 12 Nov 2006 15:11:39 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so572628nzh for ; Sun, 12 Nov 2006 07:11:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NROCbYQ8GCfCDvTsupUzN+jMGf7nhFncJlOZ9dX5Zlcxo1LzwtUwgESZSdkD+rydEF/B/mt++JtT1wKFETJ9pdZ0FyDrCKyiac8KISesPPU4nYsghApxxcgjjYkibmL7Eak8vsDcCIA8bCLlEoYwhleWoPSTUZ+A7Y+5ksGXB8o= Received: by 10.65.250.11 with SMTP id c11mr6245342qbs.1163344298550; Sun, 12 Nov 2006 07:11:38 -0800 (PST) Received: by 10.64.204.15 with HTTP; Sun, 12 Nov 2006 07:11:38 -0800 (PST) Message-ID: <84dead720611120711q41d9dbefi5617f2edb03759f1@mail.gmail.com> Date: Sun, 12 Nov 2006 20:41:38 +0530 From: "Joseph Koshy" To: current@freebsd.org In-Reply-To: <20061111202438.CFBC473068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061111202438.CFBC473068@freebsd-current.sentex.ca> Cc: arm@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:11:40 -0000 > /src/lib/libelf/elf_rand.c: In function `elf_rand': > /src/lib/libelf/elf_rand.c:47: warning: cast increases > required alignment of target type > *** Error code 1 This is the offending line: $ sed -ne 47p elf_rand.c arh = (struct ar_hdr *) (ar->e_rawfile + offset); However, 'struct ar_hdr' is a collection of char[] arrays, so I'm puzzled as to why GCC/arm thinks 'struct ar_hdr' has an alignment requirement. __alignof__(struct ar_hdr) appears to be '4' according GCC/arm. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 15:12:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE1616A40F; Sun, 12 Nov 2006 15:12:35 +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 5EC1B43D66; Sun, 12 Nov 2006 15:12:30 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACFC3Kj002654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 17:12:09 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACFBqkf003046; Sun, 12 Nov 2006 16:11:54 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACFBpBo003045; Sun, 12 Nov 2006 16:11:51 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 16:11:51 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112151150.GA2988@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112145151.GC49703@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:12:35 -0000 On 2006-11-12 17:51, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > %%% > > > $ cat a.c > > > struct foo { > > > char x; > > > }; > > > > > > struct foo * > > > bubu(char *s) > > > { > > > > > > return (struct foo *)s; > > > } > > > $ cc -c -Wcast-align a.c > > > a.c: In function `bubu': > > > a.c:9: warning: cast increases required alignment of target type > > > %%% > > > > > > (None of other supported architecutes see the issue here.) > > > > You can't cast any random (char *) pointer to a pointer of a type which > > is (potentially) larger than 1 byte. It's the same sort of warning you > > will get if you try to: > > > > char ch[] = "\x00\x00\x00\x00"; > > char *p = &(ch[0]); > > unsigned long *lptr = (unsigned long *)p; > > > > You cannot guarantee that `ch' is stored in an address that is properly > > aligned for (unsigned long), and this is what GCC warns about here. > > No, your example I perfectly understand but it is completely different. > Note that the first (and only) member in my structure is "char", so it > doesn't need to be more than sizeof(char) aligned. Ah, but the tricky part is that inside bubu() there is no knowledge that `s' may be properly aligned for a (struct foo *) pointer. All the compiler knows is that it is a (char *), possibly misaligned for any pointer whose object has a size > 1. > > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > > What is sizeof(struct foo)? If it's > 1 it makes sense. > > > > Exactly :) > > Still doesn't make much sense to me. If all structure members are chars > (like is the case with "struct ar_hdr" from which GCC complains > about, and in my example, the required alignment shouldn't be more than > sizeof(char). What am I missing? You are missing that inside bubu() the compiler 'believes' that: * The `s' pointer is (char *)-aligned. * The sizeof(struct foo) is >1. * You are trying to assign `s' (with it's possibly misaligned value) to the `return value' place, whose type is (at least, as far as the compiler knows) is (struct foo *). That may break alignment assumptions the compiler is making inside bubu(), especially about the `s' pointer, hence the warning. - Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 15:28:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F44316A4EA for ; Sun, 12 Nov 2006 15:28:14 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 471CA43D6E for ; Sun, 12 Nov 2006 15:28:04 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by nf-out-0910.google.com with SMTP id l23so186598nfc for ; Sun, 12 Nov 2006 07:28:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ib4HYrBL19GCndhcpGVRaokTtzPkr+KTJwqQfH1ArP7wzRmhrOv30BlpAevGAwoyDJwJjKFj+yO8lpGpdJdC+M3RstjwLuvLsPRiU1ShpPobXD4H1wv8nI74LOOjFdZa1N1wyKjeYTo2nllCHQCx8jx3ttN5wYHSTfqLDwaNYss= Received: by 10.82.98.13 with SMTP id v13mr513378bub.1163345283512; Sun, 12 Nov 2006 07:28:03 -0800 (PST) Received: by 10.82.164.13 with HTTP; Sun, 12 Nov 2006 07:28:03 -0800 (PST) Message-ID: Date: Sun, 12 Nov 2006 16:28:03 +0100 From: "Pawel Worach" To: "Andre Oppermann" In-Reply-To: <4557330D.3010009@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> Cc: freebsd-current@freebsd.org, amistry@am-productions.biz Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 15:28:14 -0000 On 11/12/06, Andre Oppermann wrote: > Pawel Worach wrote: > > Andre Oppermann wrote: > > > >> > >> I'm looking into the problem. Please try a binary FTP transfer as well > >> and check if the checksums match. ftpd uses sendfile(2) as well but w/o > >> headers or trailers and does the send in one swoop. > >> > > > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file does not > > trash it. Meanwhile a couple of other things where tested, SMP disabled > > (removed from kernel config), added some printf's which when printing to > > a serial console moves the offset where the breakage begins to > > 0x01000000, sometimes. > > OK, I found the bug. The sent byte count reporting was incorrect. While > doing the sendfile(2) rewrite I got lost in the mixup of the FreeBSD 4.x > bug for bug compatibility. > > Please try this patch: > > http://people.freebsd.org/~andre/sendfile_fix-20061112.diff > > It fixes apache 2.0.59 for me. For some reason lighttpd didn't suffer > from this problem, even w/o the fix. Unfortunately that's what I tested > the rewrite against. > This fixes it for me, thanks! -- Pawel From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 15:52:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5EA116A417; Sun, 12 Nov 2006 15:52:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from customer-domains.icp-qv1-irony14.iinet.net.au (customer-domains.icp-qv1-irony14.iinet.net.au [203.59.1.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBABE43D6A; Sun, 12 Nov 2006 15:52:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from 203-59-110-253.dyn.iinet.net.au (HELO [10.1.1.3]) ([203.59.110.253]) by iinet-mail.icp-qv1-irony14.iinet.net.au with ESMTP; 12 Nov 2006 23:52:43 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAErQVkXLO279VWdsb2JhbAANjDYBKw X-IronPort-AV: i="4.09,414,1157299200"; d="scan'208"; a="24117918:sNHT16434684" Message-ID: <4557434C.7080106@elischer.org> Date: Sun, 12 Nov 2006 07:52:44 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Chris References: <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> In-Reply-To: <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: threads@freebsd.org, freebsd-current@freebsd.org Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 15:52:47 -0000 Chris wrote: [...] > > > HI I posted in another thread about how my own experiences seem to > differ from all these benchmarks, they are based on 3 heavily loaded > web/mysql servers. > > One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd > 6.1 and 3rd is another dual xeon freebsd 6.1. > > All 3 of these machines perform better as well as more stable under > higher loads using libpthread process scope. > > System scope appears to make mysql hog the system and everything slows > down except of course mysql. Is this libpthread "system scope" or libthr (which has system scope by default)? > > Libthr appears to make mysql very sporadic with some requests fast > others with a unexplained 5-10 sec delay including timeouts. > > Process scope on libpthread gives me the best results not making mysql > starve the server of resources and it has a consistent response time > of under 2 seconds under heavy loads. this is interesting.. there has been a call to remove "fairness" as a threading property as it complicates the scheduler. It has been said by many that they do not consider this as an important feature and it reduces throughput. > > I cant explain other then it maybe that test mysql data isnt a proper > way to test these threading libraries only real work loads can. > > Chris > _______________________________________________ > 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 Nov 12 15:57:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E013A16A415; Sun, 12 Nov 2006 15:57:55 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E9643D9D; Sun, 12 Nov 2006 15:57:21 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 3B6F15EEC; Sun, 12 Nov 2006 18:57:20 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 195A75E9C; Sun, 12 Nov 2006 18:57:20 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACFvNMe050883; Sun, 12 Nov 2006 18:57:23 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 18:57:23 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20061112155723.GB50349@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <20061112151150.GA2988@kobe.laptop> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:57:56 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:11:51PM +0100, Giorgos Keramidas wrote: > On 2006-11-12 17:51, Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > > > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > > %%% > > > > $ cat a.c > > > > struct foo { > > > > char x; > > > > }; > > > > > > > > struct foo * > > > > bubu(char *s) > > > > { > > > > > > > > return (struct foo *)s; > > > > } > > > > $ cc -c -Wcast-align a.c > > > > a.c: In function `bubu': > > > > a.c:9: warning: cast increases required alignment of target type > > > > %%% > > > > > > > > (None of other supported architecutes see the issue here.) > > >=20 > > > You can't cast any random (char *) pointer to a pointer of a type whi= ch > > > is (potentially) larger than 1 byte. It's the same sort of warning y= ou > > > will get if you try to: > > >=20 > > > char ch[] =3D "\x00\x00\x00\x00"; > > > char *p =3D &(ch[0]); > > > unsigned long *lptr =3D (unsigned long *)p; > > >=20 > > > You cannot guarantee that `ch' is stored in an address that is proper= ly > > > aligned for (unsigned long), and this is what GCC warns about here. > >=20 > > No, your example I perfectly understand but it is completely different. > > Note that the first (and only) member in my structure is "char", so it > > doesn't need to be more than sizeof(char) aligned. >=20 > Ah, but the tricky part is that inside bubu() there is no knowledge that > `s' may be properly aligned for a (struct foo *) pointer. All the > compiler knows is that it is a (char *), possibly misaligned for any > pointer whose object has a size > 1. >=20 I don't think you're right. If I don't declare a structure so that the compiler REALLY doesn't know the alignment requirement, it doesn't even complain (this is on ARM): : $ diff -u20 a.c b.c : --- a.c Sun Nov 12 18:19:34 2006 : +++ b.c Sun Nov 12 18:19:22 2006 : @@ -1,10 +1,12 @@ : #include : =20 : -struct foo; : +struct foo { : + char x; : +}; : =20 : struct foo * : bubu(char *s) : { : =20 : return (struct foo *)s; : } : $ cc -c -Wcast-align a.c : $ cc -c -Wcast-align b.c : b.c: In function `bubu': : b.c:11: warning: cast increases required alignment of target type > > > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > > > What is sizeof(struct foo)? If it's > 1 it makes sense. > > >=20 > > > Exactly :) > >=20 > > Still doesn't make much sense to me. If all structure members are chars > > (like is the case with "struct ar_hdr" from which GCC complains > > about, and in my example, the required alignment shouldn't be more than > > sizeof(char). What am I missing? >=20 > You are missing that inside bubu() the compiler 'believes' that: >=20 > * The `s' pointer is (char *)-aligned. >=20 > * The sizeof(struct foo) is >1. >=20 > * You are trying to assign `s' (with it's possibly misaligned > value) to the `return value' place, whose type is (at > least, as far as the compiler knows) is (struct foo *). >=20 I will assume that under a "misaligned value" you mean a data that the `s' pointer points to. Assigning a pointer to pointer isn't a problem per se, there are no alignment issues here; dereferencing an assigned pointer later might be a problem if it points to an object with more strict alignment requirement. This is all clear and fine, I understand how all this works. :-) What I don't seem to understand (and you didn't tell me) is why the alignment requirement for "struct foo" is >1. From the above it looks like you're thinking that __alignof__(x) >=3D sizeof(x). Fortunately, not all that bad, and compiling the following snippet on sparc64: : #include :=20 : struct foo1 { : char foo[4]; : }; :=20 : struct foo2 { : int foo; : }; :=20 : int : main(char *s) : { : struct foo1 *foo1 =3D (struct foo1 *)s; : struct foo2 *foo2 =3D (struct foo2 *)s; : printf("%jd %jd\n", __alignof__(*foo1), __alignof__(*foo2)); : } Only complains about the second assignment: : a.c: In function `main': : a.c:15: warning: cast increases required alignment of target type Running it outputs: "1 4". Similarly for "struct ar_hdr", whose all members are character arrays, also has the alignment requirement of 1 byte (verified on sparc64). So your sizeof() argument, well... I don't understand it and it doesn't make things clearer at least to me. I still believe this is bug in GCC that the alignment requirement is so high for a "struct foo { char x; }" (there's no real reason for this!). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV0RjqRfpzJluFF4RAlAOAKCXFEwLbtRFOFq2kvM8B5/Xgu1VJACdEFva Cdzbot64aK6bvxSbXCKw3iI= =/D0P -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 16:00:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4077016A407 for ; Sun, 12 Nov 2006 16:00:02 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0747F43D94 for ; Sun, 12 Nov 2006 15:58:55 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so577899nzh for ; Sun, 12 Nov 2006 07:58:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hrMMllOgmJrcLHJJhQbDsiUgL2Ea2K7LnqBp3tFRB5anCPsYj1K8VbfILccj78Cgha9/o+EvsyjnW54z/0vqQpW9v7Ryak1WlkV6FvtZYLowKO8TUqIRQIqVTeEXdNWOGIwaxg1LPTcasxkGBUdzuD6Geev17g1VrpIqQ8FldEg= Received: by 10.64.199.2 with SMTP id w2mr6271488qbf.1163347129719; Sun, 12 Nov 2006 07:58:49 -0800 (PST) Received: by 10.64.204.15 with HTTP; Sun, 12 Nov 2006 07:58:49 -0800 (PST) Message-ID: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> Date: Sun, 12 Nov 2006 21:28:49 +0530 From: "Joseph Koshy" To: "Giorgos Keramidas" In-Reply-To: <20061112151150.GA2988@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:00:02 -0000 ru> Still doesn't make much sense to me. If all structure ru> members are chars (like is the case with "struct ar_hdr" ru> from which GCC complains about, and in my example, ru> the required alignment shouldn't be more than sizeof(char). ru> What am I missing? gk> You are missing that inside bubu() the compiler gk> 'believes' that: gk> * The `s' pointer is (char *)-aligned. gk> * The sizeof(struct foo) is >1. gk> * You are trying to assign `s' (with it's possibly gk> misaligned value) to the `return value' place, gk> whose type is (at least, as far as the compiler gk> knows) is (struct foo *). gk> That may break alignment assumptions the compiler is making gk> inside bubu(), especially about the `s' pointer, hence the gk> warning. The following program prints `1' on the AMD64, i386 and on sparc64. ----- SNIP ---- #include struct foo { char x; }; int main(int c, char **v) { printf("align=%d\n", __alignof__(struct foo)); } ---- SNIP --- I don't have a way of running ARM binaries, but disassembly of the binary shows: 00000000
: ... snip ... 20: e59f0010 ldr r0, [pc, #16] ; 38 <.text+0x38> 24: e3a01004 mov r1, #4 ; 0x4 28: ebfffffe bl 28 2c: e1a00003 mov r0, r3 ... snip ... If I am reading the assembly correctly, GCC thinks that the alignment for struct foo is '4'. However, changing the program print `__alignof__(foo.x)' results in a value of `1' being loaded into R1. And then `sizeof (struct foo)` appears to be 4 with GCC/arm and 1 on the other architectures. GCC/arm also thinks that the alignment requirement for `char a[1]' is `4', even though `sizeof(char a[1])` remains at 1. This doesn't make sense at many levels. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy/ From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 16:00:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209A816A5F2 for ; Sun, 12 Nov 2006 16:00:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6640F43DB0 for ; Sun, 12 Nov 2006 16:00:31 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 25376 invoked from network); 12 Nov 2006 16:00:29 -0000 Received: from unknown (HELO localhost) (775067@[217.50.200.64]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 16:00:29 -0000 Date: Sun, 12 Nov 2006 17:00:13 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061112170013.78949e96@localhost> In-Reply-To: <4557330D.3010009@freebsd.org> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_PmVDMkKbRdwp9VLzKDbOry8; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 16:00:58 -0000 --Sig_PmVDMkKbRdwp9VLzKDbOry8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Pawel Worach wrote: > > Andre Oppermann wrote: > >=20 > >> > >> I'm looking into the problem. Please try a binary FTP transfer as > >> well and check if the checksums match. ftpd uses sendfile(2) as well > >> but w/o headers or trailers and does the send in one swoop. > >> > >=20 > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file does > > not trash it. Meanwhile a couple of other things where tested, SMP > > disabled (removed from kernel config), added some printf's which when > > printing to a serial console moves the offset where the breakage > > begins to 0x01000000, sometimes. >=20 > OK, I found the bug. The sent byte count reporting was incorrect. While > doing the sendfile(2) rewrite I got lost in the mixup of the FreeBSD 4.x > bug for bug compatibility. >=20 > Please try this patch: >=20 > http://people.freebsd.org/~andre/sendfile_fix-20061112.diff >=20 > It fixes apache 2.0.59 for me. For me too, but I'm still seeing problems with Gatling/0.8. [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat-queues.png pfstat-queues.png 78% of 5206 B 2706 kBps fetch: pfstat-queues.png appears to be truncated: 4096/5206 bytes [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat-queues.png pfstat-queues.png 78% of 5206 B 1484 kBps fetch: pfstat-queues.png appears to be truncated: 4096/5206 bytes [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat.png pfstat.png 83% of 4929 B 1881 kBps fetch: pfstat.png appears to be truncated: 4096/4929 bytes [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat.png pfstat.png 83% of 4929 B 1777 kBps fetch: pfstat.png appears to be truncated: 4096/4929 bytes PNG files always seem to be truncated after 4096 bytes, the same files are delivered with Apache without problems. This is on FreeBSD 7.0-CURRENT #20: Sun Nov 12 16:24:32 CET 2006 with your patch and without Joe's one. Fabian --=20 http://www.fabiankeil.de/ --Sig_PmVDMkKbRdwp9VLzKDbOry8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV0UUBYqIVf93VJ0RAnYSAJ4mYBpV/nk+oow8ib+HZcuI290mhwCfbwpO TKqwoe8QuozK/judJs2IjUM= =4rwT -----END PGP SIGNATURE----- --Sig_PmVDMkKbRdwp9VLzKDbOry8-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 16:27:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2916C16A47C; Sun, 12 Nov 2006 16:27:27 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 413E343D46; Sun, 12 Nov 2006 16:27:19 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 1208C5FBB; Sun, 12 Nov 2006 19:27:18 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id E54295FAC; Sun, 12 Nov 2006 19:27:17 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACGRLeV051756; Sun, 12 Nov 2006 19:27:21 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 19:27:21 +0300 From: Ruslan Ermilov To: Joseph Koshy Message-ID: <20061112162721.GD50349@rambler-co.ru> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:27:27 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > The following program prints `1' on the AMD64, i386 and on > sparc64. >=20 > ----- SNIP ---- > #include >=20 > struct foo { > char x; > }; >=20 > int > main(int c, char **v) > { > printf("align=3D%d\n", __alignof__(struct foo)); > } > ---- SNIP --- >=20 Yes. > I don't have a way of running ARM binaries, but > disassembly of the binary shows: > 00000000
: > ... snip ... > 20: e59f0010 ldr r0, [pc, #16] ; 38 <.text+0x38> > 24: e3a01004 mov r1, #4 ; 0x4 > 28: ebfffffe bl 28 > 2c: e1a00003 mov r0, r3 > ... snip ... >=20 :-) I cheated differently; if (sizeof(...) =3D=3D 1) printf("1111111111111"); else if (sizeof(...) =3D=3D 2) printf("2222222222222"); and then running strings(1) on the object file to find the answer. > If I am reading the assembly correctly, GCC thinks that > the alignment for struct foo is '4'. However, changing > the program print `__alignof__(foo.x)' results in a value > of `1' being loaded into R1. >=20 __alignof__(foo.x) has nothing to do with __alignof__(foo); here's a relevant snippet from gcc.info: : If the operand of `__alignof__' is an lvalue rather than a type, its : value is the required alignment for its type, taking into account any : minimum alignment specified with GCC's `__attribute__' extension (*note : Variable Attributes::). For example, after this declaration: :=20 : struct foo { int x; char y; } foo1; :=20 : the value of `__alignof__ (foo1.y)' is 1, even though its actual : alignment is probably 2 or 4, the same as `__alignof__ (int)'. > And then `sizeof (struct foo)` appears to be 4 with GCC/arm > and 1 on the other architectures. >=20 Yes, but even with this insane sizeof(), it should not be an alignment problem; see my other email which shows that alignment of a four-byte structure can still be 1 byte (like is the case for "struct ar_hdr" on all other arches). It was always my basic sunderstanding that an alignment of a structure type is a maximum of alignments of its members, so this struct foo { char foo[16]; char x; char bar[32]; }; doesn't have alignment requirements, and this struct foo { char foo[16]; int x; char bar[32]; }; should be 4 bytes aligned assuming sizeof(int) =3D=3D 4. > GCC/arm also thinks that the alignment requirement for > `char a[1]' is `4', even though `sizeof(char a[1])` > remains at 1. >=20 > This doesn't make sense at many levels. >=20 For one thing, such a structure is not "portable" -- you cannot pass it over a network safely without the __attribute__((packed)) which should be redundant here. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --eheScQNz3K90DVRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV0tpqRfpzJluFF4RAuWPAJ9aKuu3QRgJCcPn/sii6022LKwT2QCfZWZQ tObU0gTNX669NL3oouGWLtY= =TZVZ -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 17:14:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 437E416A403; Sun, 12 Nov 2006 17:14:44 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7285843D46; Sun, 12 Nov 2006 17:14:34 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 9347D5E5E; Sun, 12 Nov 2006 20:14:33 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 713D35E5C; Sun, 12 Nov 2006 20:14:33 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACHEbRQ053693; Sun, 12 Nov 2006 20:14:37 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 20:14:37 +0300 From: Ruslan Ermilov To: Giorgos Keramidas , arm@freebsd.org, current@freebsd.org Message-ID: <20061112171436.GF50349@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <20061112165904.GP6501@plum.flirble.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:14:44 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: > On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > > So your sizeof() argument, well... I don't understand it and it > > doesn't make things clearer at least to me. I still believe this > > is bug in GCC that the alignment requirement is so high for a > > "struct foo { char x; }" (there's no real reason for this!). >=20 > It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to > align (or pad) structures. The assumptions in the code you presented are = not > portable. The problem tends to be that ARM is the only common platform th= at > does structure alignment this way, so tends to trip up a lot of code that > has worked just fine in many other places. >=20 > There is a lot more detail in > http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html > including how gcc's __packed__ extention can be used to tell gcc to align > structures in different ways. >=20 Thanks! Item 2 at this URL has an answer to my question. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --tMbDGjvJuJijemkf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV1Z8qRfpzJluFF4RAnrMAJsHxnuDRsfSADbZhIuqVaSalcaOdACfZkqZ zHQkfDktO4QwcnjRNJPs1iE= =9vjp -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 18:01:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BFC216A412; Sun, 12 Nov 2006 18:01:17 +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 501F943D7E; Sun, 12 Nov 2006 18:01:10 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACI0ivr012141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 20:00:49 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACI0WGC006785; Sun, 12 Nov 2006 19:00:35 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACI0Wae006784; Sun, 12 Nov 2006 19:00:32 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 19:00:32 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112180031.GC4237@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20061112155723.GB50349@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:01:17 -0000 On 2006-11-12 18:57, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 04:11:51PM +0100, Giorgos Keramidas wrote: > > Ah, but the tricky part is that inside bubu() there is no knowledge that > > `s' may be properly aligned for a (struct foo *) pointer. All the > > compiler knows is that it is a (char *), possibly misaligned for any > > pointer whose object has a size > 1. > > I don't think you're right. If I don't declare a structure so that the > compiler REALLY doesn't know the alignment requirement, it doesn't even > complain (this is on ARM): > > : $ diff -u20 a.c b.c > : --- a.c Sun Nov 12 18:19:34 2006 > : +++ b.c Sun Nov 12 18:19:22 2006 > : @@ -1,10 +1,12 @@ > : #include > : > : -struct foo; > : +struct foo { > : + char x; > : +}; > : > : struct foo * > : bubu(char *s) > : { > : > : return (struct foo *)s; > : } > : $ cc -c -Wcast-align a.c > : $ cc -c -Wcast-align b.c > : b.c: In function `bubu': > : b.c:11: warning: cast increases required alignment of target type The type of (struct foo) in a.c is an "incomplete type" (a type for which the compiler has no size information yet, c.f. ISO/IEC 9899:1999 §6.2.5 (1)). This is probably it doesn't complain about the same problem in `a.c'. What I *don't* know and I can't explain is why sizeof(struct foo) in `b.c' is larger than 1 byte. >>On 2006-11-12 17:00, Ruslan Ermilov wrote: >>> %%% >>> $ cat a.c >>> struct foo { >>> char x; >>> }; >>> >>> struct foo * >>> bubu(char *s) >>> { >>> >>> return (struct foo *)s; >>> } >>> $ cc -c -Wcast-align a.c >>> a.c: In function `bubu': >>> a.c:9: warning: cast increases required alignment of target type >>> %%% >> >> You are missing that inside bubu() the compiler 'believes' that: >> >> * The `s' pointer is (char *)-aligned. >> >> * The sizeof(struct foo) is >1. >> >> * You are trying to assign `s' (with it's possibly misaligned >> value) to the `return value' place, whose type is (at >> least, as far as the compiler knows) is (struct foo *). > > I will assume that under a "misaligned value" you mean a data that the > `s' pointer points to. Assigning a pointer to pointer isn't a problem > per se, there are no alignment issues here; dereferencing an assigned > pointer later might be a problem if it points to an object with more > strict alignment requirement. Right. But the compiler can't really tell if you *are* dereferencing the return value of bubu() somewhere else, just by looking at the definition of bubu()'s body. So it warns you about a potentially problematic cast. > This is all clear and fine, I understand how all this works. :-) > What I don't seem to understand (and you didn't tell me) is why the > alignment requirement for "struct foo" is >1. From the above it looks > like you're thinking that __alignof__(x) >= sizeof(x). Fortunately, > not all that bad, and compiling the following snippet on sparc64: > > : #include > : > : struct foo1 { > : char foo[4]; > : }; > : > : struct foo2 { > : int foo; > : }; > : > : int > : main(char *s) > : { > : struct foo1 *foo1 = (struct foo1 *)s; > : struct foo2 *foo2 = (struct foo2 *)s; > : printf("%jd %jd\n", __alignof__(*foo1), __alignof__(*foo2)); > : } > > Only complains about the second assignment: > > : a.c: In function `main': > : a.c:15: warning: cast increases required alignment of target type > > Running it outputs: "1 4". Similarly for "struct ar_hdr", whose all > members are character arrays, also has the alignment requirement of > 1 byte (verified on sparc64). > > So your sizeof() argument, well... I don't understand it and it > doesn't make things clearer at least to me. I still believe this > is bug in GCC that the alignment requirement is so high for a > "struct foo { char x; }" (there's no real reason for this!). I tried accessing panther.freebsd.org to test this on sparc64 earlier, but it doesn't seem to work from here. I can't really explain why on ARM the alignment requirements seem odd, though. From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 18:08:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFFB16A403; Sun, 12 Nov 2006 18:08:35 +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 8CB8A43D5A; Sun, 12 Nov 2006 18:08:33 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACI84Mt013458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 20:08:08 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACI7wXu006837; Sun, 12 Nov 2006 19:07:59 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACI7waS006836; Sun, 12 Nov 2006 19:07:58 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 19:07:58 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112180758.GD4237@kobe.laptop> References: <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112171436.GF50349@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:08:35 -0000 On 2006-11-12 20:14, Ruslan Ermilov wrote: >On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: >>On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: >>> So your sizeof() argument, well... I don't understand it and it >>> doesn't make things clearer at least to me. I still believe this >>> is bug in GCC that the alignment requirement is so high for a >>> "struct foo { char x; }" (there's no real reason for this!). >> >> It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to >> align (or pad) structures. The assumptions in the code you presented are not >> portable. The problem tends to be that ARM is the only common platform that >> does structure alignment this way, so tends to trip up a lot of code that >> has worked just fine in many other places. >> >> There is a lot more detail in >> http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html >> including how gcc's __packed__ extention can be used to tell gcc to align >> structures in different ways. > > Thanks! Item 2 at this URL has an answer to my question. Perfect! Now it's obvious why GCC prefers '4-byte accesses' on ARM. Nicholas, thank you so much :) From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 18:21:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8757116A4EB for ; Sun, 12 Nov 2006 18:21:20 +0000 (UTC) (envelope-from kabaev@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 2E4B343D5D for ; Sun, 12 Nov 2006 18:21:17 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so896316wxc for ; Sun, 12 Nov 2006 10:21:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=mTYpcOafrAiWxpFLvW8igWaTBUOJLLFMu4BlLO300fxAyC4cNjJrGdlWWc+/mQBK6EhwCZJCX+a51KPlkULgGSjbTBJqCSxxsgxFj2hdu7gn0mSKxERTDCian37JLJ4wrJTL6Xk2tjkAl/xprWc9gNWSbWhlBvGyyeT17HooLNo= Received: by 10.70.113.13 with SMTP id l13mr7938392wxc.1163355675526; Sun, 12 Nov 2006 10:21:15 -0800 (PST) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id h38sm8741641wxd.2006.11.12.10.21.14; Sun, 12 Nov 2006 10:21:14 -0800 (PST) Date: Sun, 12 Nov 2006 13:21:05 -0500 From: Alexander Kabaev To: Giorgos Keramidas Message-ID: <20061112132105.6bac38d6@kan.dnsalias.net> In-Reply-To: <20061112180758.GD4237@kobe.laptop> References: <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_CjRMC7u8sQyTRrKNY83VXXE; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:21:20 -0000 --Sig_CjRMC7u8sQyTRrKNY83VXXE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 12 Nov 2006 19:07:58 +0100 Giorgos Keramidas wrote: > On 2006-11-12 20:14, Ruslan Ermilov wrote: > >On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: > >>On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > >>> So your sizeof() argument, well... I don't understand it and it > >>> doesn't make things clearer at least to me. I still believe this > >>> is bug in GCC that the alignment requirement is so high for a > >>> "struct foo { char x; }" (there's no real reason for this!). > >> > >> It is no bug in GCC. ANSI C gives extreme flexibility for the > >> compiler to align (or pad) structures. The assumptions in the code > >> you presented are not portable. The problem tends to be that ARM > >> is the only common platform that does structure alignment this > >> way, so tends to trip up a lot of code that has worked just fine > >> in many other places. > >> > >> There is a lot more detail in > >> http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html > >> including how gcc's __packed__ extention can be used to tell gcc > >> to align structures in different ways. > > > > Thanks! Item 2 at this URL has an answer to my question. >=20 > Perfect! >=20 > Now it's obvious why GCC prefers '4-byte accesses' on ARM. > Nicholas, thank you so much :) >=20 GCC expects 4-byte aligned structured on ARM but does not necessarily have to. We can change the default at the expense of possible more inefficient code generated and lost binary compatibility with other ARM OSes out there. So this is trade off between unclear performance penalty and an unspecified but certainly sizable number of other landmines like this lurking on the code. We should decide what evil we regard as lesser. --=20 Alexander Kabaev --Sig_CjRMC7u8sQyTRrKNY83VXXE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV2YYQ6z1jMm+XZYRAiv6AJwI+6bO6xIP6qnbAnx+V3R4zg0Z/wCgnzGw THSY8Ry1ncgrGhqV+CoECNY= =zjot -----END PGP SIGNATURE----- --Sig_CjRMC7u8sQyTRrKNY83VXXE-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 18:32:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9723816A412 for ; Sun, 12 Nov 2006 18:32:57 +0000 (UTC) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E64E643D73 for ; Sun, 12 Nov 2006 18:32:56 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([24.202.77.103]) by VL-MO-MR004.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J8M000NHRIVYW50@VL-MO-MR004.ip.videotron.ca> for freebsd-current@freebsd.org; Sun, 12 Nov 2006 13:32:56 -0500 (EST) Date: Sun, 12 Nov 2006 13:32:47 -0500 From: Nicolas Blais To: freebsd-current@freebsd.org Message-id: <200611121332.55397.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; boundary=nextPart1814664.eKacNRNqIs; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit User-Agent: KMail/1.9.4 Subject: Oddity with apache-2.2.3 since upgrade 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: Sun, 12 Nov 2006 18:32:57 -0000 --nextPart1814664.eKacNRNqIs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline So I've done my weekly upgrade to -CURRENT this morning (usually it's Satur= day=20 but it was fubar'ed yesterday), but now apache seems to corrupts binary fil= es=20 in the transfer.=20 My httpd logs show no errors, and code 200 (successful transfer) is done fo= r=20 my images and other binary files, but the result is a corrupted image or fi= le=20 on the client's side. After googling for a solution, I found that putting : EnableSendfile off in my httpd.conf file would solve the problem. Which it does. It looks like= =20 the actual problem isn't apache (and it worked fine before my upgrade this= =20 morning) but something in either the network layer or perhaps the pf firewa= ll=20 (wild guess...).=20 Any others having a similar problem? Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #10: Sun Nov 12 10:07:33 EST 2006 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart1814664.eKacNRNqIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFV2jX4wTBlvcsbJURAhUfAJwNoHLVK84RnGpOaNLmq6wOuexXPgCfXeAW zXVBQNpxvTorW/O7pUC1gCA= =yKV/ -----END PGP SIGNATURE----- --nextPart1814664.eKacNRNqIs-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 18:55:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295D816A403; Sun, 12 Nov 2006 18:55:27 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA43343D46; Sun, 12 Nov 2006 18:55:26 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 771565B3C; Sun, 12 Nov 2006 10:55:26 -0800 (PST) To: freebsd-emulation@freebsd.org Date: Sun, 12 Nov 2006 10:55:26 -0800 From: Bakul Shah Message-Id: <20061112185526.771565B3C@mail.bitblocks.com> Cc: freebsd-current@freebsd.org Subject: attack of the zombies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 18:55:27 -0000 About a week or so ago I updated -current and now linux binaries don't seem to collect all zombie processes. Eventually the maxproc limit is reached and further forks fail so that you can't even do ps (of course, dealing sensibly with such errors is another problem with most programs but that is a separate discussion). Work around is killing linux programs to allow init to kill the zombies. This happens with skype, firefox and opera and may be more. I reinstalled linux_base-fc-4_9 and all ports depending on it -- all updated yesterday. The problem persists even with yesterday's -current. This problem showed up sometime between Oct 6 and Nov 6. One significant change I see during this time is the treatment of KSE. But presence or absence of nooption KSE does not seem to affect this problem. BTW, linux emulation is loaded as a module. Also note that the old problem of linux-* programs gobbling up lots of memory is still present. For example, FreeBSD opera uses 96MB while Linux opera on FreeBSD needs 236MB + 48 zombies to displaying exact same 24 pages (same session file and *just* after starting!). Is this a known problem? Am I doing something wrong? Thanks! From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 19:08:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D7AF16A500 for ; Sun, 12 Nov 2006 19:08:15 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED70543DB7 for ; Sun, 12 Nov 2006 19:07:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AE0DD1A4D86; Sun, 12 Nov 2006 11:07:30 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 86D6A513BC; Sun, 12 Nov 2006 14:07:19 -0500 (EST) Date: Sun, 12 Nov 2006 14:07:19 -0500 From: Kris Kennaway To: Nicolas Blais Message-ID: <20061112190718.GA18383@xor.obsecurity.org> References: <200611121332.55397.nb_root@videotron.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <200611121332.55397.nb_root@videotron.ca> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: Oddity with apache-2.2.3 since upgrade 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: Sun, 12 Nov 2006 19:08:15 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 01:32:47PM -0500, Nicolas Blais wrote: > So I've done my weekly upgrade to -CURRENT this morning (usually it's Sat= urday=20 > but it was fubar'ed yesterday), but now apache seems to corrupts binary f= iles=20 > in the transfer.=20 >=20 > My httpd logs show no errors, and code 200 (successful transfer) is done = for=20 > my images and other binary files, but the result is a corrupted image or = file=20 > on the client's side. >=20 > After googling for a solution, I found that putting : > EnableSendfile off > in my httpd.conf file would solve the problem. Which it does. It looks li= ke=20 > the actual problem isn't apache (and it worked fine before my upgrade thi= s=20 > morning) but something in either the network layer or perhaps the pf fire= wall=20 > (wild guess...).=20 >=20 > Any others having a similar problem? See recent discussion + patch. Kris --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV3DlWry0BWjoQKURAuTgAKD4TCXlnbN9LllFBkqVgTxfKcZ+0wCfcWtL FRbxNAE1qRtYf2YZnVIbOIQ= =5eZE -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 19:13:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7476016A415; Sun, 12 Nov 2006 19:13:51 +0000 (UTC) (envelope-from ivoras@freebsd.org) Received: from ls405.htnet.hr (ls405.t-com.hr [195.29.150.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4EAE43D7F; Sun, 12 Nov 2006 19:13:23 +0000 (GMT) (envelope-from ivoras@freebsd.org) Received: from ls242.t-com.hr (ls242.t-com.hr [195.29.150.134]) by ls405.htnet.hr (Postfix) with ESMTP id F1FEA14658B; Sun, 12 Nov 2006 20:13:21 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id D3D7A10F8055; Sun, 12 Nov 2006 20:13:21 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id BC7BC10F8057; Sun, 12 Nov 2006 20:13:21 +0100 (CET) X-Envelope-Sender-Info: qNMqIwJL6pMxrLsv6Bv6Q+DON6a015vxOcE6sDDdqLFwavEOfecH+Ec8BH2pviS1 X-Envelope-Sender: ivoras@freebsd.org Received: from [10.0.0.100] (89-172-63-161.adsl.net.t-com.hr [89.172.63.161])by ls242.t-com.hr (Qmali) with ESMTP id 95B086C0036; Sun, 12 Nov 2006 20:13:21 +0100 (CET) Message-ID: <4557725B.2060804@freebsd.org> Date: Sun, 12 Nov 2006 20:13:31 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 References: <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808c u7e1f710970350044@mail.gmail.com> <4557434C.7080106@elischer.org> In-Reply-To: <4557434C.7080106@elischer.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-imss-version: 2.044 X-imss-result: Passed X-imss-scanInfo: M:P L:N SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(14806.003) X-imss-scores: Clean:6.13759 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:3 C:3 M:3 S:3 R:3 (0.5000 0.5000) Cc: threads@freebsd.org, freebsd-current@freebsd.org Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivoras@fer.hr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 19:13:51 -0000 Julian Elischer wrote: > this is interesting.. there has been a call to remove "fairness" > as a threading property as it complicates the scheduler. > It has been said by many that they do not consider this as an important > feature and it reduces throughput. IMO both sides are right and fairness should be optional. It will certainly help some workloads and harm others; leaving it as a (default) kernel compile option is fine for now, as long as it's documented how to toggle it (in pthread man page at least). From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 19:28:22 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F55D16A4C9; Sun, 12 Nov 2006 19:28:22 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E1D43DA2; Sun, 12 Nov 2006 19:28:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 07FDE6046; Sun, 12 Nov 2006 22:28:07 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id D852D5EDD; Sun, 12 Nov 2006 22:28:06 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACJSAj6027872; Sun, 12 Nov 2006 22:28:10 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 22:28:10 +0300 From: Ruslan Ermilov To: Alexander Kabaev Message-ID: <20061112192810.GC1173@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: <20061112132105.6bac38d6@kan.dnsalias.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, Giorgos Keramidas , current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 19:28:22 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: > GCC expects 4-byte aligned structured on ARM but does not necessarily > have to. We can change the default at the expense of possible more > inefficient code generated and lost binary compatibility with other ARM > OSes out there. So this is trade off between unclear performance > penalty and an unspecified but certainly sizable number of other > landmines like this lurking on the code. >=20 > We should decide what evil we regard as lesser. >=20 This is the only buildworld problem so far on FreeBSD/ARM, so my feeling is that we can actually benefit from leaving it "as is", as it has a potential of making our code more portable. Of course if binary compatibility for structs across platforms is an issue, a structure should be "packed", because otherwise the C standard says that "Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type." On the other hand, having GCC align "struct foo { char x[11]; }" on a four-byte boundary (other than for backward compatibility) doesn't make too much sense to me. I don't know GCC rules for alignment of structure members. For example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) is always 1 for "struct foo { char foo; char bar; }" (without the "packed" attribute) on all platforms and OSes GCC supports? I'd expect the latter to be "4" for FreeBSD/ARM but fortunately it stays "1", i.e., only the structure alignment is affected, and not of structure members (which is POLA but makes the 4 byte for structure alignment questionable). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ALfTUftag+2gvp1h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV3XKqRfpzJluFF4RAkf+AJ9iKs5nW9ORpNQnI4vQUWSAHMFMWACfdLsB aBsZvSlKNYnR6XkANypmCdg= =CPYa -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 19:48:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F02BA16A407 for ; Sun, 12 Nov 2006 19:48:40 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 415E543D81 for ; Sun, 12 Nov 2006 19:48:28 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 13140 invoked from network); 12 Nov 2006 19:48:27 -0000 Received: from unknown (HELO localhost) (775067@[217.50.200.64]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 19:48:27 -0000 Date: Sun, 12 Nov 2006 20:48:12 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061112204812.011e06d1@localhost> In-Reply-To: <20061112170013.78949e96@localhost> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_+Wa8aD=F+/nt467bMoUIE4s"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 19:48:41 -0000 --Sig_+Wa8aD=F+/nt467bMoUIE4s Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Andre Oppermann wrote: > > Please try this patch: > >=20 > > http://people.freebsd.org/~andre/sendfile_fix-20061112.diff > >=20 > > It fixes apache 2.0.59 for me. >=20 > For me too, but I'm still seeing problems with Gatling/0.8. I just had to reboot the system and noticed several LORs before the login prompt. Because of this one: lock order reversal: 1st 0xc070b6a8 Giant (sleep mutex) @ /usr/src/sys/kern/uipc_syscalls.c:1335 2nd 0xc27e5b10 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:1120 3rd 0xc27e30e0 so_snd (sleep mutex) @ /usr/src/sys/kern/uipc_sockbuf.c:95 KDB: stack backtrace: db_trace_self_wrapper(c069ae0c) at db_trace_self_wrapper+0x25 kdb_backtrace(0,0,c071a380,c071a060,c06d24c4,...) at kdb_backtrace+0x29 witness_checkorder(c27e30e0,9,c069fc63,5f) at witness_checkorder+0x586 _mtx_lock_flags(c27e30e0,0,c069fc63,5f,c27e5b10,...) at _mtx_lock_flags+0x84 socantsendmore(c27e3000,c27e5b10,0,c06a78e3,460,...) at socantsendmore+0x1d udp_shutdown(c27e3000,0,d4b01d04,c2662700,d4b01c84,...) at udp_shutdown+0x3a soshutdown(c27e3000,2,c2776af8,0,c2662700,...) at soshutdown+0x37 shutdown(c2662700,d4b01d04) at shutdown+0x5d syscall(b0003b,822003b,bfbf003b,bfbfc5d0,bfbfc6f0,...) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (134, FreeBSD ELF32, shutdown), eip =3D 0x2810a277, esp =3D 0xb= fbfc5bc, ebp =3D 0xbfbfc608 --- I assume there is a connection to your patch. For the rest of them please have a look at: http://www.fabiankeil.de/tmp/freebsd/dmesg-with-lors.txt Fabian --=20 http://www.fabiankeil.de/ --Sig_+Wa8aD=F+/nt467bMoUIE4s Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV3qBBYqIVf93VJ0RAp1NAJ4/22oWw3UaqyM+W2ZNsgAe1bsH4wCfXhEI 5OHfS5+NAEHT6z6cKlTimZE= =UFvT -----END PGP SIGNATURE----- --Sig_+Wa8aD=F+/nt467bMoUIE4s-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:19:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE10816A47E; Sun, 12 Nov 2006 20:19:33 +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 50B6543D60; Sun, 12 Nov 2006 20:19:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kACKJWmf040690; Sun, 12 Nov 2006 15:19:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kACKJWJd047604; Sun, 12 Nov 2006 15:19:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 42C9773068; Sun, 12 Nov 2006 15:19:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112201932.42C9773068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 15:19:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:19:34 -0000 TB --- 2006-11-12 19:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 19:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 19:50:00 - cleaning the object tree TB --- 2006-11-12 19:50:24 - checking out the source tree TB --- 2006-11-12 19:50:24 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 19:50:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 20:01:48 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 20:01:48 - cd /src TB --- 2006-11-12 20:01:48 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 20:01:49 UTC 2006 >>> 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 [...] cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 20:19:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 20:19:32 - ERROR: failed to build world TB --- 2006-11-12 20:19:32 - tinderbox aborted TB --- 0.24 user 0.59 system 1771.83 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:22:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C0B16A407; Sun, 12 Nov 2006 20:22:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B1B943DA8; Sun, 12 Nov 2006 20:21:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKLonu029896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:21:51 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4557825E.3070009@errno.com> Date: Sun, 12 Nov 2006 12:21:50 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: Ruslan Ermilov References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> In-Reply-To: <20061112192810.GC1173@rambler-co.ru> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, current@freebsd.org, Giorgos Keramidas Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:22:06 -0000 Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: >> GCC expects 4-byte aligned structured on ARM but does not necessarily >> have to. We can change the default at the expense of possible more >> inefficient code generated and lost binary compatibility with other ARM >> OSes out there. So this is trade off between unclear performance >> penalty and an unspecified but certainly sizable number of other >> landmines like this lurking on the code. >> >> We should decide what evil we regard as lesser. >> > This is the only buildworld problem so far on FreeBSD/ARM, so my > feeling is that we can actually benefit from leaving it "as is", > as it has a potential of making our code more portable. Of course > if binary compatibility for structs across platforms is an issue, > a structure should be "packed", because otherwise the C standard > says that "Each non-bit-field member of a structure or union object > is aligned in an implementation-defined manner appropriate to its > type." > > On the other hand, having GCC align "struct foo { char x[11]; }" > on a four-byte boundary (other than for backward compatibility) > doesn't make too much sense to me. > > I don't know GCC rules for alignment of structure members. For > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) > is always 1 for "struct foo { char foo; char bar; }" (without the > "packed" attribute) on all platforms and OSes GCC supports? > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately > it stays "1", i.e., only the structure alignment is affected, > and not of structure members (which is POLA but makes the 4 byte > for structure alignment questionable). This issue appears to have broken if_bridge. On my avila board I align rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. This results in the ethernet header being 2-byte aligned which is ok on other platforms. But the compiler takes this code in bridge_forward: /* * If the interface is learning, and the source * address is valid and not multicast, record * the address. */ if ((bif->bif_flags & IFBIF_LEARNING) != 0 && ETHER_IS_MULTICAST(eh->ether_shost) == 0 && (eh->ether_shost[0] == 0 && eh->ether_shost[1] == 0 && eh->ether_shost[2] == 0 && eh->ether_shost[3] == 0 && eh->ether_shost[4] == 0 && eh->ether_shost[5] == 0) == 0) { (void) bridge_rtupdate(sc, eh->ether_shost, src_if, 0, IFBAF_DYNAMIC); } and converts the 6 byte compares to a 32-bit and 16-bit compare. Since the data is only 16-bit aligned the 32-bit load faults. So the point is that just because things compile doesn't necessarily mean they work. And worse code that works on many/most other architectures may not work. Sam From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:23:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BA4E16A4D8 for ; Sun, 12 Nov 2006 20:23:52 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64ABF43E16 for ; Sun, 12 Nov 2006 20:23:33 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 02A6C140EC03; Sun, 12 Nov 2006 20:24:29 +0000 (GMT) Date: Sun, 12 Nov 2006 20:24:29 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20061112202429.GA66219@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: FreeBSD/sun4v install/live CD 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: Sun, 12 Nov 2006 20:23:52 -0000 Kip Macy's FreeBSD port to Sun's UltraSparc-T1 architecture has reached the stage where there is an install ISO containing a live file system. See -- John Birrell From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:48:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7340716A403 for ; Sun, 12 Nov 2006 20:48:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE87843DB3 for ; Sun, 12 Nov 2006 20:48:10 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.80] ([10.0.0.80]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKm7dJ030021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:48:08 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45578887.6010602@errno.com> Date: Sun, 12 Nov 2006 12:48:07 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Bruno Damour References: <4556F224.3050501@free.fr> In-Reply-To: <4556F224.3050501@free.fr> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wpa-psk help with output of ifconfig ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 20:48:30 -0000 Bruno Damour wrote: > Hello, > > I'm trying to debug some problems using WPA-PSK with ral driver. > Connection is often hanging after a while, network down. > netstat -r takes a very long time, ping doesnt respond, etc... > it works if I reset everything with netif restart. > > I saw a difference in the output of ifconfig that seems to be connected : > working state : > > ral0: flags=8843 mtu 1500 > inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 > inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:16:b6:5d:93:f9 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) > status: associated > ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 100 > bmiss 7 protmode CTS roaming MANUAL bintval 100 > > not working : > ral0: flags=8843 mtu 1500 > inet6 fe80::216:b6ff:fe5d:93f9%ral0 prefixlen 64 scopeid 0x2 > inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:16:b6:5d:93:f9 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) > status: associated > ssid ruomad channel 9 bssid 00:11:95:f0:8f:21 > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit > txpowmax 100 bmiss 7 protmode CTS roaming MANUAL bintval 100 > > The issue seems to be the TKIP 2:128-bit TKIP 3:128-bit (two items) when > prevously there was only one... > > Does anyone know what this output means ? The key change is just the WPA group key being re-issued by the AP. This happens periodically and/or when a new station joins the bss. If your network connection stalls then you need to identify what's going on. It's likely you lost connectivity to the ap. You can typically see this happen by monitoring debug output from wpa_supplicant (e.g. by supplying the -d option on the command line). Assuming you've just lost your association and are re-scanning you need to figure out why. There are tools and techniques for doing this (e.g. wlandebug can be used to enable debug msgs from the net80211 layer). Unfortunately the ral driver has no maintainer so resolving this may be difficult. Sam From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:58:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9855316A407 for ; Sun, 12 Nov 2006 20:58:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81EB943D4C for ; Sun, 12 Nov 2006 20:58:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79435 invoked from network); 12 Nov 2006 20:51:55 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 20:51:55 -0000 Message-ID: <45578B0E.5060809@freebsd.org> Date: Sun, 12 Nov 2006 21:58:54 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Pawel Worach References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, amistry@am-productions.biz Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 20:58:57 -0000 Pawel Worach wrote: > On 11/12/06, Andre Oppermann wrote: > >> Pawel Worach wrote: >> > Andre Oppermann wrote: >> > >> >> >> >> I'm looking into the problem. Please try a binary FTP transfer as >> well >> >> and check if the checksums match. ftpd uses sendfile(2) as well but >> w/o >> >> headers or trailers and does the send in one swoop. >> >> >> > >> > Oh, didn't think of that, ftpd is ok, transferring a 64MB file does not >> > trash it. Meanwhile a couple of other things where tested, SMP disabled >> > (removed from kernel config), added some printf's which when >> printing to >> > a serial console moves the offset where the breakage begins to >> > 0x01000000, sometimes. >> >> OK, I found the bug. The sent byte count reporting was incorrect. While >> doing the sendfile(2) rewrite I got lost in the mixup of the FreeBSD 4.x >> bug for bug compatibility. >> >> Please try this patch: >> >> http://people.freebsd.org/~andre/sendfile_fix-20061112.diff >> >> It fixes apache 2.0.59 for me. For some reason lighttpd didn't suffer >> from this problem, even w/o the fix. Unfortunately that's what I tested >> the rewrite against. >> > > This fixes it for me, thanks! Committed in rev. 1.244 of sys/kern/uipc_syscalls.c. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 21:09:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9BD16A415 for ; Sun, 12 Nov 2006 21:09:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9503B43D58 for ; Sun, 12 Nov 2006 21:09:35 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79552 invoked from network); 12 Nov 2006 21:02:33 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 21:02:33 -0000 Message-ID: <45578D8C.8020207@freebsd.org> Date: Sun, 12 Nov 2006 22:09:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Fabian Keil References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> In-Reply-To: <20061112170013.78949e96@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 21:09:39 -0000 Fabian Keil wrote: > Andre Oppermann wrote: > > >>Pawel Worach wrote: >> >>>Andre Oppermann wrote: >>> >>> >>>>I'm looking into the problem. Please try a binary FTP transfer as >>>>well and check if the checksums match. ftpd uses sendfile(2) as well >>>>but w/o headers or trailers and does the send in one swoop. >>>> >>> >>>Oh, didn't think of that, ftpd is ok, transferring a 64MB file does >>>not trash it. Meanwhile a couple of other things where tested, SMP >>>disabled (removed from kernel config), added some printf's which when >>>printing to a serial console moves the offset where the breakage >>>begins to 0x01000000, sometimes. >> >>OK, I found the bug. The sent byte count reporting was incorrect. While >>doing the sendfile(2) rewrite I got lost in the mixup of the FreeBSD 4.x >>bug for bug compatibility. >> >>Please try this patch: >> >> http://people.freebsd.org/~andre/sendfile_fix-20061112.diff >> >>It fixes apache 2.0.59 for me. > > > For me too, but I'm still seeing problems with Gatling/0.8. > > [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat-queues.png > pfstat-queues.png 78% of 5206 B 2706 kBps > fetch: pfstat-queues.png appears to be truncated: 4096/5206 bytes > [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat-queues.png > pfstat-queues.png 78% of 5206 B 1484 kBps > fetch: pfstat-queues.png appears to be truncated: 4096/5206 bytes > [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat.png > pfstat.png 83% of 4929 B 1881 kBps > fetch: pfstat.png appears to be truncated: 4096/4929 bytes > [fk@tor ~]$ fetch http://127.0.0.1:8000/pfstat.png > pfstat.png 83% of 4929 B 1777 kBps > fetch: pfstat.png appears to be truncated: 4096/4929 bytes > > PNG files always seem to be truncated after 4096 bytes, > the same files are delivered with Apache without problems. I'm sorry but I can't find out where gatling calls sendfile to inspect the parameters it uses. > This is on FreeBSD 7.0-CURRENT #20: Sun Nov 12 16:24:32 CET 2006 > with your patch and without Joe's one. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 16:59:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D699116A412; Sun, 12 Nov 2006 16:59:16 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id D379643D60; Sun, 12 Nov 2006 16:59:05 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjIfg-000GU4-BE; Sun, 12 Nov 2006 16:59:04 +0000 Date: Sun, 12 Nov 2006 16:59:04 +0000 From: Nicholas Clark To: Ruslan Ermilov Message-ID: <20061112165904.GP6501@plum.flirble.org> Mail-Followup-To: Ruslan Ermilov , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112155723.GB50349@rambler-co.ru> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark X-Mailman-Approved-At: Sun, 12 Nov 2006 22:01:57 +0000 Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:59:17 -0000 On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > So your sizeof() argument, well... I don't understand it and it > doesn't make things clearer at least to me. I still believe this > is bug in GCC that the alignment requirement is so high for a > "struct foo { char x; }" (there's no real reason for this!). It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to align (or pad) structures. The assumptions in the code you presented are not portable. The problem tends to be that ARM is the only common platform that does structure alignment this way, so tends to trip up a lot of code that has worked just fine in many other places. There is a lot more detail in http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html including how gcc's __packed__ extention can be used to tell gcc to align structures in different ways. Nicholas Clark From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 17:07:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE90916A407; Sun, 12 Nov 2006 17:07:22 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2417743D68; Sun, 12 Nov 2006 17:07:13 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjInX-000H6j-Lq; Sun, 12 Nov 2006 17:07:11 +0000 Date: Sun, 12 Nov 2006 17:07:11 +0000 From: Nicholas Clark To: Joseph Koshy Message-ID: <20061112170711.GQ6501@plum.flirble.org> Mail-Followup-To: Joseph Koshy , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark X-Mailman-Approved-At: Sun, 12 Nov 2006 22:02:11 +0000 Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:07:22 -0000 On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > GCC/arm also thinks that the alignment requirement for > `char a[1]' is `4', even though `sizeof(char a[1])` > remains at 1. > > This doesn't make sense at many levels. But is legal for an ANSI C compiler to do so. (As I understand it, the reason for the original ARM ABI on other operating systems choosing to do this alignment was because it was thought that word alignment even of arrays would generate faster code. I think that they now realise that actually this is not the case) I'm not following FreeBSD closely enough to know whether ARM has shipped as a released supported platform yet, but if not then I believe that FreeBSD is free to change its ARM ABI to anything that it feels more suitable. It may be worth talking to the ARM Linux folks to find out what they would have done differently in the ABI had they known. I suspect that the EABI described in http://wiki.debian.org/ArmEabiPort is based on previous pain. Has FreeBSD adopted the wonderful mixed endian IEEE 64 bit representation too? (Yep, that's legal. But catches a lot of code too) Nicholas Clark From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 22:38:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98F7316A47C for ; Sun, 12 Nov 2006 22:38:39 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0855143E15 for ; Sun, 12 Nov 2006 22:36:02 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 11605 invoked from network); 12 Nov 2006 22:35:33 -0000 Received: from unknown (HELO localhost) (775067@[217.50.200.64]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 22:35:33 -0000 Date: Sun, 12 Nov 2006 23:35:18 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061112233518.5f4752b5@localhost> In-Reply-To: <45578D8C.8020207@freebsd.org> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> <45578D8C.8020207@freebsd.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_ATVtY2eHHel8gAeCL1mx/ax"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 22:38:39 -0000 --Sig_ATVtY2eHHel8gAeCL1mx/ax Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Fabian Keil wrote: > > Andre Oppermann wrote: > >>OK, I found the bug. The sent byte count reporting was incorrect. > >>While doing the sendfile(2) rewrite I got lost in the mixup of the > >>FreeBSD 4.x bug for bug compatibility. > >> > >>Please try this patch: > >> > >> http://people.freebsd.org/~andre/sendfile_fix-20061112.diff > >> > >>It fixes apache 2.0.59 for me. > >=20 > >=20 > > For me too, but I'm still seeing problems with Gatling/0.8. > > PNG files always seem to be truncated after 4096 bytes, > > the same files are delivered with Apache without problems. >=20 > I'm sorry but I can't find out where gatling calls sendfile to inspect > the parameters it uses. I presume it's done through libowfat: [fk@tor /usr/jails/buildjail/usr/ports/devel/libowfat/work/libowfat-0.24]$ = grep -n sendfile\( *.c trybsdsf.c:18: r=3Dsendfile(0,1,37,42,&hdr,&sbytes,0); trysendfile.c:9: sbsize_t sendfile(int s, int fd, off_t offset, bsize_= t nbytes, trysendfile.c:18: sendfile(1 /* dest socket */,fd /* src file */, trysendfile.c:33: sendfile(1 /* dest */, 0 /* src */,&o,23 /* nbytes */); trysendfile.c:77: off_t r=3Dsendfile(1,fd,&o,23); Fabian --=20 http://www.fabiankeil.de/ --Sig_ATVtY2eHHel8gAeCL1mx/ax Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV6GrBYqIVf93VJ0RAhoAAKCDIDEkBK1kEop/fKGRui4L+h2QpwCfcJDW Fy2wvnYmLlJsNBUbrHcnA8s= =F5S4 -----END PGP SIGNATURE----- --Sig_ATVtY2eHHel8gAeCL1mx/ax-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 22:48:43 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B055B16A4A0; Sun, 12 Nov 2006 22:48:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B640D43D5E; Sun, 12 Nov 2006 22:48:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kACMkwDG081266; Sun, 12 Nov 2006 15:46:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 15:47:33 -0700 (MST) Message-Id: <20061112.154733.-432839119.imp@bsdimp.com> To: ru@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20061112192810.GC1173@rambler-co.ru> References: <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 15:46:58 -0700 (MST) Cc: arm@FreeBSD.org, current@FreeBSD.org, keramida@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 22:48:43 -0000 In message: <20061112192810.GC1173@rambler-co.ru> Ruslan Ermilov writes: : On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: : > GCC expects 4-byte aligned structured on ARM but does not necessarily : > have to. We can change the default at the expense of possible more : > inefficient code generated and lost binary compatibility with other ARM : > OSes out there. So this is trade off between unclear performance : > penalty and an unspecified but certainly sizable number of other : > landmines like this lurking on the code. : > : > We should decide what evil we regard as lesser. : > : This is the only buildworld problem so far on FreeBSD/ARM, so my : feeling is that we can actually benefit from leaving it "as is", : as it has a potential of making our code more portable. Of course : if binary compatibility for structs across platforms is an issue, : a structure should be "packed", because otherwise the C standard : says that "Each non-bit-field member of a structure or union object : is aligned in an implementation-defined manner appropriate to its : type." : : On the other hand, having GCC align "struct foo { char x[11]; }" : on a four-byte boundary (other than for backward compatibility) : doesn't make too much sense to me. It does for me. People shouldn't think of structs as being packed. The standard is very clear about the allowed type punning and the disallowed. Many platforms pad structures to the size of a word, and we have to cope. In this specific case, it should be __packed__ because the structure is intended to be packed. : I don't know GCC rules for alignment of structure members. For : example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) : is always 1 for "struct foo { char foo; char bar; }" (without the : "packed" attribute) on all platforms and OSes GCC supports? : I'd expect the latter to be "4" for FreeBSD/ARM but fortunately : it stays "1", i.e., only the structure alignment is affected, : and not of structure members (which is POLA but makes the 4 byte : for structure alignment questionable). It is all up to the compiler. Trying to figure it out is not possible. There's no POLA to violate, unless you expect the whole world to behave like a i386 :-). Warner From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:07:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 199B616A415; Sun, 12 Nov 2006 23:07:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F8143D8C; Sun, 12 Nov 2006 23:06:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kACN5313081507; Sun, 12 Nov 2006 16:05:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 16:05:39 -0700 (MST) Message-Id: <20061112.160539.-1350496508.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <4557825E.3070009@errno.com> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 16:05:04 -0700 (MST) Cc: arm@freebsd.org, current@freebsd.org, keramida@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:07:00 -0000 In message: <4557825E.3070009@errno.com> Sam Leffler writes: : Ruslan Ermilov wrote: : > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: : >> GCC expects 4-byte aligned structured on ARM but does not necessarily : >> have to. We can change the default at the expense of possible more : >> inefficient code generated and lost binary compatibility with other ARM : >> OSes out there. So this is trade off between unclear performance : >> penalty and an unspecified but certainly sizable number of other : >> landmines like this lurking on the code. : >> : >> We should decide what evil we regard as lesser. : >> : > This is the only buildworld problem so far on FreeBSD/ARM, so my : > feeling is that we can actually benefit from leaving it "as is", : > as it has a potential of making our code more portable. Of course : > if binary compatibility for structs across platforms is an issue, : > a structure should be "packed", because otherwise the C standard : > says that "Each non-bit-field member of a structure or union object : > is aligned in an implementation-defined manner appropriate to its : > type." : > : > On the other hand, having GCC align "struct foo { char x[11]; }" : > on a four-byte boundary (other than for backward compatibility) : > doesn't make too much sense to me. : > : > I don't know GCC rules for alignment of structure members. For : > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) : > is always 1 for "struct foo { char foo; char bar; }" (without the : > "packed" attribute) on all platforms and OSes GCC supports? : > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately : > it stays "1", i.e., only the structure alignment is affected, : > and not of structure members (which is POLA but makes the 4 byte : > for structure alignment questionable). : : This issue appears to have broken if_bridge. On my avila board I align : rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. : This results in the ethernet header being 2-byte aligned which is ok on : other platforms. But the compiler takes this code in bridge_forward: : : /* : * If the interface is learning, and the source : * address is valid and not multicast, record : * the address. : */ : if ((bif->bif_flags & IFBIF_LEARNING) != 0 && : ETHER_IS_MULTICAST(eh->ether_shost) == 0 && : (eh->ether_shost[0] == 0 && : eh->ether_shost[1] == 0 && : eh->ether_shost[2] == 0 && : eh->ether_shost[3] == 0 && : eh->ether_shost[4] == 0 && : eh->ether_shost[5] == 0) == 0) { : (void) bridge_rtupdate(sc, eh->ether_shost, : src_if, 0, IFBAF_DYNAMIC); : } : : and converts the 6 byte compares to a 32-bit and 16-bit compare. Since : the data is only 16-bit aligned the 32-bit load faults. Yea, that's clearly bogus of it. It does this because it thinks that eh is going to be 4-byte aligned, which it isn't in this case. I think that we may need to change: /* * Structure of a 10Mb/s Ethernet header. */ struct ether_header { u_char ether_dhost[ETHER_ADDR_LEN]; u_char ether_shost[ETHER_ADDR_LEN]; u_short ether_type; }; to be struct ether_header { u_char ether_dhost[ETHER_ADDR_LEN]; u_char ether_shost[ETHER_ADDR_LEN]; u_short ether_type; } __packed; since that would fit. There's one caveat that I'd caution people about. NetBSD had lots of issues with gcc4 and packed when the struct doesn't need to be packed. But, I must say, that they do flag these as packed: /* * Ethernet address - 6 octets * this is only used by the ethers(3) functions. */ struct ether_addr { u_int8_t ether_addr_octet[ETHER_ADDR_LEN]; } __attribute__((__packed__)); /* * Structure of a 10Mb/s Ethernet header. */ struct ether_header { u_int8_t ether_dhost[ETHER_ADDR_LEN]; u_int8_t ether_shost[ETHER_ADDR_LEN]; u_int16_t ether_type; } __attribute__((__packed__)); (note: in FreeBSD we have #define in sys/cdefs.h: #define __packed __attribute__((__packed__)) ) : So the point is that just because things compile doesn't necessarily : mean they work. And worse code that works on many/most other : architectures may not work. I've fought this same issue in the boot code (look at boot2 for how I worked around it). The arm really really hates unaligned accesses... Warner From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:07:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id F12B416A4AB; Sun, 12 Nov 2006 23:07:16 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Mon, 13 Nov 2006 07:07:09 +0800 User-Agent: KMail/1.8.2 References: <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> In-Reply-To: <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611130707.10220.davidxu@freebsd.org> Cc: Chris Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2006 23:07:18 -0000 On Sunday 12 November 2006 07:03, Chris wrote: > On 10/11/06, Nikolay Pavlov wrote: > > Hi. In this post i am not trying to raise a discussion about teoretical > > advantages of some special threading model, but still i would like to > > figure out why libthr in it current state is not our default posix > > thread library and could it be so in time of 7-STABLE? > > > > As a user and administrator of FreeBSD i want to mention some benefits > > of libthr: > > > > 1. It's simpler. > > 2. It's stable and has been used by many of us for a long time. > > 3. It proved to be very productive on real world applications. > > 4. It has active talented developers. > > 5. If it was a default library it would couse a incrase of users > > feedback which would lead to futher improvement of it's code by the time > > 7 becomes a stable branch. > > > > And some flaws of libpthread: > > > > 1. It's more difficult. > > 2. It's slow in compare of libthr. > > 3. The last, but the worst. IMHO the position under which libpthread is > > the library by default is the source of a bad myth that threading model > > in FreeBSD sucks and threading applications is slow. If 7.0 had libthr > > as a default posix threads library we could brake that belief. > > > > This point of view may seem one-sided that is why someone with good > > knowledge of the current state of code could tell other pros and cons > > of both libraries. > > > > Another interesting question is which of the libraries will better work > > with multikernel and multiprocessor systems which will be very popular > > by the time 7.0 branch launches its stable releases. > > > > -- > > ====================================================================== > > - Best regards, Nikolay Pavlov. <<<----------------------------------- > > ====================================================================== > > HI I posted in another thread about how my own experiences seem to > differ from all these benchmarks, they are based on 3 heavily loaded > web/mysql servers. > > One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd > 6.1 and 3rd is another dual xeon freebsd 6.1. > > All 3 of these machines perform better as well as more stable under > higher loads using libpthread process scope. > > System scope appears to make mysql hog the system and everything slows > down except of course mysql. > > Libthr appears to make mysql very sporadic with some requests fast > others with a unexplained 5-10 sec delay including timeouts. > > Process scope on libpthread gives me the best results not making mysql > starve the server of resources and it has a consistent response time > of under 2 seconds under hevay loads. libthr on FreeBSD 6.1 respects process scope, if your mysql is compiled with process scope, it will use it, this is only removed in -CURRENT, I don't know why you said that it starved server resource if KSEGRP really works as expected. > > I cant explain other then it maybe that test mysql data isnt a proper > way to test these threading libraries only real work loads can. > > Chris > _______________________________________________ > 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 Nov 12 23:21:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E63116A407; Sun, 12 Nov 2006 23:21:13 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD9843D70; Sun, 12 Nov 2006 23:21:05 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kACNYZud012922; Mon, 13 Nov 2006 00:34:35 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kACNYYmR012921; Mon, 13 Nov 2006 00:34:34 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 00:34:34 +0100 From: Olivier Houchard To: Nicholas Clark Message-ID: <20061112233434.GA12739@ci0.org> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112170711.GQ6501@plum.flirble.org> User-Agent: Mutt/1.4.1i Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:21:13 -0000 On Sun, Nov 12, 2006 at 05:07:11PM +0000, Nicholas Clark wrote: > On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > > > GCC/arm also thinks that the alignment requirement for > > `char a[1]' is `4', even though `sizeof(char a[1])` > > remains at 1. > > > > This doesn't make sense at many levels. > > But is legal for an ANSI C compiler to do so. > (As I understand it, the reason for the original ARM ABI on other operating > systems choosing to do this alignment was because it was thought that word > alignment even of arrays would generate faster code. I think that they now > realise that actually this is not the case) > > I'm not following FreeBSD closely enough to know whether ARM has shipped as > a released supported platform yet, but if not then I believe that FreeBSD > is free to change its ARM ABI to anything that it feels more suitable. > > It may be worth talking to the ARM Linux folks to find out what they would > have done differently in the ABI had they known. I suspect that the EABI > described in http://wiki.debian.org/ArmEabiPort is based on previous pain. > > Has FreeBSD adopted the wonderful mixed endian IEEE 64 bit representation too? > (Yep, that's legal. But catches a lot of code too) > > Nicholas Clark It was my choice to align structures on a word boundary, because of what you pointed, and because of that little comment in gcc/config/arm/netbsd-elf.h : 2. A potential performance penalty may exist if strings are no longer word aligned. GCC will not be able to use word load/stores to copy short strings. I may just not have given enough though to the issue, if the EABI folks chose to switch from word-aligned to no restriction, they certainly have their reasons. I consider we can still do the switch if we should, it will force people to rebuild all their arm apps, but for now as far as I know all users of FreeBSD/arm are FreeBSD developers, so a heads up should be enough. It has to be done now, however. No, we're not using the mixed endian IEEE 64bits representation. We're defaulting to softfloat VFP. What would be te point of switching ? Cheers, Olivier From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:31:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63D0316A4F8; Sun, 12 Nov 2006 23:31:40 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDF1B43DEA; Sun, 12 Nov 2006 23:30:37 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kACNiCPP013043; Mon, 13 Nov 2006 00:44:12 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kACNiC6T013042; Mon, 13 Nov 2006 00:44:12 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 00:44:12 +0100 From: Olivier Houchard To: Nicholas Clark Message-ID: <20061112234412.GA12998@ci0.org> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> <20061112233434.GA12739@ci0.org> <20061112232742.GU6501@plum.flirble.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112232742.GU6501@plum.flirble.org> User-Agent: Mutt/1.4.1i Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:31:40 -0000 On Sun, Nov 12, 2006 at 11:27:42PM +0000, Nicholas Clark wrote: > On Mon, Nov 13, 2006 at 12:34:34AM +0100, Olivier Houchard wrote: > > > No, we're not using the mixed endian IEEE 64bits representation. We're > > defaulting to softfloat VFP. What would be te point of switching ? > > >From my limited understanding of these things (mostly observing on the > ARM Linux lists) absolutely none. The mixed endian IEEE representation > is a complete pain, I'm unaware of any reason why it was chosen over a > conventional little endian representation (probably back some time in > 1987). > I thought so :) I think FPA is used for historical reasons, because that's what some older arm cpus used when they had a FPU. And of course using a kernel FPE was a great idea for linux too. Olivier From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:31:52 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A19D216A4D2; Sun, 12 Nov 2006 23:31:52 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7894243E2A; Sun, 12 Nov 2006 23:31:02 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 2F02560B9; Mon, 13 Nov 2006 02:30:55 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 43EAA5D3B; Mon, 13 Nov 2006 02:28:50 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACNSshA048101; Mon, 13 Nov 2006 02:28:54 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 02:28:54 +0300 From: Ruslan Ermilov To: "M. Warner Losh" , Joseph Koshy Message-ID: <20061112232854.GC45238@rambler-co.ru> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> <20061112.160539.-1350496508.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <20061112.160539.-1350496508.imp@bsdimp.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, keramida@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:31:52 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:05:39PM -0700, M. Warner Losh wrote: > Yea, that's clearly bogus of it. It does this because it thinks that > eh is going to be 4-byte aligned, which it isn't in this case. I > think that we may need to change: >=20 > /* > * Structure of a 10Mb/s Ethernet header. > */ > struct ether_header { > u_char ether_dhost[ETHER_ADDR_LEN]; > u_char ether_shost[ETHER_ADDR_LEN]; > u_short ether_type; > }; >=20 > to be >=20 > struct ether_header { > u_char ether_dhost[ETHER_ADDR_LEN]; > u_char ether_shost[ETHER_ADDR_LEN]; > u_short ether_type; > } __packed; >=20 > since that would fit. >=20 "fit" =3D=3D avoid 32-bit loads (I've similarly checked adding __packed to "struct ar_hdr" here, and it indeed stops using 32-bit loads instructions now): %%% Index: ar.h =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/include/ar.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 ar.h --- ar.h 24 May 1994 09:57:26 -0000 1.1.1.1 +++ ar.h 12 Nov 2006 23:26:38 -0000 @@ -44,6 +44,8 @@ #ifndef _AR_H_ #define _AR_H_ =20 +#include + /* Pre-4BSD archives had these magic numbers in them. */ #define OARMAG1 0177555 #define OARMAG2 0177545 @@ -62,6 +64,6 @@ struct ar_hdr { char ar_size[10]; /* size in bytes */ #define ARFMAG "`\n" char ar_fmag[2]; /* consistency check */ -}; +} __packed; =20 #endif /* !_AR_H_ */ %%% > There's one caveat that I'd caution people about. NetBSD had lots of > issues with gcc4 and packed when the struct doesn't need to be packed. >=20 We don't have a lot of packed structs yet, and we should certainly have more of them. :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --MW5yreqqjyrRcusr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV642qRfpzJluFF4RAvxsAJsHxNw7Xu078RVRV7gZUGmpWnvSaACfbZ5G psteO64afQgekuYrzw6kJu8= =MhYA -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:38:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F5016A4D0; Sun, 12 Nov 2006 23:38:28 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B867443D8E; Sun, 12 Nov 2006 23:38:08 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C809E5E07; Mon, 13 Nov 2006 02:38:02 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 8D8FC5DF3; Mon, 13 Nov 2006 02:38:02 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACNc7fN049795; Mon, 13 Nov 2006 02:38:07 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 02:38:07 +0300 From: Ruslan Ermilov To: Sam Leffler Message-ID: <20061112233806.GD45238@rambler-co.ru> References: <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <4557825E.3070009@errno.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:38:28 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 12:21:50PM -0800, Sam Leffler wrote: > Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: > >> GCC expects 4-byte aligned structured on ARM but does not necessarily > >> have to. We can change the default at the expense of possible more > >> inefficient code generated and lost binary compatibility with other ARM > >> OSes out there. So this is trade off between unclear performance > >> penalty and an unspecified but certainly sizable number of other > >> landmines like this lurking on the code. > >> > >> We should decide what evil we regard as lesser. > >> > > This is the only buildworld problem so far on FreeBSD/ARM, so my > > feeling is that we can actually benefit from leaving it "as is", > > as it has a potential of making our code more portable. Of course > > if binary compatibility for structs across platforms is an issue, > > a structure should be "packed", because otherwise the C standard > > says that "Each non-bit-field member of a structure or union object > > is aligned in an implementation-defined manner appropriate to its > > type." > >=20 > > On the other hand, having GCC align "struct foo { char x[11]; }" > > on a four-byte boundary (other than for backward compatibility) > > doesn't make too much sense to me. > >=20 > > I don't know GCC rules for alignment of structure members. For > > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) > > is always 1 for "struct foo { char foo; char bar; }" (without the > > "packed" attribute) on all platforms and OSes GCC supports? > > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately > > it stays "1", i.e., only the structure alignment is affected, > > and not of structure members (which is POLA but makes the 4 byte > > for structure alignment questionable). >=20 > This issue appears to have broken if_bridge. On my avila board I align > rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. > This results in the ethernet header being 2-byte aligned which is ok on > other platforms. But the compiler takes this code in bridge_forward: >=20 > /* > * If the interface is learning, and the source > * address is valid and not multicast, record > * the address. > */ > if ((bif->bif_flags & IFBIF_LEARNING) !=3D 0 && > ETHER_IS_MULTICAST(eh->ether_shost) =3D=3D 0 && > (eh->ether_shost[0] =3D=3D 0 && > eh->ether_shost[1] =3D=3D 0 && > eh->ether_shost[2] =3D=3D 0 && > eh->ether_shost[3] =3D=3D 0 && > eh->ether_shost[4] =3D=3D 0 && > eh->ether_shost[5] =3D=3D 0) =3D=3D 0) { > (void) bridge_rtupdate(sc, eh->ether_shost, > src_if, 0, IFBAF_DYNAMIC); > } >=20 > and converts the 6 byte compares to a 32-bit and 16-bit compare. Since > the data is only 16-bit aligned the 32-bit load faults. >=20 > So the point is that just because things compile doesn't necessarily > mean they work. And worse code that works on many/most other > architectures may not work. >=20 No, this is only because our kernels are compiled without -Wcast-align. Otherwise it notices that mtod() casts "char *" into "struct ether_header *= ": $ pwd =20 /home/ru/w/freebsd/src/sys/modules/if_bridge $ make WARNS=3D6 2>&1 |grep -A1 forward /home/ru/w/freebsd/src/sys/modules/if_bridge/../../net/if_bridge.c: In func= tion `bridge_forward': /home/ru/w/freebsd/src/sys/modules/if_bridge/../../net/if_bridge.c:1888: wa= rning: cast increases required alignment of target type Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --E13BgyNx05feLLmH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV7BeqRfpzJluFF4RAkKgAJ983jddAbAprxVnOPJiouzXozTMmwCaAjGN n1Mu+nBMZUMsWhyS8loG/cI= =EgaF -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 23:28:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73F416A47E; Sun, 12 Nov 2006 23:28:06 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0734543DBA; Sun, 12 Nov 2006 23:27:54 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjOjm-000KAE-I5; Sun, 12 Nov 2006 23:27:42 +0000 Date: Sun, 12 Nov 2006 23:27:42 +0000 From: Nicholas Clark To: Olivier Houchard Message-ID: <20061112232742.GU6501@plum.flirble.org> Mail-Followup-To: Olivier Houchard , Joseph Koshy , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> <20061112233434.GA12739@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112233434.GA12739@ci0.org> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark X-Mailman-Approved-At: Sun, 12 Nov 2006 23:59:29 +0000 Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:28:07 -0000 On Mon, Nov 13, 2006 at 12:34:34AM +0100, Olivier Houchard wrote: > No, we're not using the mixed endian IEEE 64bits representation. We're > defaulting to softfloat VFP. What would be te point of switching ? >From my limited understanding of these things (mostly observing on the ARM Linux lists) absolutely none. The mixed endian IEEE representation is a complete pain, I'm unaware of any reason why it was chosen over a conventional little endian representation (probably back some time in 1987). Nicholas Clark From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 00:19:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 408F516A407 for ; Mon, 13 Nov 2006 00:19:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B26543D45 for ; Mon, 13 Nov 2006 00:19:57 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 9841 invoked from network); 13 Nov 2006 00:19:54 -0000 Received: from unknown (HELO localhost) (775067@[217.50.200.64]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 13 Nov 2006 00:19:54 -0000 Date: Mon, 13 Nov 2006 01:19:41 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061113011941.1ab10f39@localhost> In-Reply-To: <20061112204812.011e06d1@localhost> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> <20061112204812.011e06d1@localhost> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_47//Cpcga0l=Z+mfRDXDini"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 00:19:58 -0000 --Sig_47//Cpcga0l=Z+mfRDXDini Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Fabian Keil wrote: >=20 > > Andre Oppermann wrote: >=20 > > > Please try this patch: > > >=20 > > > http://people.freebsd.org/~andre/sendfile_fix-20061112.diff > I just had to reboot the system and noticed several LORs before > the login prompt. Because of this one: >=20 > lock order reversal: > 1st 0xc070b6a8 Giant (sleep mutex) > @ /usr/src/sys/kern/uipc_syscalls.c:1335 2nd 0xc27e5b10 inp (udpinp) > @ /usr/src/sys/netinet/udp_usrreq.c:1120 3rd 0xc27e30e0 so_snd (sleep > mutex) @ /usr/src/sys/kern/uipc_sockbuf.c:95 KDB: stack backtrace: > db_trace_self_wrapper(c069ae0c) at db_trace_self_wrapper+0x25 > kdb_backtrace(0,0,c071a380,c071a060,c06d24c4,...) at kdb_backtrace+0x29 > witness_checkorder(c27e30e0,9,c069fc63,5f) at witness_checkorder+0x586 > _mtx_lock_flags(c27e30e0,0,c069fc63,5f,c27e5b10,...) at > _mtx_lock_flags+0x84 > socantsendmore(c27e3000,c27e5b10,0,c06a78e3,460,...) at > socantsendmore+0x1d > udp_shutdown(c27e3000,0,d4b01d04,c2662700,d4b01c84,...) at > udp_shutdown+0x3a soshutdown(c27e3000,2,c2776af8,0,c2662700,...) at > soshutdown+0x37 shutdown(c2662700,d4b01d04) at shutdown+0x5d > syscall(b0003b,822003b,bfbf003b,bfbfc5d0,bfbfc6f0,...) at syscall+0x256 > Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (134, FreeBSD > ELF32, shutdown), eip =3D 0x2810a277, esp =3D 0xbfbfc5bc, ebp =3D 0xbfbfc= 608 > --- >=20 > I assume there is a connection to your patch. As I'm still getting these without Andre's patch they must be the result of some other changes. Fabian --=20 http://www.fabiankeil.de/ --Sig_47//Cpcga0l=Z+mfRDXDini Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV7oiBYqIVf93VJ0RAoEnAJ45ZzHkul+HOEo8SzGPH7ao24ULNwCgyYZ7 M98+XMnXQDQk1DEbeuuIySE= =rK1x -----END PGP SIGNATURE----- --Sig_47//Cpcga0l=Z+mfRDXDini-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 02:10:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7077016A40F; Mon, 13 Nov 2006 02:10:47 +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 5CED543D67; Mon, 13 Nov 2006 02:10:46 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.221] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id kAD2Ak24079878; Sun, 12 Nov 2006 18:10:46 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4557D425.40101@freebsd.org> Date: Sun, 12 Nov 2006 18:10:45 -0800 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 References: <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <20061112.154733.-432839119.imp@bsdimp.com> In-Reply-To: <20061112.154733.-432839119.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, current@freebsd.org, keramida@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 02:10:47 -0000 In message: <20061112192810.GC1173@rambler-co.ru> Ruslan Ermilov writes: : On the other hand, having GCC align "struct foo { char x[11]; }" : on a four-byte boundary (other than for backward compatibility) : doesn't make too much sense to me. It makes a lot of sense, actually, even on i386, which is why the standard allows the compiler a lot of leeway to pad and align such structure. For example, consider this structure assignment: struct foo a,b; a = b; The structure copy here is a LOT faster if the structures are always suitably aligned and padded. If the compiler pads your sample struct to 12 bytes and 4-aligns, the structure copy here can be done with 3 aligned 32-bit moves. Even on i386, aligned operations are a lot faster than unaligned ones. The code mentioned in the original post is simply broken; it does not comply with the ISO C Standard. Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 02:59:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD7DB16A412; Mon, 13 Nov 2006 02:59:40 +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 57C9943D58; Mon, 13 Nov 2006 02:59:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAD2xdwF063610; Sun, 12 Nov 2006 21:59:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD2xduE012787; Sun, 12 Nov 2006 21:59:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5386E73068; Sun, 12 Nov 2006 21:59:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061113025939.5386E73068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 21:59:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 02:59:41 -0000 TB --- 2006-11-13 02:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-13 02:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-13 02:30:00 - cleaning the object tree TB --- 2006-11-13 02:30:22 - checking out the source tree TB --- 2006-11-13 02:30:22 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-13 02:30:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-13 02:41:50 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-13 02:41:50 - cd /src TB --- 2006-11-13 02:41:50 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 13 02:41:52 UTC 2006 >>> 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 [...] cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -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 -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-13 02:59:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-13 02:59:39 - ERROR: failed to build world TB --- 2006-11-13 02:59:39 - tinderbox aborted TB --- 0.17 user 0.64 system 1778.32 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 04:26:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DEB416A40F for ; Mon, 13 Nov 2006 04:26:43 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6CF543D58 for ; Mon, 13 Nov 2006 04:26:42 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so668318nzh for ; Sun, 12 Nov 2006 20:26:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gBa7wMMQKTfDb8L/Lb2WicPqtgIYrwsYflFU8f21+yCtoHisIb9kVDLE0OgEcdrPx7G4RNw8d8nrEMWAYM1a8NRF/dJzLYQJ9hnsMauyz0Xa5B2eATkX12MZJ7602pzXAgBGgyrWzNokyaNy1jlj1pxPkIYEIqf+TPtcf7Uz/4k= Received: by 10.35.10.17 with SMTP id n17mr8886642pyi.1163391610009; Sun, 12 Nov 2006 20:20:10 -0800 (PST) Received: by 10.35.29.20 with HTTP; Sun, 12 Nov 2006 20:20:09 -0800 (PST) Message-ID: <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com> Date: Mon, 13 Nov 2006 04:20:09 +0000 From: Chris To: "David Xu" In-Reply-To: <200611130707.10220.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> <200611130707.10220.davidxu@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 04:26:43 -0000 On 12/11/06, David Xu wrote: > On Sunday 12 November 2006 07:03, Chris wrote: > > On 10/11/06, Nikolay Pavlov wrote: > > > Hi. In this post i am not trying to raise a discussion about teoretical > > > advantages of some special threading model, but still i would like to > > > figure out why libthr in it current state is not our default posix > > > thread library and could it be so in time of 7-STABLE? > > > > > > As a user and administrator of FreeBSD i want to mention some benefits > > > of libthr: > > > > > > 1. It's simpler. > > > 2. It's stable and has been used by many of us for a long time. > > > 3. It proved to be very productive on real world applications. > > > 4. It has active talented developers. > > > 5. If it was a default library it would couse a incrase of users > > > feedback which would lead to futher improvement of it's code by the time > > > 7 becomes a stable branch. > > > > > > And some flaws of libpthread: > > > > > > 1. It's more difficult. > > > 2. It's slow in compare of libthr. > > > 3. The last, but the worst. IMHO the position under which libpthread is > > > the library by default is the source of a bad myth that threading model > > > in FreeBSD sucks and threading applications is slow. If 7.0 had libthr > > > as a default posix threads library we could brake that belief. > > > > > > This point of view may seem one-sided that is why someone with good > > > knowledge of the current state of code could tell other pros and cons > > > of both libraries. > > > > > > Another interesting question is which of the libraries will better work > > > with multikernel and multiprocessor systems which will be very popular > > > by the time 7.0 branch launches its stable releases. > > > > > > -- > > > ====================================================================== > > > - Best regards, Nikolay Pavlov. <<<----------------------------------- > > > ====================================================================== > > > > HI I posted in another thread about how my own experiences seem to > > differ from all these benchmarks, they are based on 3 heavily loaded > > web/mysql servers. > > > > One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd > > 6.1 and 3rd is another dual xeon freebsd 6.1. > > > > All 3 of these machines perform better as well as more stable under > > higher loads using libpthread process scope. > > > > System scope appears to make mysql hog the system and everything slows > > down except of course mysql. > > > > Libthr appears to make mysql very sporadic with some requests fast > > others with a unexplained 5-10 sec delay including timeouts. > > > > Process scope on libpthread gives me the best results not making mysql > > starve the server of resources and it has a consistent response time > > of under 2 seconds under hevay loads. > libthr on FreeBSD 6.1 respects process scope, if your mysql is compiled > with process scope, it will use it, this is only removed in -CURRENT, > I don't know why you said that it starved server resource if KSEGRP > really works as expected. > > > > > I cant explain other then it maybe that test mysql data isnt a proper > > way to test these threading libraries only real work loads can. > > > > Chris > > _______________________________________________ Interesting libthr can use system or process scope? as far as I am aware it was using whatever the default is for libthr. Chris From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 04:30:37 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5419E16A403 for ; Mon, 13 Nov 2006 04:30:37 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from omta01ps.mx.bigpond.com (omta01ps.mx.bigpond.com [144.140.82.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B6AE43D46 for ; Mon, 13 Nov 2006 04:30:36 +0000 (GMT) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta01ps.mx.bigpond.com ([141.168.2.3]) by omta01ps.mx.bigpond.com with ESMTP id <20061113043035.EMMZ24786.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com> for ; Mon, 13 Nov 2006 04:30:35 +0000 Received: from areilly.bpa.nu ([141.168.2.3]) by oaamta01ps.mx.bigpond.com with ESMTP id <20061113043035.CISZ13696.oaamta01ps.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 13 Nov 2006 04:30:35 +0000 Received: (qmail 80213 invoked by uid 501); 13 Nov 2006 04:27:29 -0000 Date: Mon, 13 Nov 2006 15:27:29 +1100 From: Andrew Reilly To: Ruslan Ermilov Message-ID: <20061113042729.GA79796@duncan.reilly.home> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> <20061112.160539.-1350496508.imp@bsdimp.com> <20061112232854.GC45238@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112232854.GC45238@rambler-co.ru> User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Mon, 13 Nov 2006 05:23:16 +0000 Cc: current@FreeBSD.org, Joseph Koshy , keramida@FreeBSD.org, arm@FreeBSD.org, "M. Warner Losh" Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 04:30:37 -0000 On Mon, Nov 13, 2006 at 02:28:54AM +0300, Ruslan Ermilov wrote: > We don't have a lot of packed structs yet, and we should certainly > have more of them. :-) Well, packed structs is one (non-portable) way to work around the fact that C doesn't really support the use of structs for parsing external (wire, file) data structures. They're internal-use, abstract devices. If you want the code to be portable now and into the future, then you'll use accessor macros that access the byte-stream explicitly, to build larger data types. Won't even have to do anything special for endian-compatability, that way. Yes, I realize that that's not the /traditional way/, and that there's a hell of a lot of inappropriate struct code in there. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 09:01:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C471716A47B; Mon, 13 Nov 2006 09:01:30 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org Date: Mon, 13 Nov 2006 17:01:25 +0800 User-Agent: KMail/1.8.2 References: <20061110151247.GA64530@zone3000.net> <200611130707.10220.davidxu@freebsd.org> <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com> In-Reply-To: <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611131701.25572.davidxu@freebsd.org> Cc: Chris Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 09:01:31 -0000 On Monday 13 November 2006 12:20, Chris wrote: > > Interesting libthr can use system or process scope? as far as I am > aware it was using whatever the default is for libthr. > > Chris FreeBSD 6.1, the default is libthr uses process scope, but I know mysql explicitly uses system scope thread unless you forced it to use process scope(there is a knob in the ports's Makefile). if the mysql uses system scope (the default), you should see the same effect with libpthread, i.e you said it starved your server. David Xu From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 10:23:28 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DB1B16A412 for ; Mon, 13 Nov 2006 10:23:28 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from mx28.mail.ru (mx28.mail.ru [194.67.23.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9724243D90 for ; Mon, 13 Nov 2006 10:23:16 +0000 (GMT) (envelope-from samspeed@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.64]) by mx28.mail.ru (mPOP.Fallback_MX) with ESMTP id C16B27166C1 for ; Mon, 13 Nov 2006 11:31:38 +0300 (MSK) Received: from [80.82.44.194] (port=55759 helo=[192.168.168.7]) by mx27.mail.ru with asmtp id 1GjXE0-000CPD-00 for current@FreeBSD.org; Mon, 13 Nov 2006 11:31:28 +0300 Message-ID: <45582D3E.1060305@mail.ru> Date: Mon, 13 Nov 2006 11:30:54 +0300 From: Andrey Smagin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Hard reset on amd64 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, 13 Nov 2006 10:23:28 -0000 Hi. If I copy files from PC1 to PC2 via NFS, PC1 - cold rebooted after copying some KBytes of file. If copying via Smb protocol or from PC2 to PC1 via NFS - all success. PC1 - Current(GENERIC 5 days ago), AMD64. PC2 - Current(GENERIC, 1-2 week ago), i386. From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 11:16:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C55616A49E for ; Mon, 13 Nov 2006 11:16:33 +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 DFD1E43D70 for ; Mon, 13 Nov 2006 11:16:24 +0000 (GMT) (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 98F1D46C37; Mon, 13 Nov 2006 06:16:24 -0500 (EST) Date: Mon, 13 Nov 2006 11:16:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Fabian Keil In-Reply-To: <20061112204812.011e06d1@localhost> Message-ID: <20061113111138.Q38359@fledge.watson.org> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> <20061112204812.011e06d1@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 11:16:33 -0000 On Sun, 12 Nov 2006, Fabian Keil wrote: > Fabian Keil wrote: > >> Andre Oppermann wrote: > >>> Please try this patch: >>> >>> http://people.freebsd.org/~andre/sendfile_fix-20061112.diff >>> >>> It fixes apache 2.0.59 for me. >> >> For me too, but I'm still seeing problems with Gatling/0.8. > > I just had to reboot the system and noticed several LORs before > the login prompt. Because of this one: > > lock order reversal: > 1st 0xc070b6a8 Giant (sleep mutex) @ /usr/src/sys/kern/uipc_syscalls.c:1335 > 2nd 0xc27e5b10 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:1120 > 3rd 0xc27e30e0 so_snd (sleep mutex) @ /usr/src/sys/kern/uipc_sockbuf.c:95 This is the correct lock order, so there must be a new lock order occuring earlier that gets added as the first order causing this one to appear as the incorrect order. The following patch may help in making the right lock order problem come to surface: Index: subr_witness.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_witness.c,v retrieving revision 1.220 diff -u -r1.220 subr_witness.c --- subr_witness.c 11 Nov 2006 03:18:06 -0000 1.220 +++ subr_witness.c 13 Nov 2006 11:14:15 -0000 @@ -325,6 +325,7 @@ /* * UDP/IP */ + { "Giant", &lock_class_mtx_sleep }, { "udp", &lock_class_mtx_sleep }, { "udpinp", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, > KDB: stack backtrace: > db_trace_self_wrapper(c069ae0c) at db_trace_self_wrapper+0x25 > kdb_backtrace(0,0,c071a380,c071a060,c06d24c4,...) at kdb_backtrace+0x29 > witness_checkorder(c27e30e0,9,c069fc63,5f) at witness_checkorder+0x586 > _mtx_lock_flags(c27e30e0,0,c069fc63,5f,c27e5b10,...) at _mtx_lock_flags+0x84 > socantsendmore(c27e3000,c27e5b10,0,c06a78e3,460,...) at socantsendmore+0x1d > udp_shutdown(c27e3000,0,d4b01d04,c2662700,d4b01c84,...) at udp_shutdown+0x3a > soshutdown(c27e3000,2,c2776af8,0,c2662700,...) at soshutdown+0x37 > shutdown(c2662700,d4b01d04) at shutdown+0x5d > syscall(b0003b,822003b,bfbf003b,bfbfc5d0,bfbfc6f0,...) at syscall+0x256 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (134, FreeBSD ELF32, shutdown), eip = 0x2810a277, esp = 0xbfbfc5bc, ebp = 0xbfbfc608 --- > > I assume there is a connection to your patch. > > For the rest of them please have a look at: > http://www.fabiankeil.de/tmp/freebsd/dmesg-with-lors.txt > > Fabian > -- > http://www.fabiankeil.de/ > From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 11:58:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8EF416A407 for ; Mon, 13 Nov 2006 11:58:41 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (ns2.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED1843D5C for ; Mon, 13 Nov 2006 11:58:41 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dkirhlarov.mow.oilspace.com (proxy-mow.oilspace.com [81.222.156.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 692DA17A9F6 for ; Mon, 13 Nov 2006 11:58:40 +0000 (GMT) Received: from dkirhlarov.mow.oilspace.com (localhost [127.0.0.1]) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8) with ESMTP id kADBwdAJ062294 for ; Mon, 13 Nov 2006 14:58:39 +0300 (MSK) (envelope-from dkirhlarov@dkirhlarov.mow.oilspace.com) Received: (from dkirhlarov@localhost) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8/Submit) id kADBwd2O062293 for current@freebsd.org; Mon, 13 Nov 2006 14:58:39 +0300 (MSK) (envelope-from dkirhlarov) Date: Mon, 13 Nov 2006 14:58:39 +0300 From: Dmitriy Kirhlarov To: current@freebsd.org Message-ID: <20061113115839.GL59604@dimma.mow.oilspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.2-PRERELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Subject: nscd 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: Mon, 13 Nov 2006 11:58:41 -0000 Hi, list I'm interested in name service caching daemon for freebsd (it's useful for external userbase, stored in ldap and for monitoring hosts, with resolving/polling of many hosts). It's much more useful, then local cached named and local ldap replica. I found "cached" daemon in HEAD. Can somebody answer me -- when this daemon will be MFC-ed to RELENG_6? Also why this strange name? It's impossible to find this name in google, cause this daemon used to be called nscd. Is there any reason for inventing new name? WBR. Dmitriy From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 12:12:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E28C216A416 for ; Mon, 13 Nov 2006 12:12:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53C2543D5E for ; Mon, 13 Nov 2006 12:12:10 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 29347 invoked from network); 13 Nov 2006 12:12:07 -0000 Received: from unknown (HELO localhost) (775067@[217.50.130.202]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 13 Nov 2006 12:12:07 -0000 Date: Mon, 13 Nov 2006 13:11:39 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20061113131139.0c9e1dd1@localhost> In-Reply-To: <20061113111138.Q38359@fledge.watson.org> References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> <4557330D.3010009@freebsd.org> <20061112170013.78949e96@localhost> <20061112204812.011e06d1@localhost> <20061113111138.Q38359@fledge.watson.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_yjC0Xcd.wdXtT9eKDXXLJHp; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 12:12:20 -0000 --Sig_yjC0Xcd.wdXtT9eKDXXLJHp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Robert Watson wrote: >=20 > On Sun, 12 Nov 2006, Fabian Keil wrote: >=20 > > Fabian Keil wrote: > > > >> Andre Oppermann wrote: > > > >>> Please try this patch: > >>> > >>> http://people.freebsd.org/~andre/sendfile_fix-20061112.diff > >>> > >>> It fixes apache 2.0.59 for me. > >> > >> For me too, but I'm still seeing problems with Gatling/0.8. > > > > I just had to reboot the system and noticed several LORs before > > the login prompt. Because of this one: > > > > lock order reversal: > > 1st 0xc070b6a8 Giant (sleep mutex) > > @ /usr/src/sys/kern/uipc_syscalls.c:1335 2nd 0xc27e5b10 inp (udpinp) > > @ /usr/src/sys/netinet/udp_usrreq.c:1120 3rd 0xc27e30e0 so_snd (sleep > > mutex) @ /usr/src/sys/kern/uipc_sockbuf.c:95 >=20 > This is the correct lock order, so there must be a new lock order > occuring earlier that gets added as the first order causing this one to > appear as the incorrect order. The following patch may help in making > the right lock order problem come to surface: >=20 > Index: subr_witness.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/kern/subr_witness.c,v > retrieving revision 1.220 > diff -u -r1.220 subr_witness.c > --- subr_witness.c 11 Nov 2006 03:18:06 -0000 1.220 > +++ subr_witness.c 13 Nov 2006 11:14:15 -0000 > @@ -325,6 +325,7 @@ > /* > * UDP/IP > */ > + { "Giant", &lock_class_mtx_sleep }, > { "udp", &lock_class_mtx_sleep }, > { "udpinp", &lock_class_mtx_sleep }, > { "so_snd", &lock_class_mtx_sleep }, Thanks, but the LORs are already gone in: FreeBSD 7.0-CURRENT #22: Mon Nov 13 12:47:19 CET 2006 Fabian --=20 http://www.fabiankeil.de/ --Sig_yjC0Xcd.wdXtT9eKDXXLJHp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWGEEBYqIVf93VJ0RApFmAJ9pYUY0IcPcdqYUfGEFkYxWXgPZsQCfQJMI K4wAcbBdHyXVXLzH3lmOV6Y= =vNKr -----END PGP SIGNATURE----- --Sig_yjC0Xcd.wdXtT9eKDXXLJHp-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 12:37:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A39816A412 for ; Mon, 13 Nov 2006 12:37:30 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B9143D8C for ; Mon, 13 Nov 2006 12:37:27 +0000 (GMT) (envelope-from bushman@freebsd.org) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) (authenticated bits=0) by mail.r61.net (8.13.8/8.13.8) with ESMTP id kADCbGPO044181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Nov 2006 15:37:16 +0300 (MSK) (envelope-from bushman@freebsd.org) From: Michael Bushkov Organization: Rostov State University To: freebsd-current@freebsd.org Date: Mon, 13 Nov 2006 15:37:12 +0300 User-Agent: KMail/1.9.4 References: <20061113115839.GL59604@dimma.mow.oilspace.com> In-Reply-To: <20061113115839.GL59604@dimma.mow.oilspace.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200611131537.12954.bushman@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on asterix.r61.net X-Virus-Status: Clean Cc: Dmitriy Kirhlarov Subject: Re: nscd 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: Mon, 13 Nov 2006 12:37:30 -0000 On Monday 13 November 2006 14:58, Dmitriy Kirhlarov wrote: > I'm interested in name service caching daemon for freebsd (it's useful > for external userbase, stored in ldap and for monitoring hosts, with > resolving/polling of many hosts). It's much more useful, then local > cached named and local ldap replica. > > I found "cached" daemon in HEAD. > > Can somebody answer me -- when this daemon will be MFC-ed to RELENG_6? > Also why this strange name? > It's impossible to find this name in google, cause this daemon used to > be called nscd. > Is there any reason for inventing new name? > Actually, cached is called "cached" because initially it was intended only to cache the already obtained results of nsswitch queries. This is not how nscd behaves. Nscd makes all queries (to LDAP, NIS, etc) by itself and caches the results. cached only cached the results of requests, that have been actually made by other applications. The name "cached" was used to highlight this difference. Later, however, the nscd-like functionality was added to cached, but the name was left unchanged. Personally I don't see any reasons why "cached" can't be renamed to nscd right now - so I guess, it would happen in the nearest future. cached is similar to nscd in many ways (including configuration file). To enable nscd-like behavior for particular nsswitch database (so that cached will make all queries by itself), "perform-actual-lookups" directive should be specified in cached.conf. Please see cached(8) manual page for more details about this. The choice of using or not using "perform-actual-lookups" mode depends on many factors and should be made by system administrator. The default value for this option is "no". Can't say anything about when cached would be MFC'ed. All I can say is that it's possible. It will require a number of changes in libc, but they all are fine-grained and, as far as I remember, the patch, that I've used to add caching support to -CURRENT was almost clearly applicable to RELENG_6. -- With best regards, Michael Bushkov Rostov State University -- With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 12:54:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B53816A40F; Mon, 13 Nov 2006 12:54: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 45ED643D70; Mon, 13 Nov 2006 12:54:10 +0000 (GMT) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5FAFC.dip.t-dialin.net [84.165.250.252]) by redbull.bpaserver.net (Postfix) with ESMTP id CEB952E06A; Mon, 13 Nov 2006 13:54:02 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 4C5395B4C35; Mon, 13 Nov 2006 13:54:01 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id kADCs1pl061427; Mon, 13 Nov 2006 13:54:01 +0100 (CET) (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, 13 Nov 2006 13:54:01 +0100 Message-ID: <20061113135401.3dm4klxfacsc48gg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 13 Nov 2006 13:54:01 +0100 From: Alexander Leidinger To: Bakul Shah References: <20061112185526.771565B3C@mail.bitblocks.com> In-Reply-To: <20061112185526.771565B3C@mail.bitblocks.com> 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.3) / 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.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: attack of the zombies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 12:54:15 -0000 Quoting Bakul Shah (from Sun, 12 Nov 2006 =20 10:55:26 -0800): > About a week or so ago I updated -current and now linux > binaries don't seem to collect all zombie processes. > Eventually the maxproc limit is reached and further forks > fail so that you can't even do ps (of course, dealing > sensibly with such errors is another problem with most > programs but that is a separate discussion). Work around is > killing linux programs to allow init to kill the zombies. You are the first one reporting this problem. I didn't noticed =20 something like this in my regression test runs with the linux test =20 project testcases and all other active developers in this area didn't =20 noticed something like this too (so far). Do you have some small =20 testcases (e.g. with programs in linux_base) or does this apply to a =20 specific workload (like the one below) only? > This happens with skype, firefox and opera and may be more. > I reinstalled linux_base-fc-4_9 and all ports depending on it > -- all updated yesterday. The problem persists even with To make sure there is no "garbage" somewhere: - remove all linux ports - remove /compat/linux/* (rm -rf) - install what you need (only from ports) > yesterday's -current. This problem showed up sometime > between Oct 6 and Nov 6. One significant change I see during > this time is the treatment of KSE. But presence or absence > of nooption KSE does not seem to affect this problem. BTW, > linux emulation is loaded as a module. We are talking about i386, right? Please provide the output of "sysctl =20 compat.linux" (osversion should be set to 2.4.2). > Also note that the old problem of linux-* programs gobbling > up lots of memory is still present. For example, FreeBSD > opera uses 96MB while Linux opera on FreeBSD needs 236MB + 48 > zombies to displaying exact same 24 pages (same session file > and *just* after starting!). > > Is this a known problem? Am I doing something wrong? This is not a known problem (at least not for 2.4.2 compatibility, =20 which is the default in -current). For known problems have a look at =20 http://wiki.freebsd.org/linux-kernel Bye, Alexander. --=20 "The only real way to look younger is not to be born so soon." =09=09-- Charles Schulz, "Things I've Had to Learn Over and =09=09 Over and Over" 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 Nov 13 13:04:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90CCE16A47C; Mon, 13 Nov 2006 13:04:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0347243D69; Mon, 13 Nov 2006 13:04:42 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id kADD4f38028949; Mon, 13 Nov 2006 08:04:41 -0500 (EST) Date: Mon, 13 Nov 2006 08:04:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Michael Bushkov In-Reply-To: <200611131537.12954.bushman@freebsd.org> Message-ID: References: <20061113115839.GL59604@dimma.mow.oilspace.com> <200611131537.12954.bushman@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Mon, 13 Nov 2006 08:04:41 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org, Dmitriy Kirhlarov Subject: Re: nscd for freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 13:04:43 -0000 On Mon, 13 Nov 2006, Michael Bushkov wrote: > On Monday 13 November 2006 14:58, Dmitriy Kirhlarov wrote: >> I'm interested in name service caching daemon for freebsd (it's useful >> for external userbase, stored in ldap and for monitoring hosts, with >> resolving/polling of many hosts). It's much more useful, then local >> cached named and local ldap replica. >> >> I found "cached" daemon in HEAD. >> >> Can somebody answer me -- when this daemon will be MFC-ed to RELENG_6? >> Also why this strange name? >> It's impossible to find this name in google, cause this daemon used to >> be called nscd. >> Is there any reason for inventing new name? >> > Actually, cached is called "cached" because initially it was intended only to > cache the already obtained results of nsswitch queries. This is not how nscd > behaves. Nscd makes all queries (to LDAP, NIS, etc) by itself and caches the > results. cached only cached the results of requests, that have been actually > made by other applications. The name "cached" was used to highlight this > difference. > > Later, however, the nscd-like functionality was added to cached, but the name > was left unchanged. Personally I don't see any reasons why "cached" can't be > renamed to nscd right now - so I guess, it would happen in the nearest > future. If it now performs the same thing as Linux/Solaris nscd, then can we change the name to nscd and nscd.conf before 7.0 goes out the door? -- DE From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 13:08:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A46216A40F; Mon, 13 Nov 2006 13:08:26 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50F4C43D5A; Mon, 13 Nov 2006 13:08:24 +0000 (GMT) (envelope-from bushman@freebsd.org) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) (authenticated bits=0) by mail.r61.net (8.13.8/8.13.8) with ESMTP id kADD8LeT050345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Nov 2006 16:08:21 +0300 (MSK) (envelope-from bushman@freebsd.org) From: Michael Bushkov Organization: Rostov State University To: freebsd-current@freebsd.org, Daniel Eischen Date: Mon, 13 Nov 2006 16:08:19 +0300 User-Agent: KMail/1.9.4 References: <20061113115839.GL59604@dimma.mow.oilspace.com> <200611131537.12954.bushman@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611131608.19793.bushman@freebsd.org> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on asterix.r61.net X-Virus-Status: Clean Cc: Dmitriy Kirhlarov Subject: Re: nscd 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: Mon, 13 Nov 2006 13:08:26 -0000 On Monday 13 November 2006 16:04, Daniel Eischen wrote: > > Later, however, the nscd-like functionality was added to cached, but the > > name was left unchanged. Personally I don't see any reasons why "cached" > > can't be renamed to nscd right now - so I guess, it would happen in the > > nearest future. > > If it now performs the same thing as Linux/Solaris nscd, then can > we change the name to nscd and nscd.conf before 7.0 goes out the > door? I'll prepare the patch and will file the PR. -- With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 14:35:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB2216A407 for ; Mon, 13 Nov 2006 14:35:12 +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 CEE5143E16 for ; Mon, 13 Nov 2006 14:34:02 +0000 (GMT) (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 DE2BF46E02 for ; Mon, 13 Nov 2006 09:34:01 -0500 (EST) Date: Mon, 13 Nov 2006 14:34:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20061113141916.H38359@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: My slides from EuroBSDCon 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 14:35:13 -0000 Dear All, I've put my slides from EuroBSDCon 2006 up on my web site: http://www.watson.org/~robert/freebsd/2006eurobsdcon/ These include the TrustedBSD slides from the developer summit, my slides from my "How the FreeBSD Project Works" talk (revised version of a talk by the same name at BSDCan 2006), and a pointer to the TrustedBSD Audit slides I gave previously at UKUUG, but presented on short notice as a substitution for a speaker who failed to turn up. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 15:38:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA9A16A407 for ; Mon, 13 Nov 2006 15:38:49 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C7A43D73 for ; Mon, 13 Nov 2006 15:38:36 +0000 (GMT) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id kADFbvLr017130; Mon, 13 Nov 2006 16:37:57 +0100 From: Pieter de Goeje To: pyunyh@gmail.com Date: Mon, 13 Nov 2006 16:37:57 +0100 User-Agent: KMail/1.9.4 References: <20061111011051.GB5233@cdnetworks.co.kr> In-Reply-To: <20061111011051.GB5233@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611131637.57216.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Call for re(4) TSO/VLAN testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 15:38:49 -0000 On Saturday 11 November 2006 02:10, Pyun YongHyeon wrote: > With TSO you can see reduced system load while large file transfers > is in progress. Please test the patch and report any unusual things > you've found. Idle time has increased from 0% to 25% with this patch while sustaining the transferrate (520Mbit/s) previously reached with iperf. With the patch the number of interrupts/sec. was halved from 32K to 16K. The test was performed on a fresh current without any tuning but with debug support removed. System details: CPU: AMD Sempron(tm) 2400+ (1659.95-MHz 686-class CPU) re0@pci0:9:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' The receiving end was probably limiting the transferrate. -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 16:26:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A44C16A407 for ; Mon, 13 Nov 2006 16:26:15 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 920CB43D67 for ; Mon, 13 Nov 2006 16:25:51 +0000 (GMT) (envelope-from bahamasfranks@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so974250uge for ; Mon, 13 Nov 2006 08:25:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=bx+fSjgiILaD6MpjE5Sv/km6eYdxXPGC7z8WNwk+iMuZ5V1OUVR3ye5ZaC54mFOUc7PV1cAK9WHmQ+mdWCKwtqQjUEslhk3LLYcgyj/e+qbxX85Cl1v4yEoyLxk+FAfZ2PSvQIHtztB832hvuYkotrlzoD/BR7o50SRGAdu9VjY= Received: by 10.66.255.7 with SMTP id c7mr5769445ugi.1163435147903; Mon, 13 Nov 2006 08:25:47 -0800 (PST) Received: by 10.66.236.1 with HTTP; Mon, 13 Nov 2006 08:25:47 -0800 (PST) Message-ID: <539c60b90611130825x3219cdf2k1f355e2dfa7a9b5a@mail.gmail.com> Date: Mon, 13 Nov 2006 09:25:47 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 1b979f574f92b02a Subject: dhcp only works once on wifi card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 16:26:15 -0000 Hi, Have a wifi card that dhcp's fine on startup, however, every time the AP drops off (say 15-45min), it loses it's ip adress, and never asks for a new one. Adapter has "blah blah blah DCHP" in it's ifconfig entry in rc.conf, what am I missing? Do I need to place dhclient_enable="YES" in rc.conf or something like that? The man page for dhclient seems to assume it's always run from the command line, afaik, although the -b switch would indicate otherwise... Thanks, Steve -- Steve Franks, KE7BTE Staff Engineer La Palma Devices, LLC http://www.lapalmadevices.com (520) 312-0089 From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 16:50:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD35E16A5E8 for ; Mon, 13 Nov 2006 16:50:33 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2312343D55 for ; Mon, 13 Nov 2006 16:50:32 +0000 (GMT) (envelope-from bahamasfranks@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so982116uge for ; Mon, 13 Nov 2006 08:50:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=XNj8IdCmUoZ+H1IrzGExBIGKKH93el5VmfMfhqgPKPCBd5drO4gclIXsJbse9FxqImeL4EsjqexMVNeF4X0jWzihLRHSeg0xCHsocUq5XAkuWJgO4zkhddaMvxf+sCa2J5oSKxW3RcCWGUPXZr/+FAR53hr6uYSo690+/g9tyZU= Received: by 10.67.30.6 with SMTP id h6mr8385640ugj.1163436632143; Mon, 13 Nov 2006 08:50:32 -0800 (PST) Received: by 10.66.236.1 with HTTP; Mon, 13 Nov 2006 08:50:32 -0800 (PST) Message-ID: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> Date: Mon, 13 Nov 2006 09:50:32 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 982224faaf696166 Subject: now from way-out in left field X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 16:50:33 -0000 So I know you can open up 4 or more virtual desktops in X. And I know you can open up any number of terminals. But I sort of like the nice clean look and feel of a plain old vtty for many tasks. Unfortuately, X, it would seem, steals all the F-keys, and the screen it would seem. Is there any slight of hand I can do to switch between X on vtty1 and my other enabled vtty's? I've also had KDE lock up solid (as I result I'm evaluating gnome), and that would be a good method to fix things, instead of the power switch, I would think. Obviously, I've marked myself as a noob, and not to step on toes, but ctrl-alt-del on winNT's generally does get one the task manager, unless you are bluescreened. If I'm on a tty I feel reasonalby sure I can kill anything locked. Unfortunately, the modern world needs X sometimes, lynx only goes so far, but then I'm at X's mercy, follow me? Ok, I'll shut up now. Have mercy on my opinions ;) Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 16:53:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 885B616A636; Mon, 13 Nov 2006 16:53:47 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E5743D9D; Mon, 13 Nov 2006 16:53:44 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gjf44-0002eC-2Q; Mon, 13 Nov 2006 16:53:44 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gjf2L-0001f7-JO; Mon, 13 Nov 2006 06:51:57 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17752.41644.706579.902238@roam.psg.com> Date: Mon, 13 Nov 2006 06:51:56 -1000 To: FreeBSD Current Cc: freebsd-net@freebsd.org Subject: fxp going quiescent in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 16:53:47 -0000 FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 and for the last four or five days, fxp0 goes dead. it shows up and active, but no packets move. down/up does not help. only way out has been reboot. suggestions on how to debug? randy From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 17:27:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32DF716A49E for ; Mon, 13 Nov 2006 17:27:46 +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 723DC43E7C for ; Mon, 13 Nov 2006 17:19:10 +0000 (GMT) (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.13.8/8.13.8) with ESMTP id kADHEsjU005896; Mon, 13 Nov 2006 09:14:54 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kADHEsYK005895; Mon, 13 Nov 2006 09:14:54 -0800 (PST) (envelope-from sgk) Date: Mon, 13 Nov 2006 09:14:54 -0800 From: Steve Kargl To: Steve Franks Message-ID: <20061113171454.GA5806@troutmask.apl.washington.edu> References: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: now from way-out in left field X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 17:27:46 -0000 On Mon, Nov 13, 2006 at 09:50:32AM -0700, Steve Franks wrote: > So I know you can open up 4 or more virtual desktops in X. And I know > you can open up any number of terminals. But I sort of like the nice > clean look and feel of a plain old vtty for many tasks. Unfortuately, > X, it would seem, steals all the F-keys, and the screen it would seem. > Is there any slight of hand I can do to switch between X on vtty1 and > my other enabled vtty's? I've also had KDE lock up solid (as I result > I'm evaluating gnome), and that would be a good method to fix things, > instead of the power switch, I would think. Obviously, I've marked > myself as a noob, and not to step on toes, but ctrl-alt-del on winNT's > generally does get one the task manager, unless you are bluescreened. > If I'm on a tty I feel reasonalby sure I can kill anything locked. > Unfortunately, the modern world needs X sometimes, lynx only goes so > far, but then I'm at X's mercy, follow me? Ok, I'll shut up now. > Have mercy on my opinions ;) > Unless you've done something with remapping the keyboard in X and you've done something to /etc/ttys, ctrl-alt-Fn where n = 1, ..., 12 should work. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 17:41:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1951D16A407; Mon, 13 Nov 2006 17:41:49 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id B654644121; Mon, 13 Nov 2006 17:36:17 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 390045B50; Mon, 13 Nov 2006 09:35:43 -0800 (PST) To: Alexander Leidinger In-reply-to: Your message of "Mon, 13 Nov 2006 13:54:01 +0100." <20061113135401.3dm4klxfacsc48gg@webmail.leidinger.net> Date: Mon, 13 Nov 2006 09:35:43 -0800 From: Bakul Shah Message-Id: <20061113173543.390045B50@mail.bitblocks.com> Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: attack of the zombies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 17:41:49 -0000 First of all, thanks for looking at this! > To make sure there is no "garbage" somewhere: > - remove all linux ports > - remove /compat/linux/* (rm -rf) I hope we can find a less drastic way to handle such problems. Anyway I did this. > - install what you need (only from ports) # cd /usr/port/net/skype; make install This resulted in fresh install of the following ports: skype-1.2.0.18_2 linux_dri-6.5 linux-xorg-libs-6.8.2_5 linux-fontconfig-2.2.3_5 linux-expat-1.95.8 linux_base-fc-4_9 Then I fired up skype and logged in and now there are 28 zombies. My guess is something with signals broke. Next I will try backing out just the stuff in /sys/compat/linux and recompling/reloading linux.ko > We are talking about i386, right? Please provide the output of "sysctl > compat.linux" (osversion should be set to 2.4.2). Correct. Only the i386. $ sysctl compat.linux compat.linux.oss_version: 198144 compat.linux.osrelease: 2.4.2 compat.linux.osname: Linux > > Also note that the old problem of linux-* programs gobbling > > up lots of memory is still present. For example, FreeBSD > > opera uses 96MB while Linux opera on FreeBSD needs 236MB + 48 > > zombies to displaying exact same 24 pages (same session file > > and *just* after starting!). > > > > Is this a known problem? Am I doing something wrong? > > This is not a known problem (at least not for 2.4.2 compatibility, > which is the default in -current). For known problems have a look at > http://wiki.freebsd.org/linux-kernel Thanks! From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 18:36:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37ADC16A4D0 for ; Mon, 13 Nov 2006 18:36:26 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 744D543E56 for ; Mon, 13 Nov 2006 18:30:03 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 5BD958A00C8 for ; Mon, 13 Nov 2006 10:29:51 -0800 (PST) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 99442-32 for ; Mon, 13 Nov 2006 10:29:44 -0800 (PST) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 83A2A8A0082 for ; Mon, 13 Nov 2006 10:29:40 -0800 (PST) Received: from 24.71.118.34 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Mon, 13 Nov 2006 10:29:44 -0800 (PST) Message-ID: <60055.24.71.118.34.1163442584.squirrel@webmail.sd73.bc.ca> In-Reply-To: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> References: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> Date: Mon, 13 Nov 2006 10:29:44 -0800 (PST) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: Subject: Re: now from way-out in left field X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 18:36:26 -0000 On Mon, November 13, 2006 8:50 am, Steve Franks wrote: > So I know you can open up 4 or more virtual desktops in X. And I > know you can open up any number of terminals. But I sort of like the > nice clean look and feel of a plain old vtty for many tasks. > Unfortuately, X, it would seem, steals all the F-keys, and the screen > it would seem. Is there any slight of hand I can do to switch between > X on vtty1 and my other enabled vtty's? I've also had KDE lock up > solid (as I result I'm evaluating gnome), and that would be a good > method to fix things, instead of the power switch, I would think. > Obviously, I've marked myself as a noob, and not to step on toes, but > ctrl-alt-del on winNT's generally does get one the task manager, > unless you are bluescreened. If I'm on a tty I feel reasonalby sure I > can kill anything locked. Unfortunately, the modern world needs X > sometimes, lynx only goes so far, but then I'm at X's mercy, follow > me? Ok, I'll shut up now. Have mercy on my opinions ;) To switch terminals at the console, you can use either ALT+Fx or CTRL+ALT+Fx (where x is 1 through the number of terminals configured, usually 8). To switch to a terminal while in X, you can only use CTRL+ALT+Fx. And to switch back to X you can use either ALT+Fx or CTRL+ALT+Fx, where x is one higher than the number of configured terminals, usually 9). ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 18:50:10 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42E4E16A4CE for ; Mon, 13 Nov 2006 18:50:10 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A324244094 for ; Mon, 13 Nov 2006 18:41:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1183E1A4D84; Mon, 13 Nov 2006 10:40:54 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5BA085138B; Mon, 13 Nov 2006 13:40:43 -0500 (EST) Date: Mon, 13 Nov 2006 13:40:43 -0500 From: Kris Kennaway To: Andrey Smagin Message-ID: <20061113184043.GA51603@xor.obsecurity.org> References: <45582D3E.1060305@mail.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <45582D3E.1060305@mail.ru> User-Agent: Mutt/1.4.2.2i Cc: current@FreeBSD.org Subject: Re: Hard reset on amd64 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, 13 Nov 2006 18:50:10 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 11:30:54AM +0300, Andrey Smagin wrote: > Hi. If I copy files from PC1 to PC2 via NFS, PC1 - cold rebooted after=20 > copying some KBytes of file. If copying via Smb protocol or from PC2 to= =20 > PC1 via NFS - all success. PC1 - Current(GENERIC 5 days ago), AMD64. PC2= =20 > - Current(GENERIC, 1-2 week ago), i386. This is usually hardware related, does it work on systems older than this date? Kris --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWLwqWry0BWjoQKURAk7YAJ41gl83mSrEAGajB7G0C5QYpLyVHwCgqkJp BU4tyftuIuVRRrP+KCpk/2I= =oIpI -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 21:55:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1170D16A47B; Mon, 13 Nov 2006 21:55:49 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A7743D5A; Mon, 13 Nov 2006 21:55:04 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id kADLsrtY092904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 22:54:53 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id kADLsqd7092903; Mon, 13 Nov 2006 22:54:52 +0100 (CET) Date: Mon, 13 Nov 2006 22:54:52 +0100 From: Divacky Roman To: Bakul Shah Message-ID: <20061113215452.GA92609@stud.fit.vutbr.cz> References: <20061113135401.3dm4klxfacsc48gg@webmail.leidinger.net> <20061113173543.390045B50@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113173543.390045B50@mail.bitblocks.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: Alexander Leidinger , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: attack of the zombies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Nov 2006 21:55:49 -0000 > Then I fired up skype and logged in and now there are 28 > zombies. My guess is something with signals broke. Next > I will try backing out just the stuff in /sys/compat/linux > and recompling/reloading linux.ko yes.. I can reproduce that with skype... I wonder what could break becausewith 2.4 emulation there should not be any change... interesting I'll give it a shot roman From owner-freebsd-current@FreeBSD.ORG Mon Nov 13 22:21:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72A9816A4D8 for ; Mon, 13 Nov 2006 22:21:23 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCCC643E7D for ; Mon, 13 Nov 2006 22:18:31 +0000 (GMT) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1071901uge for ; Mon, 13 Nov 2006 14:18:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=D2mmo7YsHcUH31nMA24XMizrIMbGyTY8ER64Z+ezYeR7qotNk8KTNRC0CHFBvrdYa2i96d/iCPuXZF5+arYwtW0VzgpO3AiUQcXiNgfHhey5JZdpA+0vJdvSvfLDiuo31PlOWcSeueaJ7sHlSg2DDnOQJ9zQuwovi51Iu0CAmHU= Received: by 10.66.255.7 with SMTP id c7mr173285ugi.1163456301109; Mon, 13 Nov 2006 14:18:21 -0800 (PST) Received: from ?192.168.123.106? ( [195.241.221.201]) by mx.google.com with ESMTP id a1sm6945735ugf.2006.11.13.14.18.19; Mon, 13 Nov 2006 14:18:20 -0800 (PST) Message-ID: <4558EF27.2040601@gmail.com> Date: Mon, 13 Nov 2006 23:18:15 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Fwd: xtaf-r6-20061112 available] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:21:23 -0000 I thought it might be interesting to forward the message below to current@ . I have made a version of the patch for CURRENT 2006-11-13 available at http://home.tiscali.nl/rladan/freebsd/xtaf-head-20061113.diff.bz2 -rw-r--r-- 1 rene rene 40867 13 nov 22:34 xtaf-head-20061113.diff.bz2 MD5 (xtaf-head-20061113.diff.bz2) = b8be64e1331470a1153965dc0903d085 It survives 'make buildworld' and 'make buildkernel', it probably doesn't properly hook up to /dev yet (see below). If you want to play with the code, you'd better take a dd of your precious Xbox stuff... (i.e. no warranty) Regards, Rene -------- Originele bericht -------- Onderwerp: xtaf-r6-20061112 available Datum: Sun, 12 Nov 2006 23:47:39 +0100 Van: Rene Ladan Aan: freebsd-fs@freebsd.org Hi, I've uploaded a new version of the XTAF (XBox 360 fs) code at http://home.tiscali.nl/rladan/freebsd/xtaf-r6-20061112.diff.bz2 The code now patch(1)es against /usr/src, no further actions are needed as in the previous version. It compiles on RELENG_6 2006-11-12, it probably fails on CURRENT. Read support should be fairly complete. Some hard disk issues may be remaining, but memory cards should be supported unless I made a mistake somewhere. I haven't really looked into write support yet. The biggest todo right now is to connect the code with the code which creates /dev/da?s? (geom?) . Both memory cards and hard disks have multiple slices. The start/size information is not stored on the devices, but in the XBox 360 kernel, so we have to duplicate it here. For memory cards (64MB) : start size info 0x0 0x7ff,000 XTAF, 16 bits, system cache 0x7ff,000 0x3,621,000 XTAF, 16 bits, user area For hard disks (20GB) : start size info 0x0 0x80,000 hard disk header 0x80,000 0x80,000,000 XTAF, 16 bits, system cache 0x80,080,000 0xA0,E30,000 unused, filled with 00 0x120,eb0,000 0x10,000,000 XTAF, 16 bits, XBox 1 compatibility 0x130,eb0,000 0x377,680,000 XTAF, 32 bits, user area I haven't yet looked at the new 256MB memory cards (goto shop). There are also rumors about larger hard disks, ranging from 60GB to 200GB. Other todos: write support, hard disk header support Could some locking / fs guru could sanity check the code? That would speed up runtime testing of the code. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 00:01:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5F8716A415 for ; Tue, 14 Nov 2006 00:01:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 687C143D5A for ; Tue, 14 Nov 2006 00:01:02 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so870138nzh for ; Mon, 13 Nov 2006 16:00:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=iEiavfAc+sitmiKooWbHYvUuAXJirvCqt+0tu9tX7BAyOXHhLaHzweWw9IEkLJtr9iv6tsj6LviY/1YL1iyYFHq3S+MjAmTfEWFNfxlJ7Hywi7tMEkWY3luf3QAgWXoxb7iZWVSSl03Gih1NkcPsSQDKmlxlJi9zeETBpok1ftM= Received: by 10.35.49.1 with SMTP id b1mr423955pyk.1163462458882; Mon, 13 Nov 2006 16:00:58 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 12sm23417675nzn.2006.11.13.16.00.57; Mon, 13 Nov 2006 16:00:58 -0800 (PST) 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 kAE015ho005743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Nov 2006 09:01:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kAE014QM005742; Tue, 14 Nov 2006 09:01:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 14 Nov 2006 09:01:03 +0900 From: Pyun YongHyeon To: Pieter de Goeje Message-ID: <20061114000103.GA5517@cdnetworks.co.kr> References: <20061111011051.GB5233@cdnetworks.co.kr> <200611131637.57216.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611131637.57216.pieter@degoeje.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for re(4) TSO/VLAN testers 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: Tue, 14 Nov 2006 00:01:33 -0000 On Mon, Nov 13, 2006 at 04:37:57PM +0100, Pieter de Goeje wrote: > On Saturday 11 November 2006 02:10, Pyun YongHyeon wrote: > > With TSO you can see reduced system load while large file transfers > > is in progress. Please test the patch and report any unusual things > > you've found. > > Idle time has increased from 0% to 25% with this patch while sustaining the > transferrate (520Mbit/s) previously reached with iperf. > With the patch the number of interrupts/sec. was halved from 32K to 16K. > > The test was performed on a fresh current without any tuning but with debug > support removed. > > System details: > CPU: AMD Sempron(tm) 2400+ (1659.95-MHz 686-class CPU) > re0@pci0:9:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8169 Gigabit Ethernet Adapter' > > The receiving end was probably limiting the transferrate. > Thanks for reporting. ATM re(4) uses still small number of Tx descriptors(i.e. 64 entries) due to the hardware limitation of 8139C+. 8169 family can have up to 1024 Tx descriptors. If we want to use more Tx descriptors on 8169 the internal structure should be modified to support both 8139C+ and 8169. I guess it would require major Tx path overhaul. Because I have just plain PCI 8169 hardware I can't sure increasing number of Tx descriptors on re(4) help Tx performance of the driver. I guess 64 Tx descriptors are not sufficient to saturate giga bit link. Would please try attached patch and report the performance of patched re(4) driver? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 01:54:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2844316A403 for ; Tue, 14 Nov 2006 01:54:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id B90FA43D99 for ; Tue, 14 Nov 2006 01:53:05 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061114015241m9100emp91e>; Tue, 14 Nov 2006 01:52:44 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kAE1qdQq041922; Mon, 13 Nov 2006 19:52:40 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kAE1qdMs041921; Mon, 13 Nov 2006 19:52:39 -0600 (CST) (envelope-from brooks) Date: Mon, 13 Nov 2006 19:52:38 -0600 From: Brooks Davis To: Steve Franks Message-ID: <20061114015238.GA41883@lor.one-eyed-alien.net> References: <539c60b90611130825x3219cdf2k1f355e2dfa7a9b5a@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <539c60b90611130825x3219cdf2k1f355e2dfa7a9b5a@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: dhcp only works once on wifi card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 01:54:58 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 09:25:47AM -0700, Steve Franks wrote: > Hi, >=20 > Have a wifi card that dhcp's fine on startup, however, every time the > AP drops off (say 15-45min), it loses it's ip adress, and never asks > for a new one. Adapter has "blah blah blah DCHP" in it's ifconfig > entry in rc.conf, what am I missing? Do I need to place > dhclient_enable=3D"YES" in rc.conf or something like that? The man page > for dhclient seems to assume it's always run from the command line, > afaik, although the -b switch would indicate otherwise... This is probably a bug in the driver's link state handling. What type of device is it? -- Brooks --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWSFmXY6L6fI4GtQRAhleAJ4oX9jZWcvAloy+pM1zKEa0Z68/kQCgtzjX 0Uh5mAxcnrG7VnLzCCb2aEw= =HDe0 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 02:08:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E6F316A417 for ; Tue, 14 Nov 2006 02:08:32 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD054404B for ; Tue, 14 Nov 2006 02:00:57 +0000 (GMT) (envelope-from fulanpeng@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so616070wra for ; Mon, 13 Nov 2006 18:00:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BzVkg6mGlSeJOlyS8vDqZ5YkpC0+D5ZyakvWo76TX2YWlu/XL9gHKGKuEZ3019afzFDJwJjnTzixpBvJjNzf1/KzbJNmQLDQnlxrYPRkbv2s8fH/a70et0blln5kM5pN+mYDmhvsCSLYGTLKuYDxjnQwnIC4Ceg5DWbm2LFSXwg= Received: by 10.90.31.19 with SMTP id e19mr409567age.1163469634911; Mon, 13 Nov 2006 18:00:34 -0800 (PST) Received: by 10.64.233.11 with HTTP; Mon, 13 Nov 2006 18:00:34 -0800 (PST) Message-ID: Date: Mon, 13 Nov 2006 21:00:34 -0500 From: "fulan Peng" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Please help with ipfw to redirect port 443 to 8892! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 02:08:32 -0000 Hi, I have recompiled the CURRENT and 6.1 kernel and added IPFIREWALL. All I want to do is to redirect incoming 443 request to 8892 which is listening and I have tested out https://breakevilaxis.org:8892 working. I added one line in the /etc/rc.firewall file with ipfw add 400 fwd 66.29.75.29,443 tcp from any to any 8892 in via "rl0" keep-state breakevilaxis# ipfw -t list 00100 Mon Nov 13 16:45:36 2006 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 fwd 66.29.75.20,443 tcp from any to any dst-port 8892 in via rl0 keep-state 65000 Mon Nov 13 16:48:02 2006 allow ip from any to any 65535 deny ip from any to any Now when I type https://66.29.75.20, it won't redirect to port 8892. Please help me to redirect port 443 to 8892. Seems FreeBSD does not allow any one to use port below 1024 except root but all of the port applications configured to run as non-root users such www. I checked pf. It is even complicated than ipfw. It needs compiling the kernel with some file system. When I type pf -e, it says /dev/pf file or directory not exists. So I have to give up pf. In CURRENT, there is a port of PAM, but there is no PAM in 6.1. I have got PAM working in CURRENT to redirect port 80 to port 8080. From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 02:29:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31DDE16A412; Tue, 14 Nov 2006 02:29:28 +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 69E8043D58; Tue, 14 Nov 2006 02:29:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAE2TQuj045081; Mon, 13 Nov 2006 21:29:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAE2TQmB022643; Mon, 13 Nov 2006 21:29:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 64C9D73068; Mon, 13 Nov 2006 21:29:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061114022926.64C9D73068@freebsd-current.sentex.ca> Date: Mon, 13 Nov 2006 21:29:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 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: Tue, 14 Nov 2006 02:29:28 -0000 TB --- 2006-11-14 01:10:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-14 01:10:19 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-11-14 01:10:19 - cleaning the object tree TB --- 2006-11-14 01:11:04 - checking out the source tree TB --- 2006-11-14 01:11:04 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-11-14 01:11:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-14 01:22:32 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-14 01:22:32 - cd /src TB --- 2006-11-14 01:22:32 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 14 01:22:34 UTC 2006 >>> 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 Tue Nov 14 02:18:28 UTC 2006 TB --- 2006-11-14 02:18:28 - generating LINT kernel config TB --- 2006-11-14 02:18:28 - cd /src/sys/pc98/conf TB --- 2006-11-14 02:18:28 - /usr/bin/make -B LINT TB --- 2006-11-14 02:18:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-14 02:18:28 - cd /src TB --- 2006-11-14 02:18:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 14 02:18:29 UTC 2006 >>> 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 [...] nexus.o(.text+0x86a): In function `nexus_alloc_msix': : undefined reference to `msix_alloc' nexus.o(.text+0x8bd): In function `nexus_release_msix': : undefined reference to `msix_release' nexus.o(.text+0x8f6): In function `nexus_alloc_msi': : undefined reference to `msi_alloc' nexus.o(.text+0x950): In function `nexus_release_msi': : undefined reference to `msi_release' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-14 02:29:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-14 02:29:26 - ERROR: failed to build lint kernel TB --- 2006-11-14 02:29:26 - tinderbox aborted TB --- 0.80 user 2.71 system 4747.10 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 03:31:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD0516A4B3 for ; Tue, 14 Nov 2006 03:31:48 +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 AF96F43D46 for ; Tue, 14 Nov 2006 03:31:47 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.6/8.13.8) id kAE3Vkvk036308; Mon, 13 Nov 2006 21:31:46 -0600 (CST) (envelope-from dan) Date: Mon, 13 Nov 2006 21:31:46 -0600 From: Dan Nelson To: fulan Peng Message-ID: <20061114033146.GA61297@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 6.2-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: Please help with ipfw to redirect port 443 to 8892! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 03:31:48 -0000 In the last episode (Nov 13), fulan Peng said: > I have recompiled the CURRENT and 6.1 kernel and added IPFIREWALL. > All I want to do is to redirect incoming 443 request to 8892 which is > listening and I have tested out https://breakevilaxis.org:8892 > working. > I added one line in the /etc/rc.firewall file with > ipfw add 400 fwd 66.29.75.29,443 tcp from any to any 8892 in via "rl0" keep-state You probably want "fwd 66.29.75.29,8892 tcp from any to any 443" here. The command you have would redirect port 8892 to port 443. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 04:23:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A77716A416 for ; Tue, 14 Nov 2006 04:23:17 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F19743D49 for ; Tue, 14 Nov 2006 04:23:16 +0000 (GMT) (envelope-from fulanpeng@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so894206nzh for ; Mon, 13 Nov 2006 20:23:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ST1y7BsMvwX/hb7Biz/IPt05cKLq5diGq5TATCRfD44MRwoMJIlHy1YOfScZFmKa3rKAV7XU1OMbzzQ41m25JbKHUdpVbL2zyuPv4W0uUq2V6Cwj1YFfFmrhceO0z0bGoy0pNkbjUACLzlVg/IQhwdGb2VopNO2wSZUhSVGGZA8= Received: by 10.65.219.4 with SMTP id w4mr395581qbq.1163478194765; Mon, 13 Nov 2006 20:23:14 -0800 (PST) Received: by 10.64.233.11 with HTTP; Mon, 13 Nov 2006 20:23:14 -0800 (PST) Message-ID: Date: Mon, 13 Nov 2006 23:23:14 -0500 From: "fulan Peng" To: "Dan Nelson" In-Reply-To: <20061114033146.GA61297@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061114033146.GA61297@dan.emsphone.com> Cc: freebsd-current@freebsd.org Subject: Re: Please help with ipfw to redirect port 443 to 8892! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 04:23:17 -0000 Yes, you are right. Now it is working. By the way, if any of you need a chat or conference, this is free for you as long as you set up your Apache as a reverse proxy server or set up Squid reverse proxy server on your site. The chat server is ejabberd running on Open Telecom Protocol in erlang. I have a cluster of ejabberd server. I am also playing YXA sip server with minisip client for VOIP. On 11/13/06, Dan Nelson wrote: > In the last episode (Nov 13), fulan Peng said: > > I have recompiled the CURRENT and 6.1 kernel and added IPFIREWALL. > > All I want to do is to redirect incoming 443 request to 8892 which is > > listening and I have tested out https://breakevilaxis.org:8892 > > working. > > > I added one line in the /etc/rc.firewall file with > > ipfw add 400 fwd 66.29.75.29,443 tcp from any to any 8892 in via "rl0" keep-state > > You probably want "fwd 66.29.75.29,8892 tcp from any to any 443" here. > The command you have would redirect port 8892 to port 443. > > -- > Dan Nelson > dnelson@allantgroup.com > From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 04:31:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7C3A16A403 for ; Tue, 14 Nov 2006 04:31:18 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DA043D4C for ; Tue, 14 Nov 2006 04:31:18 +0000 (GMT) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id kAE4VBox002624; Tue, 14 Nov 2006 05:31:12 +0100 From: Pieter de Goeje To: "Steve Franks" Date: Tue, 14 Nov 2006 05:31:11 +0100 User-Agent: KMail/1.9.4 References: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> In-Reply-To: <539c60b90611130850j342a937dmdde6d826258ca8fb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611140531.11344.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: now from way-out in left field X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 04:31:18 -0000 On Monday 13 November 2006 17:50, you wrote: > If I'm on a tty I feel reasonalby sure I can kill anything locked. You can use CTRL+ALT+BACKSPACE to kill X (and everything running in it). Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 09:15:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE9D16A47B; Tue, 14 Nov 2006 09:15:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 884CB43D45; Tue, 14 Nov 2006 09:15:11 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAE9FAJW041493; Tue, 14 Nov 2006 04:15:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAE9FAoX046546; Tue, 14 Nov 2006 04:15:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A953873068; Tue, 14 Nov 2006 04:15:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061114091509.A953873068@freebsd-current.sentex.ca> Date: Tue, 14 Nov 2006 04:15:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 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: Tue, 14 Nov 2006 09:15:12 -0000 TB --- 2006-11-14 07:44:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-14 07:44:58 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-11-14 07:44:58 - cleaning the object tree TB --- 2006-11-14 07:45:38 - checking out the source tree TB --- 2006-11-14 07:45:38 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-11-14 07:45:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-14 07:56:21 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-14 07:56:21 - cd /src TB --- 2006-11-14 07:56:21 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 14 07:56:23 UTC 2006 >>> 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 Tue Nov 14 09:04:06 UTC 2006 TB --- 2006-11-14 09:04:06 - generating LINT kernel config TB --- 2006-11-14 09:04:06 - cd /src/sys/pc98/conf TB --- 2006-11-14 09:04:06 - /usr/bin/make -B LINT TB --- 2006-11-14 09:04:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-14 09:04:06 - cd /src TB --- 2006-11-14 09:04:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 14 09:04:07 UTC 2006 >>> 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 [...] nexus.o(.text+0x86a): In function `nexus_alloc_msix': : undefined reference to `msix_alloc' nexus.o(.text+0x8bd): In function `nexus_release_msix': : undefined reference to `msix_release' nexus.o(.text+0x8f6): In function `nexus_alloc_msi': : undefined reference to `msi_alloc' nexus.o(.text+0x950): In function `nexus_release_msi': : undefined reference to `msi_release' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-14 09:15:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-14 09:15:09 - ERROR: failed to build lint kernel TB --- 2006-11-14 09:15:09 - tinderbox aborted TB --- 0.67 user 2.05 system 5411.05 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 13:38:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A4FA16A492 for ; Tue, 14 Nov 2006 13:38:54 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D0F43D45 for ; Tue, 14 Nov 2006 13:38:52 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GjyUu-0007kk-TL for current@freebsd.org; Tue, 14 Nov 2006 15:38:47 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GjyUo-0001GX-O4 for current@freebsd.org; Tue, 14 Nov 2006 15:38:38 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Tue, 14 Nov 2006 15:38:38 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2192/Tue Nov 14 10:00:57 2006) Cc: Subject: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 13:38:54 -0000 Hi I have 2 servers each with 255 vlan interfaces and carp interfaces in each vlan.During the boot up while it's configuring the interfaces, it reliably panics. It boots fine if no network cables are plugged in (and in the test evironment on a quient lan). It's an SMP machine. My guess (from the panic message below) is that an arp query arives on an interface it's in the middle of creating or something like that (highly unsophisticated debugging conjecture). In the mean time I'm going to try a UP kernel and see if that masks the problem. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x5f fault code = supervisor read, page not present instruction pointer = 0x20:0xc058e18b stack pointer = 0x28:0xe34d9bb0 frame pointer = 0x28:0xe34d9c2c 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 = 14 (swi1: net) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c06830f9,e34d9a74,c04eff40,c0695d9f,0,...) at db_trace_sel f_wrapper+0x27 kdb_backtrace(c0695d9f,0,c067664b,e34d9a80,80,...) at kdb_backtrace+0x2f panic(c067664b,c0696cfe,c49135fc,1,1,...) at panic+0x129 trap_fatal(e34d9b70,5f,1,0,e34d9ae4,...) at trap_fatal+0x332 trap_pfault(e34d9b70,0,5f,b,5f,...) at trap_pfault+0x232 trap(c06e0008,c4910028,e34d0028,0,c4e57800,...) at trap+0x3cb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc058e18b, esp = 0xe34d9bb0, ebp = 0xe34d9c2c --- in_arpinput(c4fc3200,c04e3a0f,c06e5424,0,c4fc3200,...) at in_arpinput+0x123 arpintr(c4fc3200,c06e5424,0,c4914c40,e34d9c70,...) at arpintr+0xfb netisr_processqueue(c06ed4f8,c4914540,c4914c40,c4914c40,c4913460,...) at netisr_ processqueue+0xcc swi_net(0,c4914c40,246,0,c4914c40,...) at swi_net+0x125 ithread_execute_handlers(c4913460,c496e480,0,0,0,...) at ithread_execute_handler s+0x165 ithread_loop(c48f6810,e34d9d38,7fdec364,3ae77ec0,3940eec5,...) at ithread_loop+0 x64 fork_exit(c04d405d,c48f6810,e34d9d38) at fork_exit+0x83 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe34d9d6c, ebp = 0 --- Uptime: 9m35s Physical memory: 2039 MB Dumping 64 MB: 49 33 17 1 (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc04efc20 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 #2 0xc04effff in panic (fmt=0xc067664b "%s") at /usr/src/sys/kern/kern_shutdown.c:567 #3 0xc06508e3 in trap_fatal (frame=0xe34d9b70, eva=95) at /usr/src/sys/i386/i386/trap.c:869 #4 0xc065058d in trap_pfault (frame=0xe34d9b70, usermode=0, eva=95) at /usr/src/sys/i386/i386/trap.c:778 #5 0xc06500ff in trap (frame= {tf_fs = -1066532856, tf_es = -997130200, tf_ds = -481492952, tf_edi = 0, tf_esi = -991594496, tf_ebp = -481453012, tf_isp = -481453156, tf_ebx = 3, tf_edx = 314, tf_ecx = -1, tf_eax = -996395008, tf_trapno = 12, tf_err = 0, tf_eip = -1067916917, tf_cs = 32, tf_eflags = 66118, tf_esp = -481453064, tf_ss = -989906900}) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc063771a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc058e18b in in_arpinput (m=0xc4fc3200) at /usr/src/sys/netinet/if_ether.c:635 #8 0xc058e058 in arpintr (m=0xc4fc3200) at /usr/src/sys/netinet/if_ether.c:552 #9 0xc0586213 in netisr_processqueue (ni=0xc06ed4f8) at /usr/src/sys/net/netisr.c:236 #10 0xc0586464 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 #11 0xc04d3f7b in ithread_execute_handlers (p=0xc4913460, ie=0xc496e480) at /usr/src/sys/kern/kern_intr.c:666 ---Type to continue, or q to quit--- #12 0xc04d40c1 in ithread_loop (arg=0xc48f6810) at /usr/src/sys/kern/kern_intr.c:749 #13 0xc04d2914 in fork_exit (callout=0xc04d405d , arg=0xc49c3800, frame=0xc49c3800) at /usr/src/sys/kern/kern_fork.c:834 #14 0xc063777c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 (kgdb) frame 7 #7 0xc058e18b in in_arpinput (m=0xc4fc3200) at /usr/src/sys/netinet/if_ether.c:635 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || (kgdb) l 630 * is part of carp, we call carp_iamatch to see if this is a 631 * request for the virtual host ip. 632 * XXX: This is really ugly! 633 */ 634 LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) { 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || 636 (ia->ia_ifp == ifp)) && 637 itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) 638 goto match; 639 #ifdef DEV_CARP (kgdb) print bridged $1 = 0 (kgdb) print ia->ia_ifp There is no member named ia_ifp. (kgdb) print ia $2 = (struct in_ifaddr *) 0x3 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 13:53:14 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D544C16A415; Tue, 14 Nov 2006 13:53:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F49F43D88; Tue, 14 Nov 2006 13:53:10 +0000 (GMT) (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 97BBB46C31; Tue, 14 Nov 2006 08:53:09 -0500 (EST) Date: Tue, 14 Nov 2006 13:53:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20061114134411.X66346@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jmg@FreeBSD.org, jhb@FreeBSD.org Subject: Recent kernel hangs on HP DL145 servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 13:53:15 -0000 I updated two boxes to recent kernels from a kernel around October 7 or so, and they now both hang on boot if I have a Neterion 10gbps ethernet card in the PCIe slot. Since I don't have the driver loaded at boot, it seems more likely it's a kernel bug. Both identical machines now have the following vpd warning during boot, which wasn't present previously, but may be unrelated: miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:17:a4:ff:79:0d pcib3: at device 13.0 on pci0 pci3: on pcib3 pci3:0:0: bad VPD cksum, remain 14 bge1: mem 0xca100000-0xca10ffff irq 19 at device 0.0 on pci3 miibus1: on bge1 ... Then they wedge here: ... pcib4: at device 14.0 on pci0 pci4: on pcib4 pcib5: on acpi0 pci128: on pcib5 pcib6: at device 1.0 on pci128 pci129: on pcib6 Complete boot -v until the point of unhappiness below. Robert N M Watson Computer Laboratory University of Cambridge OK boot -sv GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=0000000000098800 SMAP type=02 base=0000000000098800 len=0000000000007800 SMAP type=02 base=00000000000c2000 len=000000000003e000 SMAP type=01 base=0000000000100000 len=00000000bfe20000 SMAP type=03 base=00000000bff20000 len=0000000000009000 SMAP type=04 base=00000000bff29000 len=0000000000057000 SMAP type=02 base=00000000bff80000 len=0000000000080000 SMAP type=02 base=00000000d8000000 len=0000000000000400 SMAP type=02 base=00000000d8001000 len=0000000000000400 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000000400 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff80000 len=0000000000080000 SMAP type=01 base=0000000100000000 len=0000000140000000 Copyright (c) 1992-2006 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 #5: Tue Nov 14 06:33:45 GMT 2006 root@noisier.cam.watson.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Using 16 colors for the VM-PQ tuning (1024, 16) Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80b67000. Calibrating clock(s) ... i8254 clock: 1193200 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2210192952 Hz CPU: Dual Core AMD Opteron(tm) Processor 275 (2210.19-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 HTT bit cleared - FreeBSD does not have licensing issues requiring it. Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 8576610304 (8179 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000094fff, 606208 bytes (148 pages) 0x0000000000c69000 - 0x00000000bff1ffff, 3207294976 bytes (783031 pages) 0x0000000100000000 - 0x000000022f177fff, 5085036544 bytes (1241464 pages) avail memory = 8281690112 (7898 MB) INTR: Adding local APIC 0 as a target ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Found IO APIC ID 5, Interrupt 24 at 0xd8000000 ioapic1: intpin 0 -> PCI IRQ 24 (level, low) ioapic1: intpin 1 -> PCI IRQ 25 (level, low) ioapic1: intpin 2 -> PCI IRQ 26 (level, low) ioapic1: intpin 3 -> PCI IRQ 27 (level, low) ioapic1: intpin 4 -> PCI IRQ 28 (level, low) ioapic1: intpin 5 -> PCI IRQ 29 (level, low) ioapic1: intpin 6 -> PCI IRQ 30 (level, low) MADT: Found IO APIC ID 6, Interrupt 31 at 0xd8001000 ioapic2: intpin 0 -> PCI IRQ 31 (level, low) ioapic2: intpin 1 -> PCI IRQ 32 (level, low) ioapic2: intpin 2 -> PCI IRQ 33 (level, low) ioapic2: intpin 3 -> PCI IRQ 34 (level, low) ioapic2: intpin 4 -> PCI IRQ 35 (level, low) ioapic2: intpin 5 -> PCI IRQ 36 (level, low) ioapic2: intpin 6 -> PCI IRQ 37 (level, low) MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic1: Routing NMI -> intpin 4 ioapic2: Routing NMI -> intpin 4 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-30 on motherboard ioapic2 irqs 31-37 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Nov 14 2006 06:32:52) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80801148 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=058000] [hdr=00] is there (id=005e10de) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 24 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 1 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 Validation 0 255 N 0 16 After Disable 0 255 N 0 16 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 17 Validation 0 255 N 0 17 After Disable 0 255 N 0 17 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 18 Validation 0 255 N 0 18 After Disable 0 255 N 0 18 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 19 Validation 0 255 N 0 19 After Disable 0 255 N 0 19 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 23 Validation 0 255 N 0 20 21 22 23 After Disable 0 255 N 0 20 21 22 23 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x10de, dev=0x005e, revid=0xa3 bus=0, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0051, revid=0xa3 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0x8c00, size 10, enabled found-> vendor=0x10de, dev=0x0052, revid=0xa2 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0, size 5, enabled map[20]: type 4, range 32, base 0x5000, size 6, enabled map[24]: type 4, range 32, base 0x5040, size 6, enabled found-> vendor=0x10de, dev=0x005a, revid=0xa2 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xc8000000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \_SB_.PCI0.LUS0:0) pci_link6: Picked IRQ 20 with weight 0 ioapic0: Changing polarity for pin 20 to high pcib0: slot 2 INTA routed to irq 20 via \_SB_.PCI0.LUS0 found-> vendor=0x10de, dev=0x005b, revid=0xa3 bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 0xc8001000, size 8, enabled pcib0: matched entry for 0.2.INTB (src \_SB_.PCI0.LUS2:0) pci_link7: Picked IRQ 21 with weight 0 ioapic0: Changing polarity for pin 21 to high pcib0: slot 2 INTB routed to irq 21 via \_SB_.PCI0.LUS2 found-> vendor=0x10de, dev=0x0053, revid=0xa2 bus=0, slot=6, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0x1400, size 4, enabled found-> vendor=0x10de, dev=0x0055, revid=0xa3 bus=0, slot=8, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0x1430, size 3, enabled map[14]: type 4, range 32, base 0x1424, size 2, enabled map[18]: type 4, range 32, base 0x1428, size 3, enabled map[1c]: type 4, range 32, base 0x1420, size 2, enabled map[20]: type 4, range 32, base 0x1410, size 4, enabled map[24]: type 1, range 32, base 0xc8002000, size 12, enabled pcib0: matched entry for 0.8.INTA (src \_SB_.PCI0.LSI1:0) pci_link9: Picked IRQ 22 with weight 0 ioapic0: Changing polarity for pin 22 to high pcib0: slot 8 INTA routed to irq 22 via \_SB_.PCI0.LSI1 found-> vendor=0x10de, dev=0x005c, revid=0xa2 bus=0, slot=9, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=25, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=25, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=25, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=25, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xc8000000-0xc8000fff irq 20 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc8000000 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 49 ohci0: [GIANT-LOCKED] 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: 4 ports with 4 removable, self powered ehci0: mem 0xc8001000-0xc80010ff irq 21 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xc8001000 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 device_attach: uhub1 attach returned 6 usb1: port 0, set config at addr 1 failed usb1: root hub problem, error=4 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1400 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=60 ostat1=70 ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=60 ostat1=70 ata1: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata1: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] atapci1: port 0x1430-0x1437,0x1424-0x1427,0x1428-0x142f,0x1420-0x1423,0x1410-0x141f mem 0xc8002000-0xc8002fff irq 22 at device 8.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1410 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53 atapci1: [MPSAFE] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xc8002000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1430 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1424 ata2: SATA connect ready time=0ms ata2: sata_connect devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x1428 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x1420 ata3: SATA connect ready time=0ms ata3: sata_connect devices=0x1 ata3: [MPSAFE] pcib1: at device 9.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xc9000000-0xc9ffffff pcib1: prefetched decode 0xd0000000-0xd7ffffff pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0110, revid=0xb2 bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xc9000000, size 24, enabled pcib1: requested memory range 0xc9000000-0xc9ffffff: good map[14]: type 3, range 32, base 0xd0000000, size 27, enabled pcib1: requested memory range 0xd0000000-0xd7ffffff: good pcib1: matched entry for 1.5.INTA (src \_SB_.PCI0.LNK1:0) pci_link0: Picked IRQ 16 with weight 0 ioapic0: Changing polarity for pin 16 to high pcib1: slot 5 INTA routed to irq 16 via \_SB_.PCI0.LNK1 vgapci0: mem 0xc9000000-0xc9ffffff,0xd0000000-0xd7ffffff irq 16 at device 5.0 on pci1 pcib2: at device 12.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xca000000-0xca0fffff pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 pci2:0:0: bad VPD cksum, remain 14 found-> vendor=0x14e4, dev=0x1659, revid=0x11 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 VPD Ident: Broadcom NetXtreme Gigabit Ethernet Controller MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base 0xca000000, size 16, enabled pcib2: requested memory range 0xca000000-0xca00ffff: good pcib2: matched entry for 2.0.INTA (src \_SB_.PCI0.LNK1:0) pcib2: slot 0 INTA routed to irq 16 via \_SB_.PCI0.LNK1 bge0: mem 0xca000000-0xca00ffff irq 16 at device 0.0 on pci2 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xca000000 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:17:a4:ff:79:0d ioapic0: routing intpin 16 (PCI IRQ 16) to vector 54 bge0: [MPSAFE] pcib3: at device 13.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xca100000-0xca1fffff pcib3: no prefetched decode pci3: on pcib3 pci3: physical bus=3 pci3:0:0: bad VPD cksum, remain 14 found-> vendor=0x14e4, dev=0x1659, revid=0x11 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 VPD Ident: Broadcom NetXtreme Gigabit Ethernet Controller MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base 0xca100000, size 16, enabled pcib3: requested memory range 0xca100000-0xca10ffff: good pcib3: matched entry for 3.0.INTA (src \_SB_.PCI0.LNK4:0) pci_link3: Picked IRQ 19 with weight 0 ioapic0: Changing polarity for pin 19 to high pcib3: slot 0 INTA routed to irq 19 via \_SB_.PCI0.LNK4 bge1: mem 0xca100000-0xca10ffff irq 19 at device 0.0 on pci3 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xca100000 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: bpf attached bge1: Ethernet address: 00:17:a4:ff:79:0c ioapic0: routing intpin 19 (PCI IRQ 19) to vector 55 bge1: [MPSAFE] pcib4: at device 14.0 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pci4: on pcib4 pci4: physical bus=4 pcib5: on acpi0 pcib5: could not get PCI interrupt routing table for \_SB_.PCI1 - AE_NOT_FOUND pci128: on pcib5 pci128: physical bus=128 found-> vendor=0x1022, dev=0x7458, revid=0x12 bus=128, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0157, statreg=0x0810, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x25 (9250 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7459, revid=0x12 bus=128, slot=1, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7458, revid=0x12 bus=128, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0157, statreg=0x0810, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x25 (9250 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7459, revid=0x12 bus=128, slot=2, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib6: at device 1.0 on pci128 pcib6: secondary bus 129 pcib6: subordinate bus 133 pcib6: I/O decode 0xf000-0xfff pcib6: prefetched decode 0xd8300000-0xd84fffff pci129: on pcib6 pci129: physical bus=129 From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 15:48:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36AE816A403; Tue, 14 Nov 2006 15:48:17 +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 C2C5343D80; Tue, 14 Nov 2006 15:48:07 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAEFm769082894; Tue, 14 Nov 2006 10:48:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAEFm7CJ070955; Tue, 14 Nov 2006 10:48:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ECD6A73068; Tue, 14 Nov 2006 10:48:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061114154806.ECD6A73068@freebsd-current.sentex.ca> Date: Tue, 14 Nov 2006 10:48:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 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: Tue, 14 Nov 2006 15:48:17 -0000 TB --- 2006-11-14 14:30:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-14 14:30:03 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-11-14 14:30:03 - cleaning the object tree TB --- 2006-11-14 14:30:47 - checking out the source tree TB --- 2006-11-14 14:30:47 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-11-14 14:30:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-14 14:41:26 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-14 14:41:26 - cd /src TB --- 2006-11-14 14:41:26 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 14 14:41:28 UTC 2006 >>> 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 Tue Nov 14 15:37:06 UTC 2006 TB --- 2006-11-14 15:37:06 - generating LINT kernel config TB --- 2006-11-14 15:37:06 - cd /src/sys/pc98/conf TB --- 2006-11-14 15:37:06 - /usr/bin/make -B LINT TB --- 2006-11-14 15:37:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-14 15:37:06 - cd /src TB --- 2006-11-14 15:37:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 14 15:37:06 UTC 2006 >>> 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 [...] nexus.o(.text+0x86a): In function `nexus_alloc_msix': : undefined reference to `msix_alloc' nexus.o(.text+0x8bd): In function `nexus_release_msix': : undefined reference to `msix_release' nexus.o(.text+0x8f6): In function `nexus_alloc_msi': : undefined reference to `msi_alloc' nexus.o(.text+0x950): In function `nexus_release_msi': : undefined reference to `msi_release' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-14 15:48:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-14 15:48:06 - ERROR: failed to build lint kernel TB --- 2006-11-14 15:48:06 - tinderbox aborted TB --- 0.61 user 2.07 system 4683.37 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 17:10:17 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2536716A4AB; Tue, 14 Nov 2006 17:10:17 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 641FB43D49; Tue, 14 Nov 2006 17:10:16 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (dbg0812vbdgi66gq@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id kAEHAFjp080025; Tue, 14 Nov 2006 09:10:15 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id kAEHAF3u080024; Tue, 14 Nov 2006 09:10:15 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Nov 2006 09:10:15 -0800 From: John-Mark Gurney To: Robert Watson Message-ID: <20061114171015.GT9291@funkthat.com> Mail-Followup-To: Robert Watson , current@FreeBSD.org, jhb@FreeBSD.org References: <20061114134411.X66346@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061114134411.X66346@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Recent kernel hangs on HP DL145 servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:10:17 -0000 Robert Watson wrote this message on Tue, Nov 14, 2006 at 13:53 +0000: > I updated two boxes to recent kernels from a kernel around October 7 or so, > and they now both hang on boot if I have a Neterion 10gbps ethernet card in > the PCIe slot. Since I don't have the driver loaded at boot, it seems more > likely it's a kernel bug. Both identical machines now have the following > vpd warning during boot, which wasn't present previously, but may be > unrelated: It's very likely you are plagued w/ non-standard PCI cards... I assume you mean Nov 7th? If so, there was fix committed for more normal bad VPD data (v1.321 of sys/dev/pci/pci.c)... There is still an outstanding bug of a device that doesn't even properly handle VPD accesses and it hang waiting for a bit to clear... I need to inspect the patch closer before committing.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 17:23:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9119016A403; Tue, 14 Nov 2006 17:23:46 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AE043D49; Tue, 14 Nov 2006 17:23:46 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk20f-0002rb-8r; Tue, 14 Nov 2006 17:23:45 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk1wY-0001KJ-O2; Tue, 14 Nov 2006 07:19:30 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17753.64161.965166.601002@roam.psg.com> Date: Tue, 14 Nov 2006 07:19:29 -1000 To: FreeBSD Current , freebsd-net@freebsd.org References: <17752.41644.706579.902238@roam.psg.com> Cc: Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:23:46 -0000 > FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 > > and for the last four or five days, fxp0 goes dead. it shows up > and active, but no packets move. > > down/up does not help. only way out has been reboot. > > suggestions on how to debug? this is killing me. noc woke me up twice in night to reboot the sucker. any clues? randy From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 17:38:17 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBBF916A403; Tue, 14 Nov 2006 17:38:17 +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 8614443D45; Tue, 14 Nov 2006 17:38:17 +0000 (GMT) (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 1B02E46C96; Tue, 14 Nov 2006 12:38:17 -0500 (EST) Date: Tue, 14 Nov 2006 17:38:16 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John-Mark Gurney In-Reply-To: <20061114171015.GT9291@funkthat.com> Message-ID: <20061114173539.X87081@fledge.watson.org> References: <20061114134411.X66346@fledge.watson.org> <20061114171015.GT9291@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Recent kernel hangs on HP DL145 servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 17:38:17 -0000 On Tue, 14 Nov 2006, John-Mark Gurney wrote: > Robert Watson wrote this message on Tue, Nov 14, 2006 at 13:53 +0000: >> I updated two boxes to recent kernels from a kernel around October 7 or so, >> and they now both hang on boot if I have a Neterion 10gbps ethernet card in >> the PCIe slot. Since I don't have the driver loaded at boot, it seems more >> likely it's a kernel bug. Both identical machines now have the following >> vpd warning during boot, which wasn't present previously, but may be >> unrelated: > > It's very likely you are plagued w/ non-standard PCI cards... > > I assume you mean Nov 7th? If so, there was fix committed for more normal > bad VPD data (v1.321 of sys/dev/pci/pci.c)... > > There is still an outstanding bug of a device that doesn't even properly > handle VPD accesses and it hang waiting for a bit to clear... I need to > inspect the patch closer before committing.. What I mean specifically is that the kernel dated October 7 works fine, and any more recent kernel hangs solidly if I boot it. Obviously, this is somewhat inconvenient. :-) The device in question is a PCI-X Neterion 10gbps card. The output from the kernel when the device driver is loaded is: Copyright(c) 2002-2005 Neterion Inc. xge0: mem 0xd8300000-0xd8307fff,0xd8400000-0xd84fffff,0xd8308000-0xd83087ff irq 25 at device 1.0 on pci129 xge0: Device is on 64 bit PCIX(M1) 133MHz bus If there's more information I can provide I'm happy to do so, just let me know what's needed. Is there a way I can disable vpd support at boot-time in some form -- i.e., via a tunable? It would be very useful if these machines worked. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 18:11:02 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DC0616A412 for ; Tue, 14 Nov 2006 18:11:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E1C343D7C for ; Tue, 14 Nov 2006 18:10:58 +0000 (GMT) (envelope-from 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 SDY38658; Tue, 14 Nov 2006 10:10:58 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id F1B9E45053; Tue, 14 Nov 2006 10:10:57 -0800 (PST) To: Robert Watson In-Reply-To: Your message of "Tue, 14 Nov 2006 17:38:16 GMT." <20061114173539.X87081@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1163527857_53581P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 14 Nov 2006 10:10:57 -0800 From: "Kevin Oberman" Message-Id: <20061114181057.F1B9E45053@ptavv.es.net> Cc: John-Mark Gurney , current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Recent kernel hangs on HP DL145 servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 18:11:02 -0000 --==_Exmh_1163527857_53581P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 14 Nov 2006 17:38:16 +0000 (GMT) > From: Robert Watson > Sender: owner-freebsd-current@freebsd.org > > On Tue, 14 Nov 2006, John-Mark Gurney wrote: > > > Robert Watson wrote this message on Tue, Nov 14, 2006 at 13:53 +0000: > >> I updated two boxes to recent kernels from a kernel around October 7 or so, > >> and they now both hang on boot if I have a Neterion 10gbps ethernet card in > >> the PCIe slot. Since I don't have the driver loaded at boot, it seems more > >> likely it's a kernel bug. Both identical machines now have the following > >> vpd warning during boot, which wasn't present previously, but may be > >> unrelated: > > > > It's very likely you are plagued w/ non-standard PCI cards... > > > > I assume you mean Nov 7th? If so, there was fix committed for more normal > > bad VPD data (v1.321 of sys/dev/pci/pci.c)... > > > > There is still an outstanding bug of a device that doesn't even properly > > handle VPD accesses and it hang waiting for a bit to clear... I need to > > inspect the patch closer before committing.. > > What I mean specifically is that the kernel dated October 7 works fine, and > any more recent kernel hangs solidly if I boot it. Obviously, this is > somewhat inconvenient. :-) > > The device in question is a PCI-X Neterion 10gbps card. The output from the > kernel when the device driver is loaded is: > > Copyright(c) 2002-2005 Neterion Inc. > xge0: mem > 0xd8300000-0xd8307fff,0xd8400000-0xd84fffff,0xd8308000-0xd83087ff irq 25 at > device 1.0 on pci129 > xge0: Device is on 64 bit PCIX(M1) 133MHz bus > > If there's more information I can provide I'm happy to do so, just let me know > what's needed. > > Is there a way I can disable vpd support at boot-time in some form -- i.e., > via a tunable? It would be very useful if these machines worked. The patch Ian Dowse submitted for this (which jmg is evaluating) has fixed the problem for at least two cases, my ancient Dell P3 and a newer ASUS A8V. It was posted back on 8 Nov. It simply adds a timeout for getting VPD info and lets the system proceed. Note that the last hunk is has been committed by jmg, so you only need the first two hunks. -- 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_1163527857_53581P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFFWgaxkn3rs5h7N1ERAkC/AKCeP5eSHdUHgiqonNtGZJrYCKNq5wCguYj1 fXhfhKJWf9KL7IJnaInCeeE= =80SS -----END PGP SIGNATURE----- --==_Exmh_1163527857_53581P-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 18:21:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C1E816A403; Tue, 14 Nov 2006 18:21: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 DA66F43D75; Tue, 14 Nov 2006 18:21:58 +0000 (GMT) (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 600DC46D8F; Tue, 14 Nov 2006 13:21:58 -0500 (EST) Date: Tue, 14 Nov 2006 18:21:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randy Bush In-Reply-To: <17753.64161.965166.601002@roam.psg.com> Message-ID: <20061114181823.K87081@fledge.watson.org> References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:21:59 -0000 On Tue, 14 Nov 2006, Randy Bush wrote: >> FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 >> >> and for the last four or five days, fxp0 goes dead. it shows up >> and active, but no packets move. >> >> down/up does not help. only way out has been reboot. >> >> suggestions on how to debug? > > this is killing me. noc woke me up twice in night to reboot the sucker. > any clues? Do you have serial console access to the box? The usual questions read: (1) When it's "dead", do interrupts still fire for the interface when packets go near by? See vmstat -i. (2) Does the driver think the link is still negotiated? What are the interface flags set to? See ifconfig. (3) When you run tcpdump on the interace, does it see packets from the outside world? (4) If you ping out the interface, does tcpdump see packets? Do you get ENOBUFS? Have ping send at least 256 packets. Do you get errors? Send to the broadcast address so that arp doesn't need to be working to transmit. (5) What does netstat -m show? (6) Any unusual dmesg output? In particular, any mention of fxp state changes or watchdogs firing? (7) Does lowering the interface, waiting ten seconds, then raising it help? Notice that these are all much easier if you have a serial console. If not, you might want to do the above using cron and a temporary file followed by a reboot. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 18:50:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5646B16A5D3 for ; Tue, 14 Nov 2006 18:50:28 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A46743D5C for ; Tue, 14 Nov 2006 18:50:26 +0000 (GMT) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id kAEIoMox009928; Tue, 14 Nov 2006 19:50:22 +0100 From: Pieter de Goeje To: pyunyh@gmail.com Date: Tue, 14 Nov 2006 19:50:22 +0100 User-Agent: KMail/1.9.4 References: <20061111011051.GB5233@cdnetworks.co.kr> <200611131637.57216.pieter@degoeje.nl> <20061114000103.GA5517@cdnetworks.co.kr> In-Reply-To: <20061114000103.GA5517@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611141950.22588.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Call for re(4) TSO/VLAN testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 18:50:28 -0000 On Tuesday 14 November 2006 01:01, Pyun YongHyeon wrote: > ATM re(4) uses still small number of Tx descriptors(i.e. 64 entries) > due to the hardware limitation of 8139C+. 8169 family can have > up to 1024 Tx descriptors. If we want to use more Tx descriptors > on 8169 the internal structure should be modified to support both > 8139C+ and 8169. I guess it would require major Tx path overhaul. > Because I have just plain PCI 8169 hardware I can't sure increasing > number of Tx descriptors on re(4) help Tx performance of the driver. So the 8169 has 64 Tx descriptors and the 8169S 1024? (dmesg 6-stable) re0: port 0xd000-0xd0ff mem 0xe8000000-0xe80000ff irq 17 at device 9.0 on pci0 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > I guess 64 Tx descriptors are not sufficient to saturate giga bit > link. > Would please try attached patch and report the performance of patched > re(4) driver? Where can I find this patch? Regards, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 18:51:49 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C66816A416; Tue, 14 Nov 2006 18:51:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB2A43D49; Tue, 14 Nov 2006 18:51:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0D0191A4D89; Tue, 14 Nov 2006 10:51:49 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E125B51341; Tue, 14 Nov 2006 13:51:37 -0500 (EST) Date: Tue, 14 Nov 2006 13:51:37 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20061114185137.GA88771@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: kib@FreeBSD.org Subject: leaked mountpoints after umount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Nov 2006 18:51:49 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sometimes after umounting a filesystem (maybe resulting in an error condition) it will remain listed in the mount table: dalki# mount -v /dev/da0s1a on / (ufs, local, fsid ba3af642adf91c2a) devfs on /dev (devfs, local, fsid 00ff000505000000) /dev/da0s1e on /d (ufs, local, soft-updates, fsid bb3af6420012cc6a) /dev/da0s1d on /usr (ufs, local, soft-updates, fsid bb3af64216b6e4d0) pfi.true.lv:/sdc1/dosirak on /data (nfs, fsid 01ff000202000000) haessal:/c/test on /haessal (nfs, read-only, fsid c7ff560202000000) dalki# umount -f c7ff560202000000 umount: unmount of /haessal failed: No such file or directory umount: retrying using path instead of file system ID umount: unmount of /haessal failed: No such file or directory dalki# mount -v /dev/da0s1a on / (ufs, local, fsid ba3af642adf91c2a) devfs on /dev (devfs, local, fsid 00ff000505000000) /dev/da0s1e on /d (ufs, local, soft-updates, fsid bb3af6420012cc6a) /dev/da0s1d on /usr (ufs, local, soft-updates, fsid bb3af64216b6e4d0) pfi.true.lv:/sdc1/dosirak on /data (nfs, fsid 01ff000202000000) haessal:/c/test on /haessal (nfs, read-only, fsid c7ff560202000000) It is not actually mounted (/haessal is the underlying UFS directory), but it cannot be purged from the mount table. Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWhA5Wry0BWjoQKURAgukAJ0URcvtNMPddGNljINaVe4wqMOcmwCfTZoI U8yO78d6tdY1qGmOK2/R9zY= =024I -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 23:43:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68D8916A415; Tue, 14 Nov 2006 23:43:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB48243D53; Tue, 14 Nov 2006 23:43:40 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7wK-00056s-1u; Tue, 14 Nov 2006 23:43:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7pu-0001h2-BM; Tue, 14 Nov 2006 13:37:02 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17754.21277.210338.175055@roam.psg.com> Date: Tue, 14 Nov 2006 13:37:01 -1000 To: Robert Watson References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> <20061114181823.K87081@fledge.watson.org> Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 23:43:41 -0000 Mike Tancsa suggested i try ifconfig fxp0 media 10baseT/UTP ifconfig fxp0 media autoselect this worked! i will next reboot with in_fxp.c reverted to pre 2006.10.06. but first i did the suggested analysis, which follows. > (1) When it's "dead", do interrupts still fire for the interface when packets > go near by? See vmstat -i. nope > (2) Does the driver think the link is still negotiated? What are the > interface flags set to? See ifconfig. same as in first post on this whine # ifconfig fxp0 fxp0: flags=8843 mtu 1500 options=8 inet 147.28.0.39 netmask 0xffffff00 broadcast 147.28.0.255 inet 147.28.0.40 netmask 0xffffffff broadcast 147.28.0.40 ether 00:30:48:51:c8:5e media: Ethernet 100baseTX status: active > (3) When you run tcpdump on the interace, does it see packets from the > outside world? nope. only this interface issuing arp requests etc. > (4) If you ping out the interface, does tcpdump see packets? Do you get > ENOBUFS? Have ping send at least 256 packets. Do you get errors? Send > to the broadcast address so that arp doesn't need to be working to > transmit. fun one as, when it is in this state, i have only serial access through the craft port. this machine is 4000km away in a rack. so i nohupped and backgrounded the pinger, and watched tcpdump. nohup.out showed zero response ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down PING 147.28.0.35 (147.28.0.35): 56 data bytes --- 147.28.0.35 ping statistics --- 325 packets transmitted, 0 packets received, 100.0% packet loss tcpdump showed only the arp requests 23:32:41.459630 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:42.460575 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:43.461486 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:44.462426 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:45.463347 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:46.464279 arp who-has 147.28.0.35 tell 147.28.0.39 > (5) What does netstat -m show? # netstat -m 132/693/825 mbufs in use (current/cache/total) 128/262/390/17088 mbuf clusters in use (current/cache/total/max) 128/256 mbuf+clusters out of packet secondary zone in use (current/cache) 0/28/28/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 289K/809K/1098K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 30 requests for I/O initiated by sendfile 0 calls to protocol drain routines > (6) Any unusual dmesg output? In particular, any mention of fxp state > changes or watchdogs firing? nope # dmesg | grep fxp fxp0: port 0x9800-0x983f mem 0xe2203000-0xe2203fff,0xe2100000-0xe21fffff irq 5 at device 6.0 on pci2 miibus0: on fxp0 fxp0: Ethernet address: 00:30:48:51:c8:5e fxp1: port 0x9c00-0x9c3f mem 0xe2201000-0xe2201fff,0xe2000000-0xe20fffff irq 12 at device 7.0 on pci2 miibus1: on fxp1 fxp1: Ethernet address: 00:30:48:51:c8:5f fxp0: link state changed to UP fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled > (7) Does lowering the interface, waiting ten seconds, then raising it > help? nope > Notice that these are all much easier if you have a serial console. well, most of them are :). > If not, you might want to do the above using cron and a temporary file > followed by a reboot. :-) i hope to do better than that :) randy From owner-freebsd-current@FreeBSD.ORG Tue Nov 14 23:49:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9728C16A415 for ; Tue, 14 Nov 2006 23:49:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC1743D98 for ; Tue, 14 Nov 2006 23:49:01 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id h30so4189wxd for ; Tue, 14 Nov 2006 15:49:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=MoiGHw0SSwsA1OE19HGpHByfKRBh4t2TO39vN3fcr5FgEsKpam+nluMlE9tltKbIvCmIRsiNNSXazbDpGMBuLh5Ib7XUCk+B9XwODgzs9+rVDgHNJCF+sST54R9Pn0e/pJAvJ+xZp+753tFDeU6HN99T4Im2AHg6f/o3vK1PA58= Received: by 10.70.116.1 with SMTP id o1mr1696972wxc.1163547508243; Tue, 14 Nov 2006 15:38:28 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 34sm34423wra.2006.11.14.15.38.26; Tue, 14 Nov 2006 15:38:27 -0800 (PST) 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 kAENFJqH009670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 08:15:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kAENFHJS009669; Wed, 15 Nov 2006 08:15:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 15 Nov 2006 08:15:17 +0900 From: Pyun YongHyeon To: Pieter de Goeje Message-ID: <20061114231517.GA9581@cdnetworks.co.kr> References: <20061111011051.GB5233@cdnetworks.co.kr> <200611131637.57216.pieter@degoeje.nl> <20061114000103.GA5517@cdnetworks.co.kr> <200611141950.22588.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <200611141950.22588.pieter@degoeje.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for re(4) TSO/VLAN testers 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: Tue, 14 Nov 2006 23:49:22 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 14, 2006 at 07:50:22PM +0100, Pieter de Goeje wrote: > On Tuesday 14 November 2006 01:01, Pyun YongHyeon wrote: > > ATM re(4) uses still small number of Tx descriptors(i.e. 64 entries) > > due to the hardware limitation of 8139C+. 8169 family can have > > up to 1024 Tx descriptors. If we want to use more Tx descriptors > > on 8169 the internal structure should be modified to support both > > 8139C+ and 8169. I guess it would require major Tx path overhaul. > > Because I have just plain PCI 8169 hardware I can't sure increasing > > number of Tx descriptors on re(4) help Tx performance of the driver. > > So the 8169 has 64 Tx descriptors and the 8169S 1024? > All 8169 chipsets support 1024 Tx descriptors. > (dmesg 6-stable) > re0: port 0xd000-0xd0ff mem > 0xe8000000-0xe80000ff irq 17 at device 9.0 on pci0 > miibus0: on re0 > rgephy0: on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > > > I guess 64 Tx descriptors are not sufficient to saturate giga bit > > link. > > Would please try attached patch and report the performance of patched > > re(4) driver? > > Where can I find this patch? > Attached. -- Regards, Pyun YongHyeon --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_rlreg.patch2" Index: if_rlreg.h =================================================================== RCS file: /pool/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.60 diff -u -r1.60 if_rlreg.h --- if_rlreg.h 1 Aug 2006 17:18:25 -0000 1.60 +++ if_rlreg.h 14 Nov 2006 23:13:33 -0000 @@ -541,6 +541,7 @@ #define RL_TDESC_CMD_UDPCSUM 0x00020000 /* UDP checksum enable */ #define RL_TDESC_CMD_IPCSUM 0x00040000 /* IP header checksum enable */ #define RL_TDESC_CMD_MSSVAL 0x07FF0000 /* Large send MSS value */ +#define RL_TDESC_CMD_MSSVAL_SHIFT 16 /* Large send MSS value shift */ #define RL_TDESC_CMD_LGSEND 0x08000000 /* TCP large send enb */ #define RL_TDESC_CMD_EOF 0x10000000 /* end of frame marker */ #define RL_TDESC_CMD_SOF 0x20000000 /* start of frame marker */ @@ -637,12 +638,12 @@ * due to the 8139C+. We need to put the number of descriptors in the ring * structure and use that value instead. */ -#if !defined(__i386__) && !defined(__amd64__) +#ifndef __NO_STRICT_ALIGNMENT #define RE_FIXUP_RX 1 #endif -#define RL_TX_DESC_CNT 64 -#define RL_RX_DESC_CNT RL_TX_DESC_CNT +#define RL_TX_DESC_CNT 256 +#define RL_RX_DESC_CNT 64 #define RL_RX_LIST_SZ (RL_RX_DESC_CNT * sizeof(struct rl_desc)) #define RL_TX_LIST_SZ (RL_TX_DESC_CNT * sizeof(struct rl_desc)) --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 00:06:03 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 876C916A5A9 for ; Wed, 15 Nov 2006 00:06:03 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 107CA43D46 for ; Wed, 15 Nov 2006 00:06:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E901C1A3C1E for ; Tue, 14 Nov 2006 16:06:02 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 50EF65138B; Tue, 14 Nov 2006 19:05:51 -0500 (EST) Date: Tue, 14 Nov 2006 19:05:51 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20061115000551.GA93547@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: ipfw breaks nfs over udp6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 00:06:03 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have ipfw enabled but with only the allow all rule set: haessal# ipfw show 65535 4146880 1816192333 allow ip from any to any I tried to mount nfs over udp6 from a local host, but nfs traffic makes ipfw cry: ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ... and nfs traffic is wedged. Kris --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWlneWry0BWjoQKURAvb/AKDm+DwPDpKIIIOI94MQNmla/cSjrACg6mR0 xOQ5bhexJQlEnvQrph+lVkc= =agsA -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 00:36:30 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 771EB16A407 for ; Wed, 15 Nov 2006 00:36:30 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24AD643D78 for ; Wed, 15 Nov 2006 00:36:26 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout12/MantshX 4.0) with ESMTP id kAF0aPaQ015972; Tue, 14 Nov 2006 16:36:25 -0800 (PST) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kAF0aMh1008033; Tue, 14 Nov 2006 16:36:24 -0800 (PST) In-Reply-To: <20061115000551.GA93547@xor.obsecurity.org> References: <20061115000551.GA93547@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <393E4E9D-3E77-4302-A6EE-FEE8212093A3@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 14 Nov 2006 16:36:21 -0800 To: Kris Kennaway X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: current@FreeBSD.org Subject: Re: ipfw breaks nfs over udp6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 00:36:30 -0000 On Nov 14, 2006, at 4:05 PM, Kris Kennaway wrote: > haessal# ipfw show > 65535 4146880 1816192333 allow ip from any to any > > I tried to mount nfs over udp6 from a local host, but nfs traffic > makes ipfw cry: > > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > ... > > and nfs traffic is wedged. Interesting. The "pullup failed" message means that IPFW didn't think it got enough data in the packet to produce a valid log message; perhaps something isn't determining the size of IPv6 packet headers properly...? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 04:10:33 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A2DD16A4C8 for ; Wed, 15 Nov 2006 04:10:33 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD6C43D58 for ; Wed, 15 Nov 2006 04:10:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id CBE891A3C1C for ; Tue, 14 Nov 2006 20:10:32 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6C45E51322; Tue, 14 Nov 2006 23:10:21 -0500 (EST) Date: Tue, 14 Nov 2006 23:10:21 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20061115041021.GA97078@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: kern.pts.enable=1 forces tcsh autologout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 04:10:33 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline When kern.pts.enable=1, the ptys are named /dev/pts/, and tcsh doesn't correctly recognize that it's a pty and it should disable autologout. Actually it does seem to have some code but it seems to be incorrect: if (loginsh || (uid == 0)) { if (*cp) { /* only for login shells or root and we must have a tty */ if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { cp = cp2 + 1; } else cp2 = cp; if (!(((Strncmp(cp2, STRtty, 3) == 0) && Isalpha(cp2[3])) || ((Strncmp(cp, STRpts, 3) == 0) && cp[3] == '/'))) { if (getenv("DISPLAY") == NULL) { /* NOT on X window shells */ set(STRautologout, Strsave(STRdefautologout), VAR_READWRITE); } } } } Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWpMsWry0BWjoQKURAoJqAKCHMvd6rli9TYTqIocqC+1D9Ec3WgCaA1ga foY4eOCvMZKA044s4VMXOaA= =sY6f -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 04:55:37 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E15316A407 for ; Wed, 15 Nov 2006 04:55:37 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFD8C43D45 for ; Wed, 15 Nov 2006 04:55:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 919AB1A3C19 for ; Tue, 14 Nov 2006 20:55:36 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F40E7514CB; Tue, 14 Nov 2006 23:55:24 -0500 (EST) Date: Tue, 14 Nov 2006 23:55:24 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20061115045524.GA97535@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: sysctl -a panic from kern.pts.enable=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 04:55:37 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I ran sysctl -a (in the context of looking up the correct name for kern.pts.enable, per previous email) and got a panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0xcbe8d900 fault code = supervisor read, page not present instruction pointer = 0x20:0xc04dd0af stack pointer = 0x28:0xed76baa8 frame pointer = 0x28:0xed76baa8 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 = 23312 (sysctl) [thread pid 23312 tid 101060 ] Stopped at dev2udev+0xf: movl 0(%edx),%eax db> wh Tracing pid 23312 tid 101060 td 0xc5c981c0 dev2udev(cbe8d900,88,c0743823,bf4,88,...) at dev2udev+0xf sysctl_kern_ttys(c077f520,0,0,ed76bba4,ed76bba4,...) at sysctl_kern_ttys+0xc4 sysctl_root(0,ed76bc14,2,ed76bba4,c5c981c0,...) at sysctl_root+0x174 userland_sysctl(c5c981c0,ed76bc14,2,0,bfbfd63c,...) at userland_sysctl+0x13c __sysctl(c5c981c0,ed76bd04,18,1,c5c981c0,...) at __sysctl+0xb7 syscall(bfbf003b,bfbf003b,bfbf003b,bfbfd63c,bfbfdf00,...) at syscall+0x2e3 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28146ac3, esp = 0xbfbfd5bc, ebp = 0xbfbfd5e8 --- #10 0xc04dd0af in dev2udev (x=0xcbe8d900) at ../../../fs/devfs/devfs_vnops.c:1296 #11 0xc0575874 in sysctl_kern_ttys (oidp=0xc077f520, arg1=0x0, arg2=0, req=0xed76bba4) at ../../../kern/tty.c:3030 #12 0xc0538f24 in sysctl_root (oidp=0x0, arg1=0x0, arg2=0, req=0xed76bba4) at ../../../kern/kern_sysctl.c:1282 #13 0xc05391ac in userland_sysctl (td=0xffffffff, name=0xed76bc14, namelen=2, old=0xed76bba4, oldlenp=0xbfbfd63c, inkernel=0, new=0x0, newlen=4294967295, retval=0xed76bc10, flags=-1) at ../../../kern/kern_sysctl.c:1381 #14 0xc0538ff7 in __sysctl (td=0xffffffff, uap=0xed76bd04) at ../../../kern/kern_sysctl.c:1316 #15 0xc06fa643 in syscall (frame= {tf_fs = -1078001605, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = -1077946820, tf_esi = -1077944576, tf_ebp = -1077946904, tf_isp = -310985372, tf_ebx = 672598776, tf_edx = 0, tf_ecx = 0, tf_eax = 202, tf_trapno = 0, tf_err = 2, tf_eip = 672426691, tf_cs = 51, tf_eflags = 663, tf_esp = -1077946948, tf_ss = 59}) at ../../../i386/i386/trap.c:1010 #16 0xc06e0d6f in Xint0x80_syscall () at ../../../i386/i386/exception.s:191 (kgdb) frame 10 #10 0xc04dd0af in dev2udev (x=0xcbe8d900) at ../../../fs/devfs/devfs_vnops.c:1296 1296 if (x == NULL) (kgdb) print *x Cannot access memory at address 0xcbe8d900 kern.pts.enable=1 on this machine which may be relevant, I think the tty disappeared while kern.ttys was walking it. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWp28Wry0BWjoQKURAtfxAJ4jUvO41xf8alceMrAnrm/100YJhQCdFY97 SJccYmIZ3o6+VcNbN8tGQh4= =oOUk -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 05:57:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C3B716A47C for ; Wed, 15 Nov 2006 05:57:48 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E452243D60 for ; Wed, 15 Nov 2006 05:57:43 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GkDmG-0005wh-Ok for current@freebsd.org; Wed, 15 Nov 2006 07:57:41 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkDmG-0000cE-AZ for current@freebsd.org; Wed, 15 Nov 2006 07:57:40 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Tue, 14 Nov 2006 15:38:38 +0200." X-Attribution: BOFH Date: Wed, 15 Nov 2006 07:57:40 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2195/Tue Nov 14 21:53:04 2006) Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 05:57:48 -0000 Ian FREISLICH wrote: > Hi > > I have 2 servers each with 255 vlan interfaces and carp interfaces > in each vlan.During the boot up while it's configuring the interfaces, > it reliably panics. It boots fine if no network cables are plugged > in (and in the test evironment on a quient lan). > > It's an SMP machine. My guess (from the panic message below) is > that an arp query arives on an interface it's in the middle of > creating or something like that (highly unsophisticated debugging > conjecture). > > In the mean time I'm going to try a UP kernel and see if that masks > the problem. FWIW, a UP kernel has the same problem. > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x5f > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc058e18b > stack pointer = 0x28:0xe34d9bb0 > frame pointer = 0x28:0xe34d9c2c > 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 = 14 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c06830f9,e34d9a74,c04eff40,c0695d9f,0,...) at db_trace_ sel > f_wrapper+0x27 > kdb_backtrace(c0695d9f,0,c067664b,e34d9a80,80,...) at kdb_backtrace+0x2f > panic(c067664b,c0696cfe,c49135fc,1,1,...) at panic+0x129 > trap_fatal(e34d9b70,5f,1,0,e34d9ae4,...) at trap_fatal+0x332 > trap_pfault(e34d9b70,0,5f,b,5f,...) at trap_pfault+0x232 > trap(c06e0008,c4910028,e34d0028,0,c4e57800,...) at trap+0x3cb > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc058e18b, esp = 0xe34d9bb0, ebp = 0xe34d9c2c --- > in_arpinput(c4fc3200,c04e3a0f,c06e5424,0,c4fc3200,...) at in_arpinput+0x123 > arpintr(c4fc3200,c06e5424,0,c4914c40,e34d9c70,...) at arpintr+0xfb > netisr_processqueue(c06ed4f8,c4914540,c4914c40,c4914c40,c4913460,...) at neti sr_ > processqueue+0xcc > swi_net(0,c4914c40,246,0,c4914c40,...) at swi_net+0x125 > ithread_execute_handlers(c4913460,c496e480,0,0,0,...) at ithread_execute_hand ler > s+0x165 > ithread_loop(c48f6810,e34d9d38,7fdec364,3ae77ec0,3940eec5,...) at ithread_loo p+0 > x64 > fork_exit(c04d405d,c48f6810,e34d9d38) at fork_exit+0x83 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe34d9d6c, ebp = 0 --- > Uptime: 9m35s > Physical memory: 2039 MB > Dumping 64 MB: 49 33 17 1 > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc04efc20 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 > #2 0xc04effff in panic (fmt=0xc067664b "%s") > at /usr/src/sys/kern/kern_shutdown.c:567 > #3 0xc06508e3 in trap_fatal (frame=0xe34d9b70, eva=95) > at /usr/src/sys/i386/i386/trap.c:869 > #4 0xc065058d in trap_pfault (frame=0xe34d9b70, usermode=0, eva=95) > at /usr/src/sys/i386/i386/trap.c:778 > #5 0xc06500ff in trap (frame= > {tf_fs = -1066532856, tf_es = -997130200, tf_ds = -481492952, tf_edi = 0, tf_esi = -991594496, tf_ebp = -481453012, tf_isp = -481453156, tf_ebx = 3, t f_edx = 314, tf_ecx = -1, tf_eax = -996395008, tf_trapno = 12, tf_err = 0, tf_e ip = -1067916917, tf_cs = 32, tf_eflags = 66118, tf_esp = -481453064, tf_ss = - 989906900}) at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc063771a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #7 0xc058e18b in in_arpinput (m=0xc4fc3200) > at /usr/src/sys/netinet/if_ether.c:635 > #8 0xc058e058 in arpintr (m=0xc4fc3200) > at /usr/src/sys/netinet/if_ether.c:552 > #9 0xc0586213 in netisr_processqueue (ni=0xc06ed4f8) > at /usr/src/sys/net/netisr.c:236 > #10 0xc0586464 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 > #11 0xc04d3f7b in ithread_execute_handlers (p=0xc4913460, ie=0xc496e480) > at /usr/src/sys/kern/kern_intr.c:666 > ---Type to continue, or q to quit--- > #12 0xc04d40c1 in ithread_loop (arg=0xc48f6810) > at /usr/src/sys/kern/kern_intr.c:749 > #13 0xc04d2914 in fork_exit (callout=0xc04d405d , > arg=0xc49c3800, frame=0xc49c3800) at /usr/src/sys/kern/kern_fork.c:834 > #14 0xc063777c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:19 9 > (kgdb) frame 7 > #7 0xc058e18b in in_arpinput (m=0xc4fc3200) > at /usr/src/sys/netinet/if_ether.c:635 > 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || > (kgdb) l > 630 * is part of carp, we call carp_iamatch to see if this is a > 631 * request for the virtual host ip. > 632 * XXX: This is really ugly! > 633 */ > 634 LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) { > 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || > 636 (ia->ia_ifp == ifp)) && > 637 itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) > 638 goto match; > 639 #ifdef DEV_CARP > (kgdb) print bridged > $1 = 0 > (kgdb) print ia->ia_ifp > There is no member named ia_ifp. > (kgdb) print ia > $2 = (struct in_ifaddr *) 0x3 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 07:24:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2650F16A403 for ; Wed, 15 Nov 2006 07:24:38 +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 D248643D64 for ; Wed, 15 Nov 2006 07:24:37 +0000 (GMT) (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 47C9146BC2; Wed, 15 Nov 2006 02:24:37 -0500 (EST) Date: Wed, 15 Nov 2006 07:24:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ian FREISLICH In-Reply-To: Message-ID: <20061115072404.C79655@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 07:24:38 -0000 On Wed, 15 Nov 2006, Ian FREISLICH wrote: > Ian FREISLICH wrote: >> >> I have 2 servers each with 255 vlan interfaces and carp interfaces in each >> vlan.During the boot up while it's configuring the interfaces, it reliably >> panics. It boots fine if no network cables are plugged in (and in the test >> evironment on a quient lan). >> >> It's an SMP machine. My guess (from the panic message below) is that an >> arp query arives on an interface it's in the middle of creating or >> something like that (highly unsophisticated debugging conjecture). >> >> In the mean time I'm going to try a UP kernel and see if that masks the >> problem. > > FWIW, a UP kernel has the same problem. What happens if you disable PREEMPTION on UP and try the same thing again? Robert N M Watson Computer Laboratory University of Cambridge > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x5f >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc058e18b >> stack pointer = 0x28:0xe34d9bb0 >> frame pointer = 0x28:0xe34d9c2c >> 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 = 14 (swi1: net) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c06830f9,e34d9a74,c04eff40,c0695d9f,0,...) at db_trace_ > sel >> f_wrapper+0x27 >> kdb_backtrace(c0695d9f,0,c067664b,e34d9a80,80,...) at kdb_backtrace+0x2f >> panic(c067664b,c0696cfe,c49135fc,1,1,...) at panic+0x129 >> trap_fatal(e34d9b70,5f,1,0,e34d9ae4,...) at trap_fatal+0x332 >> trap_pfault(e34d9b70,0,5f,b,5f,...) at trap_pfault+0x232 >> trap(c06e0008,c4910028,e34d0028,0,c4e57800,...) at trap+0x3cb >> calltrap() at calltrap+0x5 >> --- trap 0xc, eip = 0xc058e18b, esp = 0xe34d9bb0, ebp = 0xe34d9c2c --- >> in_arpinput(c4fc3200,c04e3a0f,c06e5424,0,c4fc3200,...) at in_arpinput+0x123 >> arpintr(c4fc3200,c06e5424,0,c4914c40,e34d9c70,...) at arpintr+0xfb >> netisr_processqueue(c06ed4f8,c4914540,c4914c40,c4914c40,c4913460,...) at neti > sr_ >> processqueue+0xcc >> swi_net(0,c4914c40,246,0,c4914c40,...) at swi_net+0x125 >> ithread_execute_handlers(c4913460,c496e480,0,0,0,...) at ithread_execute_hand > ler >> s+0x165 >> ithread_loop(c48f6810,e34d9d38,7fdec364,3ae77ec0,3940eec5,...) at ithread_loo > p+0 >> x64 >> fork_exit(c04d405d,c48f6810,e34d9d38) at fork_exit+0x83 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0x1, eip = 0, esp = 0xe34d9d6c, ebp = 0 --- >> Uptime: 9m35s >> Physical memory: 2039 MB >> Dumping 64 MB: 49 33 17 1 >> (kgdb) bt >> #0 doadump () at pcpu.h:166 >> #1 0xc04efc20 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 >> #2 0xc04effff in panic (fmt=0xc067664b "%s") >> at /usr/src/sys/kern/kern_shutdown.c:567 >> #3 0xc06508e3 in trap_fatal (frame=0xe34d9b70, eva=95) >> at /usr/src/sys/i386/i386/trap.c:869 >> #4 0xc065058d in trap_pfault (frame=0xe34d9b70, usermode=0, eva=95) >> at /usr/src/sys/i386/i386/trap.c:778 >> #5 0xc06500ff in trap (frame= >> {tf_fs = -1066532856, tf_es = -997130200, tf_ds = -481492952, tf_edi = > 0, tf_esi = -991594496, tf_ebp = -481453012, tf_isp = -481453156, tf_ebx = 3, t > f_edx = 314, tf_ecx = -1, tf_eax = -996395008, tf_trapno = 12, tf_err = 0, tf_e > ip = -1067916917, tf_cs = 32, tf_eflags = 66118, tf_esp = -481453064, tf_ss = - > 989906900}) at /usr/src/sys/i386/i386/trap.c:463 >> #6 0xc063771a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 >> #7 0xc058e18b in in_arpinput (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:635 >> #8 0xc058e058 in arpintr (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:552 >> #9 0xc0586213 in netisr_processqueue (ni=0xc06ed4f8) >> at /usr/src/sys/net/netisr.c:236 >> #10 0xc0586464 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 >> #11 0xc04d3f7b in ithread_execute_handlers (p=0xc4913460, ie=0xc496e480) >> at /usr/src/sys/kern/kern_intr.c:666 >> ---Type to continue, or q to quit--- >> #12 0xc04d40c1 in ithread_loop (arg=0xc48f6810) >> at /usr/src/sys/kern/kern_intr.c:749 >> #13 0xc04d2914 in fork_exit (callout=0xc04d405d , >> arg=0xc49c3800, frame=0xc49c3800) at /usr/src/sys/kern/kern_fork.c:834 >> #14 0xc063777c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:19 > 9 >> (kgdb) frame 7 >> #7 0xc058e18b in in_arpinput (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:635 >> 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || >> (kgdb) l >> 630 * is part of carp, we call carp_iamatch to see if this is a >> 631 * request for the virtual host ip. >> 632 * XXX: This is really ugly! >> 633 */ >> 634 LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) { >> 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || >> 636 (ia->ia_ifp == ifp)) && >> 637 itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) >> 638 goto match; >> 639 #ifdef DEV_CARP >> (kgdb) print bridged >> $1 = 0 >> (kgdb) print ia->ia_ifp >> There is no member named ia_ifp. >> (kgdb) print ia >> $2 = (struct in_ifaddr *) 0x3 > > Ian > > -- > 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 Wed Nov 15 08:49:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2457916A415; Wed, 15 Nov 2006 08:49:51 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4227A43D5A; Wed, 15 Nov 2006 08:49:47 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GkGSl-0003bq-C8; Wed, 15 Nov 2006 10:49:43 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkGSk-0000qv-6Y; Wed, 15 Nov 2006 10:49:42 +0200 To: Robert Watson From: Ian FREISLICH In-Reply-To: Message from Robert Watson of "Wed, 15 Nov 2006 07:24:37 GMT." <20061115072404.C79655@fledge.watson.org> X-Attribution: BOFH Date: Wed, 15 Nov 2006 10:49:42 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2195/Tue Nov 14 21:53:04 2006) Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 08:49:51 -0000 Robert Watson wrote: > On Wed, 15 Nov 2006, Ian FREISLICH wrote: > > > Ian FREISLICH wrote: > >> > >> I have 2 servers each with 255 vlan interfaces and carp interfaces > >> in each vlan.During the boot up while it's configuring the > >> interfaces, it reliably panics. It boots fine if no network cables > >> are plugged in (and in the test evironment on a quient lan). > >> > >> It's an SMP machine. My guess (from the panic message below) is > >> that an arp query arives on an interface it's in the middle of > >> creating or something like that (highly unsophisticated debugging > >> conjecture). > >> > >> In the mean time I'm going to try a UP kernel and see if that masks > >> the problem. > > > > FWIW, a UP kernel has the same problem. > > What happens if you disable PREEMPTION on UP and try the same thing > again? Same thing. If I don't assign the carp interfaces a vhid and pass at boot time, it boots up OK, but I need the carp interfaces. I can arrange serial console access. I have a similar system from ~"Tue Aug 29 09:47:50 SAST 2006" that works, but I suspect it may suffer the same problem. I'm about to test this. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 09:03:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89A6816A40F for ; Wed, 15 Nov 2006 09:03:29 +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 4455043D4C for ; Wed, 15 Nov 2006 09:03:29 +0000 (GMT) (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 DC68546B46; Wed, 15 Nov 2006 04:03:28 -0500 (EST) Date: Wed, 15 Nov 2006 09:03:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ian FREISLICH In-Reply-To: Message-ID: <20061115085427.R79655@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 09:03:29 -0000 On Wed, 15 Nov 2006, Ian FREISLICH wrote: > Robert Watson wrote: >> On Wed, 15 Nov 2006, Ian FREISLICH wrote: >> >>> Ian FREISLICH wrote: >>>> >>>> I have 2 servers each with 255 vlan interfaces and carp interfaces in >>>> each vlan.During the boot up while it's configuring the interfaces, it >>>> reliably panics. It boots fine if no network cables are plugged in (and >>>> in the test evironment on a quient lan). >>>> >>>> It's an SMP machine. My guess (from the panic message below) is that an >>>> arp query arives on an interface it's in the middle of creating or >>>> something like that (highly unsophisticated debugging conjecture). >>>> >>>> In the mean time I'm going to try a UP kernel and see if that masks the >>>> problem. >>> >>> FWIW, a UP kernel has the same problem. >> >> What happens if you disable PREEMPTION on UP and try the same thing again? > > Same thing. > > If I don't assign the carp interfaces a vhid and pass at boot time, it boots > up OK, but I need the carp interfaces. I can arrange serial console access. > I have a similar system from ~"Tue Aug 29 09:47:50 SAST 2006" that works, > but I suspect it may suffer the same problem. I'm about to test this. This suggests that it is not the race I was worried it was, which is really good news :-). This makes me suspect a CARP-specific bug as opposed to the wider issue of under-synchronization of the address lists. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 09:38:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C29C16A49E; Wed, 15 Nov 2006 09:38:29 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B745343D8A; Wed, 15 Nov 2006 09:35:54 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GkHBM-0000nf-Es; Wed, 15 Nov 2006 11:35:48 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkHBL-0000vU-88; Wed, 15 Nov 2006 11:35:47 +0200 To: Robert Watson From: Ian FREISLICH In-Reply-To: Message from Robert Watson of "Wed, 15 Nov 2006 09:03:28 GMT." <20061115085427.R79655@fledge.watson.org> X-Attribution: BOFH Date: Wed, 15 Nov 2006 11:35:47 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2195/Tue Nov 14 21:53:04 2006) Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 09:38:29 -0000 Robert Watson wrote: > On Wed, 15 Nov 2006, Ian FREISLICH wrote: > > Robert Watson wrote: > >> On Wed, 15 Nov 2006, Ian FREISLICH wrote: > >>> Ian FREISLICH wrote: > >>>> I have 2 servers each with 255 vlan interfaces and carp > >>>> interfaces in each vlan.During the boot up while it's configuring > >>>> the interfaces, it reliably panics. It boots fine if no network > >>>> cables are plugged in (and in the test evironment on a quient > >>>> lan). > >>>> > >>>> It's an SMP machine. My guess (from the panic message below) is > >>>> that an arp query arives on an interface it's in the middle of > >>>> creating or something like that (highly unsophisticated debugging > >>>> conjecture). > >>>> > >>>> In the mean time I'm going to try a UP kernel and see if that > >>>> masks the problem. > >>> > >>> FWIW, a UP kernel has the same problem. > >> > >> What happens if you disable PREEMPTION on UP and try the same thing > >> again? > > > > Same thing. > > > > If I don't assign the carp interfaces a vhid and pass at boot time, > > it boots up OK, but I need the carp interfaces. I can arrange > > serial console access. I have a similar system from ~"Tue Aug 29 > > 09:47:50 SAST 2006" that works, but I suspect it may suffer the same > > problem. I'm about to test this. > > This suggests that it is not the race I was worried it was, which is > really good news :-). This makes me suspect a CARP-specific bug as > opposed to the wider issue of under-synchronization of the address > lists. Which is what I'm beginning to suspect. For a long time the CARP driver was broken in -CURRENT. IIRC commits to ipcarp.c (1.41, 1.42 maymbe a few more) around June/July this year by Sam and Max fixed CARP interfaces, but they have subsequently fallen into disrepair. I don't have the knowledge to debug this further. I do have a crashdump for further inspection though. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 09:45:18 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43D2E16A51F for ; Wed, 15 Nov 2006 09:45:18 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A7FE43D67 for ; Wed, 15 Nov 2006 09:45:00 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 15 Nov 2006 09:44:59 +0000 (GMT) Date: Wed, 15 Nov 2006 09:44:59 +0000 From: David Malone To: Kris Kennaway Message-ID: <20061115094459.GA18538@walton.maths.tcd.ie> References: <20061115000551.GA93547@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061115000551.GA93547@xor.obsecurity.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: current@FreeBSD.org Subject: Re: ipfw breaks nfs over udp6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 09:45:18 -0000 On Tue, Nov 14, 2006 at 07:05:51PM -0500, Kris Kennaway wrote: > I tried to mount nfs over udp6 from a local host, but nfs traffic > makes ipfw cry: > > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > ... > > and nfs traffic is wedged. I'm guessing this is something to do with sending fragmented UDP packets. Looking at the ipfw2 code for dealing with IPv6 fragments, I think there's definitely a problem of some sort, but I can't see what the intended behaviour is yet. David. From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 14:30:54 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF4C816A4E5 for ; Wed, 15 Nov 2006 14:30:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E8BD440B2 for ; Wed, 15 Nov 2006 14:18:16 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 588B99B410 for ; Wed, 15 Nov 2006 15:18:07 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 364FC9E6C2 for ; Wed, 15 Nov 2006 14:18:38 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 23964405B; Wed, 15 Nov 2006 15:18:38 +0100 (CET) Date: Wed, 15 Nov 2006 15:18:38 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20061115141838.GL20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: psm(4) stopped working suddently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 14:30:55 -0000 Hi, my touchpad has been working like a charm until recently, then I noticed psm0 didn't exist any more. A verbose boot shows the following message in dmesg: % jarjarbinks:~:107# dmesg | grep ^psm % psm0: unable to allocate IRQ % psmcpnp0: irq 12 on acpi0 % psm0: current command byte:0047 % psm0: strange result for test aux port (1). % psm0: failed to reset the aux device Therefore, I added PSM_CONFIG_NORESET (0x400) to hint.psm.0.cflags in loader.conf(5) and this made psm0 come back and the touchpad work. I tried older kernels back to 2006.03.01 but none made my touchpad work without this flag. Does anyone have an idea of what has happened to my laptop ? Thank you. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 14:35:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 489A016A47B for ; Wed, 15 Nov 2006 14:35:42 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20EA943D4C for ; Wed, 15 Nov 2006 14:28:30 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id kAFESQdX009847 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 15:28:27 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id kAFESLi7029734; Wed, 15 Nov 2006 15:28:21 +0100 (MET) Date: Wed, 15 Nov 2006 15:28:20 +0100 From: Daniel Hartmeier To: tech@openbsd.org Message-ID: <20061115142820.GB14649@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org Subject: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 14:35:42 -0000 This patch against OpenBSD -current adds a simple form of PKI to OpenSSH. We'll be using it at work. See README.certkey (the first chunk of the patch) for details. Everything below is BSD licensed, sponsored by Allamanda Networks AG. Daniel --- /dev/null Wed Nov 15 15:14:20 2006 +++ README.certkey Wed Nov 15 15:13:45 2006 @@ -0,0 +1,176 @@ +OpenSSH Certkey + +INTRODUCTION + +Certkey allows OpenSSH to transmit certificates from server to client for host +authentication and from client to server for user authentication. Certificates +are basically signatures made by a certificate authority (CA) private key. + +A host certificate is a guarantee made by the CA that a host public key is +valid. When a host public key carries a valid certificate, the client can +use the host public key without asking the user to confirm the fingerprint +manually and through out-of-band communication the first time. The CA takes +the responsibility of verifying host keys, and users do no longer need to +maintain known_hosts files of their own. + +A user certificate is an authorization made by the CA that the holder of a +specific private key may login to the server as a specific user, without the +need of an authorized_keys file being present. The CA gains the power to grant +individual users access to the server, and users do no longer need to maintain +authorized_keys files of their own. + +Functionally, the CA assumes responsibility and control over users' known_hosts +and authorized_keys files. + +Certkey does not involve online verfication, the CA is not contacted by either +client or server. Instead, the CA generates certificates which are (once) +distributed to hosts and users. Any subsequent logins take place without the +involvment of the CA, based solely on the certificates provided between client +and server. + +For example, a company sets up a new host where many existing users need to +login. Traditionally, every one of those users will have to verify the new +host's key the first time they login. Also, each user will have to authorize +their public key on the new host. With Certkey enabled in this case (and +assuming the users have already been certified), this procedure is reduced to +the CA generating a certificate for the new host and installing the +certificate on the new host. + + +SECURITY IMPLICATIONS + +The CA, specifically the holder of the CA private key (and its password, if it +is password encrypted), holds broad control over hosts and user accounts set +up in this way. Should the CA private key become compromised, all user +accounts become compromised. + +There is no way to revoke a certificate once it has been published, the +certificate is valid until it reaches the expiry date set by the CA. + + +CONFIGURATION + +The feature is enabled through the following two options in the client and +server configurations: + + CertkeyAuthentication yes + CAKeyFile /etc/ssh/ca.pub + + +USAGE + +(1) Generating a CA key pair + + # ssh-keygen + Generating public/private rsa key pair. + Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/ca + Enter passphrase (empty for no passphrase): + Enter same passphrase again: + Your identification has been saved in /root/.ssh/ca. + Your public key has been saved in /root/.ssh/ca.pub. + The key fingerprint is: + f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d root@host + +(2) Generating a host certificate + + # ssh-keygen -s + Enter file in which the CA key is (/root/.ssh/id_rsa): /root/.ssh/ca + CA key fingerprint f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d + Enter file in which the user/host key is: /etc/ssh/ssh_host_rsa_key.pub + host/user key fingerprint 68:8c:25:e3:b1:17:8a:7f:0c:19:fa:0d:f7:12:6f:8a + CA name : benzedrine.cx + identity : lenovo.benzedrine.cx + options : + valid from : 0 + valid until: 20061231 + Certificate has been saved in /etc/ssh/ssh_host_rsa_key.cert. + + # cp /root/.ssh/ca.pub /etc/ssh/ca.pub + +(3) Generating a user certificate + + # ssh-keygen -s + Enter file in which the CA key is (/root/.ssh/id_rsa): /root/.ssh/ca + CA key fingerprint f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d + Enter file in which the user/host key is: /home/dhartmei/.ssh/id_dsa.pub + host/user key fingerprint 86:c8:52:3e:b1:17:8a:7f:0c:19:fa:0d:f7:12:f6:a8 + CA name : benzedrine.cx + identity : dhartmei + options : + valid from : 20061101 + valid until: 20071231 + Certificate has been saved in /home/dhartmei/.ssh/id_dsa.cert. + + +IMPLEMENTATION + +Host and user certificates are introduced into the transport layer and +authentication protocol by addition of a new method respectively. + +Transport Layer Protocol + +An additional key exchange method "diffie-hellman-group-exchange-cert" has +been added. This method is completely identical to the existing method +"diffie-hellman-group-exchange-sha1", except for one additional string +(the host certificate), placed at the end of the message, after the signature. + +Authentication Protocol + +An additional authentication method "certkey" has been added. This method is +completely identical to the existing method "publickey", except for one +additional string (the user certificate), placed at the end of the message, +after the signature. + +Certificate format + +Both host and user certificates share the same format. They consist of a single +string, containing values separated by semi-colons, in the following order + + fingerprint;caname;identity;options;validfrom;validto;algorithm;signature + +Values must not contain semi-colons or NUL bytes, but may be empty. + +'fingerprint' is the SSH_FP_MD5 SSH_FP_HEX fingerprint of the RSA key signing +the certificate (the CA key), e.g. the output of ssh-keygen -l for +/etc/ssh/ca.pub. + +'caname' is the name of the CA. This can be used to associate certificates with +CAs. The format is not defined, though using domain names is suggested. + +'identity' is the identity being certified by the CA with this certificate. +For user certificates, this is the user name the certifcate grants login to. +For host certificates, the format is not defined, though using the host's +fully-qualified domain name is suggested. + +'options' may contain additional options, in form of key=value pairs separated +by pipes '|', like 'foo=bar|src=10/8,*.networx.ch|dst=192.168/16'. keys and +values must not contain semi-colons, pipes, '=' or NUL bytes. The meaning of +options is not currently defined, though keys 'src' and 'dst' are reserved for +later implementation of restrictions based on client/server addresses. + +'validfrom' and 'validto' are timestamps (UNIX Epoch time) defining the time +frame the certificate is valid in. When, upon certificate verification, the +current time is outside this period, the certificate is not valid. If zero is +used as value for 'validto', the certificate is valid indefinitely after +'validfrom'. + +'algorithm' defines the hash algorithm used for the signature. Currently, the +only legal value is 'ripemd160'. + +'signature' is the signature itself in hex without colons. The data being +signed consists of + + fingerprint;caname;identity;options;validfrom;validto + +where 'fingerprint' is the SSH_FP_MD5 SSH_FP_HEX fingerprint of the user or +host key (not the CA key). + +Example: + + f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d;networx.ch;dhartmei;; + 1136070000;1451602800;ripemd160;dbd33e932d80b5612...5a0b4759bee451 + +Note that the certificate does not contain any newline characters, it's +wrapped onto two lines here to improve readability. + +$OpenBSD$ Index: auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- auth.h 18 Aug 2006 09:15:20 -0000 1.58 +++ auth.h 15 Nov 2006 14:14:32 -0000 @@ -115,6 +115,7 @@ int auth_rhosts_rsa_key_allowed(struct passwd *, char *, char *, Key *); int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); int user_key_allowed(struct passwd *, Key *); +int user_cert_key_allowed(struct passwd *, Key *); #ifdef KRB5 int auth_krb5(Authctxt *authctxt, krb5_data *auth, char **client, krb5_data *); Index: auth2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth2.c,v retrieving revision 1.113 diff -u -r1.113 auth2.c --- auth2.c 3 Aug 2006 03:34:41 -0000 1.113 +++ auth2.c 15 Nov 2006 14:14:32 -0000 @@ -55,6 +55,7 @@ /* methods */ extern Authmethod method_none; +extern Authmethod method_certkey; extern Authmethod method_pubkey; extern Authmethod method_passwd; extern Authmethod method_kbdint; @@ -65,6 +66,7 @@ Authmethod *authmethods[] = { &method_none, + &method_certkey, &method_pubkey, #ifdef GSSAPI &method_gssapi, Index: authfile.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/authfile.c,v retrieving revision 1.76 diff -u -r1.76 authfile.c --- authfile.c 3 Aug 2006 03:34:41 -0000 1.76 +++ authfile.c 15 Nov 2006 14:14:33 -0000 @@ -302,6 +302,43 @@ return pub; } +static void +key_try_load_cert(Key *key, const char *filename) +{ + char fn[MAXPATHLEN]; + int fd; + ssize_t r; + + if (key->cert) { + xfree(key->cert); + key->cert = NULL; + } + if (strlen(filename) > 4 && strlen(filename) < sizeof(fn) && + !strcmp(filename + strlen(filename) - 4, ".pub")) + strlcpy(fn, filename, strlen(filename) - 3); + else + strlcpy(fn, filename, sizeof(fn)); + strlcat(fn, ".cert", sizeof(fn)); + + fd = open(fn, O_RDONLY); + if (fd >= 0) { + key->cert = xmalloc(8192); + if (key->cert) { + r = read(fd, key->cert, 8192); + if (r > 0) { + if (key->cert[r - 1] == '\n') + key->cert[r - 1] = 0; + else + key->cert[r] = 0; + } else { + xfree(key->cert); + key->cert = NULL; + } + } + close(fd); + } +} + /* load public key from private-key file, works only for SSH v1 */ Key * key_load_public_type(int type, const char *filename, char **commentp) @@ -315,6 +352,8 @@ return NULL; pub = key_load_public_rsa1(fd, filename, commentp); close(fd); + if (pub != NULL) + key_try_load_cert(pub, filename); return pub; } return NULL; @@ -604,6 +643,8 @@ /* closes fd */ prv = key_load_private_rsa1(fd, filename, passphrase, NULL); } + if (prv != NULL) + key_try_load_cert(prv, filename); return prv; } @@ -634,6 +675,7 @@ if (commentp) *commentp=xstrdup(filename); fclose(f); + key_try_load_cert(k, filename); return 1; } } Index: kex.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kex.c,v retrieving revision 1.76 diff -u -r1.76 kex.c --- kex.c 3 Aug 2006 03:34:42 -0000 1.76 +++ kex.c 15 Nov 2006 14:14:33 -0000 @@ -312,6 +312,9 @@ } else if (strcmp(k->name, KEX_DHGEX_SHA256) == 0) { k->kex_type = KEX_DH_GEX_SHA256; k->evp_md = evp_ssh_sha256(); + } else if (strcmp(k->name, KEX_DHGEX_CERT) == 0) { + k->kex_type = KEX_DH_GEX_CERT; + k->evp_md = EVP_sha1(); } else fatal("bad kex alg %s", k->name); } Index: kex.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/kex.h,v retrieving revision 1.44 diff -u -r1.44 kex.h --- kex.h 3 Aug 2006 03:34:42 -0000 1.44 +++ kex.h 15 Nov 2006 14:14:33 -0000 @@ -32,6 +32,7 @@ #define KEX_DH14 "diffie-hellman-group14-sha1" #define KEX_DHGEX_SHA1 "diffie-hellman-group-exchange-sha1" #define KEX_DHGEX_SHA256 "diffie-hellman-group-exchange-sha256" +#define KEX_DHGEX_CERT "diffie-hellman-group-exchange-cert" #define COMP_NONE 0 #define COMP_ZLIB 1 @@ -62,6 +63,7 @@ KEX_DH_GRP14_SHA1, KEX_DH_GEX_SHA1, KEX_DH_GEX_SHA256, + KEX_DH_GEX_CERT, KEX_MAX }; Index: kexgexc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kexgexc.c,v retrieving revision 1.11 diff -u -r1.11 kexgexc.c --- kexgexc.c 6 Nov 2006 21:25:28 -0000 1.11 +++ kexgexc.c 15 Nov 2006 14:14:33 -0000 @@ -124,8 +124,6 @@ fatal("type mismatch for decoded server_host_key_blob"); if (kex->verify_host_key == NULL) fatal("cannot verify server_host_key"); - if (kex->verify_host_key(server_host_key) == -1) - fatal("server_host_key verification failed"); /* DH parameter f, server public DH key */ if ((dh_server_pub = BN_new()) == NULL) @@ -141,7 +139,20 @@ /* signed H */ signature = packet_get_string(&slen); + if (kex->kex_type == KEX_DH_GEX_CERT) { + u_char *cert; + u_int len; + + cert = packet_get_string(&len); + if (cert != NULL) { + server_host_key->cert = xstrdup(cert); + xfree(cert); + } + } packet_check_eom(); + + if (kex->verify_host_key(server_host_key) == -1) + fatal("server_host_key verification failed"); if (!dh_pub_is_valid(dh, dh_server_pub)) packet_disconnect("bad server public DH value"); Index: kexgexs.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kexgexs.c,v retrieving revision 1.10 diff -u -r1.10 kexgexs.c --- kexgexs.c 6 Nov 2006 21:25:28 -0000 1.10 +++ kexgexs.c 15 Nov 2006 14:14:33 -0000 @@ -183,6 +183,13 @@ packet_put_string(server_host_key_blob, sbloblen); packet_put_bignum2(dh->pub_key); /* f */ packet_put_string(signature, slen); + if (kex->kex_type == KEX_DH_GEX_CERT) { + if (server_host_key->cert != NULL) + packet_put_string(server_host_key->cert, + strlen(server_host_key->cert)); + else + packet_put_string("", 0); + } packet_send(); xfree(signature); Index: key.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.c,v retrieving revision 1.68 diff -u -r1.68 key.c --- key.c 6 Nov 2006 21:25:28 -0000 1.68 +++ key.c 15 Nov 2006 14:14:33 -0000 @@ -57,6 +57,7 @@ k->type = type; k->dsa = NULL; k->rsa = NULL; + k->cert = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -145,6 +146,9 @@ fatal("key_free: bad key type %d", k->type); break; } + if (k->cert != NULL) + xfree(k->cert); + k->cert = NULL; xfree(k); } @@ -833,6 +837,7 @@ pk->flags = k->flags; pk->dsa = NULL; pk->rsa = NULL; + pk->cert = k->cert ? xstrdup(k->cert) : NULL; switch (k->type) { case KEY_RSA1: @@ -862,4 +867,100 @@ } return (pk); +} + +static void +cert_token(const u_char **c, u_char *buf, int len) +{ + int i = 0; + + while (**c && **c != ';' && i + 1 < len) + buf[i++] = *(*c)++; + if (**c == ';') + (*c)++; + buf[i] = 0; +} + +/* check whether certificate is valid and signature correct */ +int +cert_verify(const u_char *cert, const Key *ca_key, const Key *key, + const u_char *identity) +{ + u_char ca_fp[128], ca_name[128], ca_id[128], ca_opts[512]; + u_char ca_vf[16], ca_vt[16], ca_alg[64], ca_sig[1024]; + u_char sigbuf[1024], datbuf[2048], c, *fp; + unsigned long vf, vt, now = time(NULL); + u_int siglen, i; + + if (cert == NULL || ca_key == NULL || ca_key->type != KEY_RSA || + ca_key->rsa == NULL || key == NULL) { + debug2("cert_verify: invalid arguments"); + return 0; + } + + cert_token(&cert, ca_fp, sizeof(ca_fp)); + cert_token(&cert, ca_name, sizeof(ca_name)); + cert_token(&cert, ca_id, sizeof(ca_id)); + cert_token(&cert, ca_opts, sizeof(ca_opts)); + cert_token(&cert, ca_vf, sizeof(ca_vf)); + vf = strtoul(ca_vf, NULL, 10); + cert_token(&cert, ca_vt, sizeof(ca_vt)); + vt = strtoul(ca_vt, NULL, 10); + cert_token(&cert, ca_alg, sizeof(ca_alg)); + cert_token(&cert, ca_sig, sizeof(ca_sig)); + + if (strcmp(ca_alg, "ripemd160")) { + debug2("cert_verify: unsupported alg '%s'\n", ca_alg); + return 0; + } + + siglen = 0; + for (i = 0; ca_sig[i]; ++i) { + if (ca_sig[i] >= '0' && ca_sig[i] <= '9') + c = ca_sig[i] - '0'; + else if (ca_sig[i] >= 'a' && ca_sig[i] <= 'f') + c = ca_sig[i] - 'a' + 10; + else + break; + if ((i % 2) == 0) + sigbuf[siglen] = c << 4; + else + sigbuf[siglen++] |= c; + } + + fp = key_fingerprint(ca_key, SSH_FP_MD5, SSH_FP_HEX); + if (strcmp(fp, ca_fp)) { + debug2("cert_verify: CA key fingerprint mismatch ('%s' != '%s')", + fp, ca_fp); + xfree(fp); + return 0; + } + xfree(fp); + + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + snprintf(datbuf, sizeof(datbuf), "%s;%s;%s;%s;%lu;%lu", + fp, ca_name, ca_id, ca_opts, vf, vt); + xfree(fp); + + if (RSA_verify(NID_ripemd160, datbuf, strlen(datbuf), sigbuf, siglen, + ca_key->rsa) != 1) { + debug2("cert_verify: signature not valid ('%s')", ca_sig); + return 0; + } + if (vf && vf > now) { + debug2("cert_verify: certificate is not yet valid (%lu > %lu)", + vf, now); + return 0; + } + if (vt && vt < now) { + debug2("cert_verify: certificate has expired (%lu < %lu)", + vt, now); + return 0; + } + if (identity != NULL && strcmp(identity, ca_id)) { + debug2("cert_verify: identity mismatches ('%s' != '%s')", + identity, ca_id); + return 0; + } + return 1; } Index: key.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.h,v retrieving revision 1.26 diff -u -r1.26 key.h --- key.h 3 Aug 2006 03:34:42 -0000 1.26 +++ key.h 15 Nov 2006 14:14:33 -0000 @@ -53,6 +53,7 @@ int flags; RSA *rsa; DSA *dsa; + u_char *cert; }; Key *key_new(int); @@ -83,5 +84,7 @@ int ssh_dss_verify(const Key *, const u_char *, u_int, const u_char *, u_int); int ssh_rsa_sign(const Key *, u_char **, u_int *, const u_char *, u_int); int ssh_rsa_verify(const Key *, const u_char *, u_int, const u_char *, u_int); + +int cert_verify(const u_char *cert, const Key *, const Key *, const u_char *); #endif Index: monitor.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor.c,v retrieving revision 1.89 diff -u -r1.89 monitor.c --- monitor.c 7 Nov 2006 10:31:31 -0000 1.89 +++ monitor.c 15 Nov 2006 14:14:35 -0000 @@ -797,6 +797,17 @@ if (key != NULL && authctxt->valid) { switch (type) { + case MM_CERTKEY: { + u_char *cert; + u_int clen; + + cert = buffer_get_string(m, &clen); + key->cert = xstrdup(cert); + allowed = options.certkey_authentication && + user_cert_key_allowed(authctxt->pw, key); + auth_method = "certkey"; + break; + } case MM_USERKEY: allowed = options.pubkey_authentication && user_key_allowed(authctxt->pw, key); @@ -859,7 +870,7 @@ } static int -monitor_valid_userblob(u_char *data, u_int datalen) +monitor_valid_userblob(u_char *data, u_int datalen, u_char *name) { Buffer b; char *p; @@ -900,7 +911,7 @@ fail++; } else { p = buffer_get_string(&b, NULL); - if (strcmp("publickey", p) != 0) + if (strcmp(name, p) != 0) fail++; xfree(p); if (!buffer_get_char(&b)) @@ -992,8 +1003,11 @@ fatal("%s: bad public key blob", __func__); switch (key_blobtype) { + case MM_CERTKEY: + valid_data = monitor_valid_userblob(data, datalen, "certkey"); + break; case MM_USERKEY: - valid_data = monitor_valid_userblob(data, datalen); + valid_data = monitor_valid_userblob(data, datalen, "publickey"); break; case MM_HOSTKEY: valid_data = monitor_valid_hostbasedblob(data, datalen, @@ -1015,7 +1029,12 @@ xfree(signature); xfree(data); - auth_method = key_blobtype == MM_USERKEY ? "publickey" : "hostbased"; + if (key_blobtype == MM_CERTKEY) + auth_method = "certkey"; + else if (key_blobtype == MM_USERKEY) + auth_method = "publickey"; + else + auth_method = "hostbased"; monitor_reset_key_state(); Index: monitor_wrap.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.c,v retrieving revision 1.54 diff -u -r1.54 monitor_wrap.c --- monitor_wrap.c 12 Aug 2006 20:46:46 -0000 1.54 +++ monitor_wrap.c 15 Nov 2006 14:14:35 -0000 @@ -295,6 +295,12 @@ } int +mm_user_cert_key_allowed(struct passwd *pw, Key *key) +{ + return (mm_key_allowed(MM_CERTKEY, NULL, NULL, key)); +} + +int mm_user_key_allowed(struct passwd *pw, Key *key) { return (mm_key_allowed(MM_USERKEY, NULL, NULL, key)); @@ -351,6 +357,8 @@ buffer_put_cstring(&m, user ? user : ""); buffer_put_cstring(&m, host ? host : ""); buffer_put_string(&m, blob, len); + if (type == MM_CERTKEY && key && key->cert) + buffer_put_string(&m, key->cert, strlen(key->cert)); xfree(blob); mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_KEYALLOWED, &m); Index: monitor_wrap.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.h,v retrieving revision 1.20 diff -u -r1.20 monitor_wrap.h --- monitor_wrap.h 3 Aug 2006 03:34:42 -0000 1.20 +++ monitor_wrap.h 15 Nov 2006 14:14:35 -0000 @@ -31,7 +31,7 @@ extern int use_privsep; #define PRIVSEP(x) (use_privsep ? mm_##x : x) -enum mm_keytype {MM_NOKEY, MM_HOSTKEY, MM_USERKEY, MM_RSAHOSTKEY, MM_RSAUSERKEY}; +enum mm_keytype {MM_NOKEY, MM_HOSTKEY, MM_CERTKEY, MM_USERKEY, MM_RSAHOSTKEY, MM_RSAUSERKEY}; struct monitor; struct mm_master; @@ -46,6 +46,7 @@ int mm_auth_password(struct Authctxt *, char *); int mm_key_allowed(enum mm_keytype, char *, char *, Key *); int mm_user_key_allowed(struct passwd *, Key *); +int mm_user_cert_key_allowed(struct passwd *, Key *); int mm_hostbased_key_allowed(struct passwd *, char *, char *, Key *); int mm_auth_rhosts_rsa_key_allowed(struct passwd *, char *, char *, Key *); int mm_key_verify(Key *, u_char *, u_int, u_char *, u_int); Index: myproposal.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/myproposal.h,v retrieving revision 1.21 diff -u -r1.21 myproposal.h --- myproposal.h 25 Mar 2006 22:22:43 -0000 1.21 +++ myproposal.h 15 Nov 2006 14:14:35 -0000 @@ -24,6 +24,7 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #define KEX_DEFAULT_KEX \ + "diffie-hellman-group-exchange-cert," \ "diffie-hellman-group-exchange-sha256," \ "diffie-hellman-group-exchange-sha1," \ "diffie-hellman-group14-sha1," \ Index: pathnames.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/pathnames.h,v retrieving revision 1.16 diff -u -r1.16 pathnames.h --- pathnames.h 25 Mar 2006 22:22:43 -0000 1.16 +++ pathnames.h 15 Nov 2006 14:14:35 -0000 @@ -36,6 +36,7 @@ #define _PATH_DH_MODULI ETCDIR "/moduli" /* Backwards compatibility */ #define _PATH_DH_PRIMES ETCDIR "/primes" +#define _PATH_CA_KEY_FILE SSHDIR "/ca.pub" #define _PATH_SSH_PROGRAM "/usr/bin/ssh" Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.159 diff -u -r1.159 readconf.c --- readconf.c 3 Aug 2006 03:34:42 -0000 1.159 +++ readconf.c 15 Nov 2006 14:14:36 -0000 @@ -117,7 +117,8 @@ oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression, oCompressionLevel, oTCPKeepAlive, oNumberOfPasswordPrompts, oUsePrivilegedPort, oLogLevel, oCiphers, oProtocol, oMacs, - oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, + oGlobalKnownHostsFile2, oUserKnownHostsFile2, oCertkeyAuthentication, + oCAKeyFile, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, @@ -148,6 +149,8 @@ { "kbdinteractiveauthentication", oKbdInteractiveAuthentication }, { "kbdinteractivedevices", oKbdInteractiveDevices }, { "rsaauthentication", oRSAAuthentication }, + { "certkeyauthentication", oCertkeyAuthentication }, + { "cakeyfile", oCAKeyFile }, { "pubkeyauthentication", oPubkeyAuthentication }, { "dsaauthentication", oPubkeyAuthentication }, /* alias */ { "rhostsrsaauthentication", oRhostsRSAAuthentication }, @@ -412,6 +415,10 @@ charptr = &options->kbd_interactive_devices; goto parse_string; + case oCertkeyAuthentication: + intptr = &options->certkey_authentication; + goto parse_flag; + case oPubkeyAuthentication: intptr = &options->pubkey_authentication; goto parse_flag; @@ -560,6 +567,10 @@ *charptr = xstrdup(arg); break; + case oCAKeyFile: + charptr = &options->ca_key_file; + goto parse_string; + case oGlobalKnownHostsFile: charptr = &options->system_hostfile; goto parse_string; @@ -1002,6 +1013,8 @@ options->gateway_ports = -1; options->use_privileged_port = -1; options->rsa_authentication = -1; + options->certkey_authentication = -1; + options->ca_key_file = NULL; options->pubkey_authentication = -1; options->challenge_response_authentication = -1; options->gss_authentication = -1; @@ -1088,6 +1101,10 @@ options->use_privileged_port = 0; if (options->rsa_authentication == -1) options->rsa_authentication = 1; + if (options->certkey_authentication == -1) + options->certkey_authentication = 0; + if (options->ca_key_file == NULL) + options->ca_key_file = _PATH_CA_KEY_FILE; if (options->pubkey_authentication == -1) options->pubkey_authentication = 1; if (options->challenge_response_authentication == -1) Index: readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.71 diff -u -r1.71 readconf.h --- readconf.h 3 Aug 2006 03:34:42 -0000 1.71 +++ readconf.h 15 Nov 2006 14:14:36 -0000 @@ -39,6 +39,8 @@ int rhosts_rsa_authentication; /* Try rhosts with RSA * authentication. */ int rsa_authentication; /* Try RSA authentication. */ + int certkey_authentication; /* Try ssh2 certkey authentication. */ + char *ca_key_file; /* File containing CA key. */ int pubkey_authentication; /* Try ssh2 pubkey authentication. */ int hostbased_authentication; /* ssh2's rhosts_rsa */ int challenge_response_authentication; Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.165 diff -u -r1.165 servconf.c --- servconf.c 14 Aug 2006 12:40:25 -0000 1.165 +++ servconf.c 15 Nov 2006 14:14:37 -0000 @@ -56,6 +56,7 @@ options->listen_addrs = NULL; options->address_family = -1; options->num_host_key_files = 0; + options->ca_key_file = NULL; options->pid_file = NULL; options->server_key_bits = -1; options->login_grace_time = -1; @@ -77,6 +78,7 @@ options->hostbased_authentication = -1; options->hostbased_uses_name_from_packet_only = -1; options->rsa_authentication = -1; + options->certkey_authentication = -1; options->pubkey_authentication = -1; options->kerberos_authentication = -1; options->kerberos_or_local_passwd = -1; @@ -134,6 +136,8 @@ _PATH_HOST_DSA_KEY_FILE; } } + if (options->ca_key_file == NULL) + options->ca_key_file = _PATH_CA_KEY_FILE; if (options->num_ports == 0) options->ports[options->num_ports++] = SSH_DEFAULT_PORT; if (options->listen_addrs == NULL) @@ -180,6 +184,8 @@ options->hostbased_uses_name_from_packet_only = 0; if (options->rsa_authentication == -1) options->rsa_authentication = 1; + if (options->certkey_authentication == -1) + options->certkey_authentication = 0; if (options->pubkey_authentication == -1) options->pubkey_authentication = 1; if (options->kerberos_authentication == -1) @@ -259,9 +265,9 @@ sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, - sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, - sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, - sMaxStartups, sMaxAuthTries, + sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, sCAKeyFile, + sGatewayPorts, sCertkeyAuthentication, sPubkeyAuthentication, sXAuthLocation, + sSubsystem, sMaxStartups, sMaxAuthTries, sBanner, sUseDNS, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, @@ -282,6 +288,7 @@ u_int flags; } keywords[] = { { "port", sPort, SSHCFG_GLOBAL }, + { "cakeyfile", sCAKeyFile, SSHCFG_GLOBAL }, { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ { "pidfile", sPidFile, SSHCFG_GLOBAL }, @@ -296,6 +303,7 @@ { "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_GLOBAL }, { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, SSHCFG_GLOBAL }, { "rsaauthentication", sRSAAuthentication, SSHCFG_GLOBAL }, + { "certkeyauthentication", sCertkeyAuthentication, SSHCFG_GLOBAL }, { "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, { "dsaauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, /* alias */ #ifdef KRB5 @@ -738,6 +746,10 @@ } break; + case sCAKeyFile: + charptr = &options->ca_key_file; + goto parse_filename; + case sPidFile: charptr = &options->pid_file; goto parse_filename; @@ -803,6 +815,10 @@ case sRSAAuthentication: intptr = &options->rsa_authentication; + goto parse_flag; + + case sCertkeyAuthentication: + intptr = &options->certkey_authentication; goto parse_flag; case sPubkeyAuthentication: Index: servconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.h,v retrieving revision 1.79 diff -u -r1.79 servconf.h --- servconf.h 14 Aug 2006 12:40:25 -0000 1.79 +++ servconf.h 15 Nov 2006 14:14:37 -0000 @@ -43,6 +43,7 @@ char *listen_addr; /* Address on which the server listens. */ struct addrinfo *listen_addrs; /* Addresses on which the server listens. */ int address_family; /* Address family used by the server. */ + char *ca_key_file; /* File containing CA key. */ char *host_key_files[MAX_HOSTKEYS]; /* Files containing host keys. */ int num_host_key_files; /* Number of files for host keys. */ char *pid_file; /* Where to put our pid */ @@ -75,6 +76,7 @@ int hostbased_uses_name_from_packet_only; /* experimental */ int rsa_authentication; /* If true, permit RSA authentication. */ int pubkey_authentication; /* If true, permit ssh2 pubkey authentication. */ + int certkey_authentication; /* If true, permit ssh2 certkey authentication. */ int kerberos_authentication; /* If true, permit Kerberos * authentication. */ int kerberos_or_local_passwd; /* If true, permit kerberos Index: ssh-keygen.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v retrieving revision 1.156 diff -u -r1.156 ssh-keygen.c --- ssh-keygen.c 14 Nov 2006 19:41:04 -0000 1.156 +++ ssh-keygen.c 15 Nov 2006 14:14:37 -0000 @@ -94,6 +94,8 @@ int print_public = 0; int print_generic = 0; +int sign_host_key = 0; + char *key_type_name = NULL; /* argv0 */ @@ -494,6 +496,142 @@ #endif /* SMARTCARD */ static void +ask_string(const char *question, char *buf, int len) +{ + printf("%s", question); + if (fgets(buf, len, stdin) == NULL) + exit(1); + buf[len - 1] = 0; + len = strlen(buf); + if (len > 0 && buf[len - 1] == '\n') + buf[len - 1] = 0; +} + +static unsigned long +ask_date(const char *question) +{ + char buf[64]; + int len; + unsigned year, mon = 1, mday = 1, hour = 0, min = 0, sec = 0; + struct tm tm; + + printf("%s", question); + if (fgets(buf, sizeof(buf), stdin) == NULL) + exit(1); + buf[sizeof(buf) - 1] = 0; + len = strlen(buf); + if (len > 0 && buf[len - 1] == '\n') + buf[len - 1] = 0; + if (sscanf(buf, "%4u%2u%2u%2u%2u%2u", + &year, &mon, &mday, &hour, &min, &sec) < 1) { + error("invalid date"); + exit(1); + } + if (!year) + return 0; + memset(&tm, 0, sizeof(tm)); + tm.tm_year = year - 1900; + tm.tm_mon = mon - 1; + tm.tm_mday = mday; + tm.tm_hour = hour; + tm.tm_min = min; + tm.tm_sec = sec; + return timegm(&tm); +} + +static void +do_sign_host_key(struct passwd *pw) +{ + struct stat st; + u_char ca_name[128], ca_id[128], ca_opts[512]; + u_char dat[8192], sig[8192], key_fn[1024], cert_fn[1024]; + unsigned long valid_from, valid_to; + u_int slen; + Key *ca_key, *host_key; + char *ca_fp, *host_fp; + FILE *f; + int i; + + if (!have_identity) + ask_filename(pw, "Enter file in which the CA key is"); + if (stat(identity_file, &st) < 0) { + perror(identity_file); + exit(1); + } + ca_key = load_identity(identity_file); + if (ca_key == NULL) { + error("load failed"); + exit(1); + } + if (ca_key->type != KEY_RSA || ca_key->rsa == NULL) { + error("key invalid"); + exit(1); + } + ca_fp = key_fingerprint(ca_key, SSH_FP_MD5, SSH_FP_HEX); + printf("CA key fingerprint %s\n", ca_fp); + + ask_string("Enter file in which the user/host key is: ", key_fn, sizeof(key_fn)); + if (stat(key_fn, &st) < 0) { + perror(key_fn); + exit(1); + } + host_key = key_load_public(key_fn, NULL); + if (host_key == NULL) { + error("load failed"); + exit(1); + } + strlcpy(cert_fn, key_fn, sizeof(cert_fn)); + if (strlen(cert_fn) > 4 && !strcmp(cert_fn + strlen(cert_fn) - 4, ".pub")) + cert_fn[strlen(cert_fn) - 4] = 0; + strlcat(cert_fn, ".cert", sizeof(cert_fn)); + host_fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + printf("host/user key fingerprint %s\n", host_fp); + + ask_string("CA name : ", ca_name, sizeof(ca_name)); + if (!ca_name[0] || strchr(ca_name, ';')) { + error("invalid CA name"); + exit(1); + } + ask_string("identity : ", ca_id, sizeof(ca_id)); + if (!ca_id[0] || strchr(ca_id, ';')) { + error("invalid identity"); + exit(1); + } + ask_string("options : ", ca_opts, sizeof(ca_opts)); + if (strchr(ca_opts, ';')) { + error("invalid options"); + exit(1); + } + valid_from = ask_date("valid from : "); + valid_to = ask_date("valid until: "); + + snprintf(dat, sizeof(dat), "%s;%s;%s;%s;%lu;%lu", + host_fp, ca_name, ca_id, ca_opts, valid_from, valid_to); + if (RSA_sign(NID_ripemd160, dat, strlen(dat), sig, &slen, ca_key->rsa) != 1 || !slen) { + fprintf(stderr, "RSA_sign() failed\n"); + exit(1); + } + if (RSA_verify(NID_ripemd160, dat, strlen(dat), sig, slen, ca_key->rsa) != 1) { + fprintf(stderr, "RSA_verify() failed\n"); + exit(1); + } + + snprintf(dat, sizeof(dat), "%s;%s;%s;%s;%lu;%lu;ripemd160;", + ca_fp, ca_name, ca_id, ca_opts, valid_from, valid_to); + for (i = 0; i < slen; ++i) + snprintf(dat + strlen(dat), sizeof(dat) - strlen(dat), "%.2x", sig[i]); + f = fopen(cert_fn, "w"); + if (f == NULL) { + fprintf(stderr, "fopen: %s: %s\n", cert_fn, strerror(errno)); + exit(1); + } + fprintf(f, "%s", dat); + fclose(f); + printf("Certificate has been saved in %s.\n", cert_fn); + exit(0); +} + +static void do_fingerprint(struct passwd *pw) { FILE *f; @@ -1026,6 +1164,7 @@ fprintf(stderr, " -R hostname Remove host from known_hosts file.\n"); fprintf(stderr, " -r hostname Print DNS resource record.\n"); fprintf(stderr, " -S start Start point (hex) for generating DH-GEX moduli.\n"); + fprintf(stderr, " -s Generate certificate for user/host key using CA key.\n"); fprintf(stderr, " -T file Screen candidates for DH-GEX moduli.\n"); fprintf(stderr, " -t type Specify type of key to create.\n"); #ifdef SMARTCARD @@ -1079,7 +1218,7 @@ } while ((opt = getopt(argc, argv, - "degiqpclBHvxXyF:b:f:t:U:D:P:N:C:r:g:R:T:G:M:S:a:W:")) != -1) { + "degiqpsclBHvxXyF:b:f:t:U:D:P:N:C:r:g:R:T:G:M:S:a:W:")) != -1) { switch (opt) { case 'b': bits = (u_int32_t)strtonum(optarg, 768, 32768, &errstr); @@ -1156,6 +1295,9 @@ case 'U': reader_id = optarg; break; + case 's': + sign_host_key = 1; + break; case 'v': if (log_level == SYSLOG_LEVEL_INFO) log_level = SYSLOG_LEVEL_DEBUG1; @@ -1221,6 +1363,8 @@ printf("Can only have one of -p and -c.\n"); usage(); } + if (sign_host_key) + do_sign_host_key(pw); if (delete_host || hash_hosts || find_host) do_known_hosts(pw, rr_hostname); if (print_fingerprint || print_bubblebabble) Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.97 diff -u -r1.97 ssh_config.5 --- ssh_config.5 27 Jul 2006 08:00:50 -0000 1.97 +++ ssh_config.5 15 Nov 2006 14:14:38 -0000 @@ -145,6 +145,15 @@ .Cm UsePrivilegedPort is set to .Dq yes . +.It Cm CAKeyFile +Specifies a file containing a public CA key. +The default is +.Pa /etc/ssh/ca.pub . +.It Cm CertkeyAuthentication +Specifies whether certified key authentication is allowed. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. .It Cm ChallengeResponseAuthentication Specifies whether to use challenge-response authentication. The argument to this keyword must be Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.200 diff -u -r1.200 sshconnect.c --- sshconnect.c 10 Oct 2006 10:12:45 -0000 1.200 +++ sshconnect.c 15 Nov 2006 14:14:39 -0000 @@ -21,6 +21,7 @@ #include +#include #include #include #include @@ -48,6 +49,7 @@ #include "misc.h" #include "dns.h" #include "version.h" +#include "authfile.h" char *client_version_string = NULL; char *server_version_string = NULL; @@ -884,6 +886,19 @@ { struct stat st; int flags = 0; + + if (options.certkey_authentication && host_key->cert != NULL) { + Key *ca_key; + int verified; + + ca_key = key_load_public(options.ca_key_file, NULL); + if (ca_key != NULL) { + verified = cert_verify(host_key->cert, ca_key, host_key, NULL); + key_free(ca_key); + if (verified) + return 0; + } + } if (options.verify_host_key_dns && verify_host_key_dns(host, hostaddr, host_key, &flags) == 0) { Index: sshconnect2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect2.c,v retrieving revision 1.162 diff -u -r1.162 sshconnect2.c --- sshconnect2.c 30 Aug 2006 00:06:51 -0000 1.162 +++ sshconnect2.c 15 Nov 2006 14:14:40 -0000 @@ -133,6 +133,7 @@ kex->kex[KEX_DH_GRP14_SHA1] = kexdh_client; kex->kex[KEX_DH_GEX_SHA1] = kexgex_client; kex->kex[KEX_DH_GEX_SHA256] = kexgex_client; + kex->kex[KEX_DH_GEX_CERT] = kexgex_client; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; kex->verify_host_key=&verify_host_key_callback; @@ -168,6 +169,7 @@ Key *key; /* public/private key */ char *filename; /* comment for agent-only keys */ int tried; + int triedcert; int isprivate; /* key points to the private key */ }; TAILQ_HEAD(idlist, identity); @@ -206,6 +208,7 @@ void input_userauth_passwd_changereq(int, u_int32_t, void *); int userauth_none(Authctxt *); +int userauth_certkey(Authctxt *); int userauth_pubkey(Authctxt *); int userauth_passwd(Authctxt *); int userauth_kbdint(Authctxt *); @@ -224,6 +227,7 @@ void userauth(Authctxt *, char *); static int sign_and_send_pubkey(Authctxt *, Identity *); +static int sign_and_send_certkey(Authctxt *, Identity *); static void pubkey_prepare(Authctxt *); static void pubkey_cleanup(Authctxt *); static Key *load_identity_file(char *); @@ -243,6 +247,10 @@ userauth_hostbased, &options.hostbased_authentication, NULL}, + {"certkey", + userauth_certkey, + &options.certkey_authentication, + NULL}, {"publickey", userauth_pubkey, &options.pubkey_authentication, @@ -472,7 +480,11 @@ */ TAILQ_FOREACH_REVERSE(id, &authctxt->keys, idlist, next) { if (key_equal(key, id->key)) { - sent = sign_and_send_pubkey(authctxt, id); + if (!strcmp(authctxt->method->name, "certkey")) { + if (id->key->cert != NULL) + sent = sign_and_send_certkey(authctxt, id); + } else + sent = sign_and_send_pubkey(authctxt, id); break; } } @@ -851,6 +863,93 @@ } static int +sign_and_send_certkey(Authctxt *authctxt, Identity *id) +{ + Buffer b; + u_char *blob, *signature; + u_int bloblen, slen; + u_int skip = 0; + int ret = -1; + int have_sig = 1; + + debug3("sign_and_send_certkey"); + + if (key_to_blob(id->key, &blob, &bloblen) == 0) { + /* we cannot handle this key */ + debug3("sign_and_send_certkey: cannot handle key"); + return 0; + } + /* data to be signed */ + buffer_init(&b); + if (datafellows & SSH_OLD_SESSIONID) { + buffer_append(&b, session_id2, session_id2_len); + skip = session_id2_len; + } else { + buffer_put_string(&b, session_id2, session_id2_len); + skip = buffer_len(&b); + } + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->server_user); + buffer_put_cstring(&b, + datafellows & SSH_BUG_PKSERVICE ? + "ssh-userauth" : + authctxt->service); + if (datafellows & SSH_BUG_PKAUTH) { + buffer_put_char(&b, have_sig); + } else { + buffer_put_cstring(&b, authctxt->method->name); + buffer_put_char(&b, have_sig); + buffer_put_cstring(&b, key_ssh_name(id->key)); + } + buffer_put_string(&b, blob, bloblen); + + /* generate signature */ + ret = identity_sign(id, &signature, &slen, + buffer_ptr(&b), buffer_len(&b)); + if (ret == -1) { + xfree(blob); + buffer_free(&b); + return 0; + } +#ifdef DEBUG_PK + buffer_dump(&b); +#endif + if (datafellows & SSH_BUG_PKSERVICE) { + buffer_clear(&b); + buffer_append(&b, session_id2, session_id2_len); + skip = session_id2_len; + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->server_user); + buffer_put_cstring(&b, authctxt->service); + buffer_put_cstring(&b, authctxt->method->name); + buffer_put_char(&b, have_sig); + if (!(datafellows & SSH_BUG_PKAUTH)) + buffer_put_cstring(&b, key_ssh_name(id->key)); + buffer_put_string(&b, blob, bloblen); + } + xfree(blob); + + /* append signature */ + buffer_put_string(&b, signature, slen); + xfree(signature); + + buffer_put_string(&b, id->key->cert, strlen(id->key->cert)); + + /* skip session id and packet type */ + if (buffer_len(&b) < skip + 1) + fatal("userauth_pubkey: internal error"); + buffer_consume(&b, skip + 1); + + /* put remaining data from buffer into packet */ + packet_start(SSH2_MSG_USERAUTH_REQUEST); + packet_put_raw(buffer_ptr(&b), buffer_len(&b)); + buffer_free(&b); + packet_send(); + + return 1; +} + +static int sign_and_send_pubkey(Authctxt *authctxt, Identity *id) { Buffer b; @@ -936,6 +1035,31 @@ } static int +send_certkey_test(Authctxt *authctxt, Identity *id) +{ + u_char *blob; + u_int bloblen, have_sig = 0; + + if (key_to_blob(id->key, &blob, &bloblen) == 0) + return 0; + /* register callback for USERAUTH_PK_OK message */ + dispatch_set(SSH2_MSG_USERAUTH_PK_OK, &input_userauth_pk_ok); + + packet_start(SSH2_MSG_USERAUTH_REQUEST); + packet_put_cstring(authctxt->server_user); + packet_put_cstring(authctxt->service); + packet_put_cstring(authctxt->method->name); + packet_put_char(have_sig); + if (!(datafellows & SSH_BUG_PKAUTH)) + packet_put_cstring(key_ssh_name(id->key)); + packet_put_string(blob, bloblen); + xfree(blob); + packet_put_string(id->key->cert, strlen(id->key->cert)); + packet_send(); + return 1; +} + +static int send_pubkey_test(Authctxt *authctxt, Identity *id) { u_char *blob; @@ -1095,6 +1219,42 @@ xfree(id->filename); xfree(id); } +} + +int +userauth_certkey(Authctxt *authctxt) +{ + Identity *id; + int sent = 0; + + while ((id = TAILQ_FIRST(&authctxt->keys))) { + if (id->triedcert++) + return (0); + /* move key to the end of the queue */ + TAILQ_REMOVE(&authctxt->keys, id, next); + TAILQ_INSERT_TAIL(&authctxt->keys, id, next); + /* + * send a test message if we have the public key. for + * encrypted keys we cannot do this and have to load the + * private key instead + */ + if (id->key && id->key->cert && id->key->type != KEY_RSA1) { + debug("Offering public key: %s", id->filename); + sent = send_certkey_test(authctxt, id); + } else if (id->key == NULL) { + debug("Trying private key: %s", id->filename); + id->key = load_identity_file(id->filename); + if (id->key != NULL && id->key->cert != NULL) { + id->isprivate = 1; + sent = sign_and_send_certkey(authctxt, id); + key_free(id->key); + id->key = NULL; + } + } + if (sent) + return (sent); + } + return (0); } int Index: sshd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd.c,v retrieving revision 1.348 diff -u -r1.348 sshd.c --- sshd.c 6 Nov 2006 21:25:28 -0000 1.348 +++ sshd.c 15 Nov 2006 14:14:40 -0000 @@ -1999,6 +1999,7 @@ kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server; kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; + kex->kex[KEX_DH_GEX_CERT] = kexgex_server; kex->server = 1; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; Index: sshd_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.70 diff -u -r1.70 sshd_config.5 --- sshd_config.5 21 Aug 2006 08:14:01 -0000 1.70 +++ sshd_config.5 15 Nov 2006 14:14:41 -0000 @@ -167,6 +167,15 @@ authentication is allowed. This option is only available for protocol version 2. By default, no banner is displayed. +.It Cm CAKeyFile +Specifies a file containing a public CA key. +The default is +.Pa /etc/ssh/ca.pub . +.It Cm CertkeyAuthentication +Specifies whether certified key authentication is allowed. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. .It Cm ChallengeResponseAuthentication Specifies whether challenge-response authentication is allowed. All authentication styles from Index: sshd/Makefile =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd/Makefile,v retrieving revision 1.64 diff -u -r1.64 Makefile --- sshd/Makefile 23 Aug 2004 14:26:39 -0000 1.64 +++ sshd/Makefile 15 Nov 2006 14:14:41 -0000 @@ -14,7 +14,7 @@ auth.c auth1.c auth2.c auth-options.c session.c \ auth-chall.c auth2-chall.c groupaccess.c \ auth-skey.c auth-bsdauth.c auth2-hostbased.c auth2-kbdint.c \ - auth2-none.c auth2-passwd.c auth2-pubkey.c \ + auth2-none.c auth2-passwd.c auth2-pubkey.c auth2-certkey.c \ monitor_mm.c monitor.c monitor_wrap.c \ kexdhs.c kexgexs.c --- /dev/null Wed Nov 15 15:14:51 2006 +++ auth2-certkey.c Wed Nov 15 11:07:56 2006 @@ -0,0 +1,196 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2000 Markus Friedl. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include + +#include +#include +#include + +#include "xmalloc.h" +#include "ssh.h" +#include "ssh2.h" +#include "packet.h" +#include "buffer.h" +#include "log.h" +#include "servconf.h" +#include "compat.h" +#include "key.h" +#include "hostfile.h" +#include "auth.h" +#include "pathnames.h" +#include "uidswap.h" +#include "auth-options.h" +#include "canohost.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif +#include "monitor_wrap.h" +#include "misc.h" + +/* import */ +extern ServerOptions options; +extern u_char *session_id2; +extern u_int session_id2_len; + +static int +userauth_certkey(Authctxt *authctxt) +{ + Buffer b; + Key *key = NULL; + char *pkalg; + u_char *pkblob, *sig, *cert; + u_int alen, blen, slen, clen; + int have_sig, pktype; + int authenticated = 0; + + if (!authctxt->valid) { + debug2("userauth_certkey: disabled because of invalid user"); + return 0; + } + have_sig = packet_get_char(); + if (datafellows & SSH_BUG_PKAUTH) { + debug2("userauth_certkey: SSH_BUG_PKAUTH"); + /* no explicit pkalg given */ + pkblob = packet_get_string(&blen); + buffer_init(&b); + buffer_append(&b, pkblob, blen); + /* so we have to extract the pkalg from the pkblob */ + pkalg = buffer_get_string(&b, &alen); + buffer_free(&b); + } else { + pkalg = packet_get_string(&alen); + pkblob = packet_get_string(&blen); + } + pktype = key_type_from_name(pkalg); + if (pktype == KEY_UNSPEC) { + /* this is perfectly legal */ + logit("userauth_certkey: unsupported public key algorithm: %s", + pkalg); + goto done; + } + key = key_from_blob(pkblob, blen); + if (key == NULL) { + error("userauth_certkey: cannot decode key: %s", pkalg); + goto done; + } + if (key->type != pktype) { + error("userauth_certkey: type mismatch for decoded key " + "(received %d, expected %d)", key->type, pktype); + goto done; + } + if (have_sig) { + sig = packet_get_string(&slen); + cert = packet_get_string(&clen); + if (!cert || clen <= 0) { + error("userauth_certkey: no cert"); + goto done; + } + key->cert = xstrdup(cert); + packet_check_eom(); + buffer_init(&b); + if (datafellows & SSH_OLD_SESSIONID) { + buffer_append(&b, session_id2, session_id2_len); + } else { + buffer_put_string(&b, session_id2, session_id2_len); + } + /* reconstruct packet */ + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->user); + buffer_put_cstring(&b, + datafellows & SSH_BUG_PKSERVICE ? + "ssh-userauth" : + authctxt->service); + if (datafellows & SSH_BUG_PKAUTH) { + buffer_put_char(&b, have_sig); + } else { + buffer_put_cstring(&b, "certkey"); + buffer_put_char(&b, have_sig); + buffer_put_cstring(&b, pkalg); + } + buffer_put_string(&b, pkblob, blen); +#ifdef DEBUG_PK + buffer_dump(&b); +#endif + /* test for correct signature */ + authenticated = 0; + if (PRIVSEP(user_cert_key_allowed(authctxt->pw, key)) && + PRIVSEP(key_verify(key, sig, slen, buffer_ptr(&b), + buffer_len(&b))) == 1) + authenticated = 1; + buffer_free(&b); + xfree(sig); + } else { + debug("test whether pkalg/pkblob are acceptable"); + cert = packet_get_string(&clen); + if (!cert || clen <= 0) { + error("userauth_certkey: no cert"); + goto done; + } + key->cert = xstrdup(cert); + packet_check_eom(); + + if (PRIVSEP(user_cert_key_allowed(authctxt->pw, key))) { + packet_start(SSH2_MSG_USERAUTH_PK_OK); + packet_put_string(pkalg, alen); + packet_put_string(pkblob, blen); + packet_send(); + packet_write_wait(); + authctxt->postponed = 1; + } + } + if (authenticated != 1) + auth_clear_options(); +done: + debug2("userauth_certkey: authenticated %d pkalg %s", authenticated, pkalg); + if (key != NULL) + key_free(key); + xfree(pkalg); + xfree(pkblob); + return authenticated; +} + +/* check whether given key is signed by certificate */ +int +user_cert_key_allowed(struct passwd *pw, Key *key) +{ + int allowed = 0; + Key *ca_key; + + temporarily_use_uid(pw); + ca_key = key_load_public(options.ca_key_file, NULL); + restore_uid(); + allowed = cert_verify(key->cert, ca_key, key, pw->pw_name); + if (ca_key != NULL) + key_free(ca_key); + return allowed; +} + +Authmethod method_certkey = { + "certkey", + userauth_certkey, + &options.certkey_authentication +}; From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 14:52:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 478BA16A415 for ; Wed, 15 Nov 2006 14:52:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEE9043D7C for ; Wed, 15 Nov 2006 14:52:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 20262 invoked from network); 15 Nov 2006 14:44:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 14:44:48 -0000 Message-ID: <455B29A4.3000601@freebsd.org> Date: Wed, 15 Nov 2006 15:52:20 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Daniel Hartmeier References: <20061115142820.GB14649@insomnia.benzedrine.cx> In-Reply-To: <20061115142820.GB14649@insomnia.benzedrine.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 14:52:22 -0000 Daniel Hartmeier wrote: > This patch against OpenBSD -current adds a simple form of PKI to > OpenSSH. We'll be using it at work. See README.certkey (the first chunk > of the patch) for details. > > Everything below is BSD licensed, sponsored by Allamanda Networks AG. As the one who assigned this work to Daniel Hartmeier I can add the rationale for this simple and easy PKI functionality in OpenSSH. Rationale for PKI in OpenSSH: Managing a large m:n relationship of users and hosts in OpenSSH is tedious and requires the use of scripting and rsync distribution methods for known_hosts and authorized_keys with all associated failure modes. Users tend not to verify server pubkey fingerprints out of band upon the first connection attempt which weakens the strong theoretic security of SSHs public key system. Known_hosts and authorized_keys do not contain any validity or expiration information. Reality shows that a lot of cruft and old information tends to remain. This tends to accidentally leave once granted privileges to users or hosts which should no longer posses them. It requires strict discipline to properly clean up and stay up to date on n hosts. What does OpenSSH PKI do: It does three things: a) It adds a certificate to the public key of a ssh server so the ssh client can verify the authenticity of a server pubkey without having to rely on other unspecified out of band methods (on first connection) or the known_hosts file (on subsequent connections). b) It adds a certificate to the public key of a ssh user so the ssh server can verify the authenticity of a users pubkey without having to have a pre-populated authorized_keys file in each users home directory on all machines this user has access to. c) It adds a number of optional fields in the certificate which can specify additional constrains on the hosts and users. The constrains include lists of IP addresses or networks which limit where the clients or server can connect to/from. This way hosts with a number of interfaces can be handled as one entity. Moving/copying of server pub/privkeys to a different IP address is prevented. Users may be restricted to be able to login only from defined list of IP addresses/networks specified in the certificate. What are the advantages: Only the CA's public key has to be distributed once to all hosts. -> Can be rolled into the host setup procedure/automation. The CA has to sign each host or user public key once. None of the user or host keys have to be distributed (copied) to all other hosts. -> Instant acceptance by all hosts with the same CA pubkey. The addition of any users or hosts is controlled by the CA. -> Single point of entry and control. The CA specifies the expiry date of any user and host certificate thus a policy can regularly timeout any of them. -> Any old cruft and temporary privileges expire by itself w/o having to individually check all hosts for them. Who is it for: Centrally managed organizations or collections of hosts which trust a single master role (the CA certification authority, a.k.a 'root'). Many real world deployments do resemble the single trust model of a CA. What are the risks: All trust and authentication/authorization is vested in the operator of the CA and the strength and secrecy of the CA private key. If the CA operator or the CA private key are compromised all doors are open. The CA operator is equal to 'root' which is trusted anyway. He can do everything root can do (that is reading/modifying each users private keys and authorized keys files). Less severe incidents include lost or compromised user keys. OpenSSH PKI gives two methods to deal with this. First it allows to specify an expiry date for all certificates. If set sufficiently short all certs lose their usefulness quickly. All users have to be re-certified in intervals and the re-certification can be tied to any number of administrative criteria. For immediate reactions any number of public key fingerprints can be blacklisted on the ssh server. This is a simple file based certificate revocation. Online revocation checks could optionally be implemented as well. The operator then has to specify whether to fail open or close depending on priorities and risk assessments. Why not implement/use X.509 or OpenPGP PKI methods: The goal is to use only basic and non-complex cryptographic methods which are widely available and do *not* require the installation of additional software libraries (eg. OpenPGP SDK or OpenSSL for OpenBSD) and a simple and modular certificate binary format (no ASN.1 or such). It should work out of the box on all currently supported OpenSSH platforms without any external dependencies. This OpenSSH PKI system is very simple and easy to use. All programs and functions necessary to use it to its full extent are included with the base OpenSSH distribution. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 17:06:51 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA04C16A40F for ; Wed, 15 Nov 2006 17:06:51 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AAC343D92 for ; Wed, 15 Nov 2006 17:06:29 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id CA2459B35A for ; Wed, 15 Nov 2006 18:06:26 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id AA8149E6C2 for ; Wed, 15 Nov 2006 17:06:57 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 8104F405B; Wed, 15 Nov 2006 18:06:57 +0100 (CET) Date: Wed, 15 Nov 2006 18:06:57 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20061115170657.GM20405@obiwan.tataz.chchile.org> References: <20061115141838.GL20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline In-Reply-To: <20061115141838.GL20405@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: psm(4) stopped working suddently X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 17:06:51 -0000 --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 15, 2006 at 03:18:38PM +0100, Jeremie Le Hen wrote: > Hi, > > my touchpad has been working like a charm until recently, then I > noticed psm0 didn't exist any more. > A verbose boot shows the following message in dmesg: > > % jarjarbinks:~:107# dmesg | grep ^psm > % psm0: unable to allocate IRQ > % psmcpnp0: irq 12 on acpi0 > % psm0: current command byte:0047 > % psm0: strange result for test aux port (1). > % psm0: failed to reset the aux device > > Therefore, I added PSM_CONFIG_NORESET (0x400) to hint.psm.0.cflags > in loader.conf(5) and this made psm0 come back and the touchpad work. > > I tried older kernels back to 2006.03.01 but none made my touchpad > work without this flag. I tested with FreeSBIE 2.0 beta, based on FreeBSD 6.1-RELEASE-p3 and I didn't see the problem. Given that I tried kernels back to March 1st, I went to expect my kernel config file was the culprit. Thus I've just tried a GENERIC kernel from the latest -CURRENT and the problem went away: % psm0: unable to allocate IRQ % psmcpnp0: irq 12 on acpi0 % psm0: current command byte:0047 % psm0: strange result for test aux port (1). % psm0: irq 12 on atkbdc0 % psm0: [GIANT-LOCKED] % psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons % psm0: config:00000000, flags:00000008, packet size:3 % psm0: syncmask:c0, syncbits:00 I tried to add/remove kbdmux and apic, but this resulted in nothing better. My configuration file is attached, I would be glad if someone pointed out what makes my psm(4) fail. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=JARJARBINKS # Z6PO kernel config. machine i386 cpu I686_CPU ident JARJARBINKS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices makeoptions DEBUG="-g" # Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE="linux syscons fdc sound usb ums geom umass snp nullfs unionfs cd9660 cd9660_iconv wlan wlan_wep wlan_tkip wlan_ccmp wi iwi ral rl bge drm/drm drm/radeon firmware ext2fs" makeoptions CPUTYPE="pentium-m" makeoptions CFLAGS="-O -pipe" # # Debugging features # options PREEMPTION # Allow threads to be preempted #options FULL_PREEMPTION # Expose race conditions options MUTEX_DEBUG # Enable extra assert in mutex code options KDB # Enable kernel debugger support options DDB # Support DDB options GDB # Support remote GDB options INVARIANT_SUPPORT # Extra sanity checks of internal struct options INVARIANTS # Enable calls of extra sanity checking options DIAGNOSTIC # Make everything more noisy #options WITNESS # Enable checks for deadlocks and cycles #options WITNESS_KDB options KSE options SCHED_4BSD # 4BSD scheduler #options SCHED_ULE # ULE scheduler #options SCHED_CORE options INCLUDE_CONFIG_FILE # # Disk and filesystems # options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options SUIDDIR #options EXT2FS # Linux filesystem options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options MSDOSFS_LARGE #options NTFS # NT filesystem #options NULLFS # NULL filesystem #options UNIONFS # Union filesystem #options CD9660 # ISO 9660 Filesystem #options UDF # Univesal Disk Format options PSEUDOFS # Pseudo-filesystem framework options PROCFS # Process filesystem (requires PSEUDOFS) options FDESCFS options LIBICONV options MSDOSFS_ICONV #options CD9660_ICONV #options UDF_ICONV #options NTFS_ICONV #options NETSMB #options NETSMBCRYPTO #options LIBMCHAIN #options SMBFS # # Misc # options SSP_SUPPORT options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] #options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #option COMPAT_FREEBSD5 #option COMPAT_FREEBSD6 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 realtime extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev # # Network # options INET # InterNETworking #options INET6 # IPv6 communications protocols options IPSEC # IP security options IPSEC_ESP # IP security with ESP options IPSEC_FILTERGIF # Filter IPSec packets from a tunnel #options BRIDGE # Bridging between ethernet cards options IPFIREWALL # IP firewall options IPFIREWALL_VERBOSE # Enable logging to syslogd(8) options IPFIREWALL_DEFAULT_TO_ACCEPT # Allow everything by default options IPFIREWALL_FORWARD # Make packet destination change #options IPV6FIREWALL # IPv6 firewall #options IPV6FIREWALL_VERBOSE #options IPV6FIREWALL_DEFAULT_TO_ACCEPT #options IPFILTER # IPFilter support #options IPFILTER_LOG # IPFilter logging device pf # PF OpenBSD packet-filter firewall device pflog # Logging support interface for PF device pfsync # Synchronization interface for PF options IPDIVERT # Divert sockets options DUMMYNET # Enables "dummyney" bandwidth limiter #options ALTQ #options ALTQ_CBQ # Class Bases Queueing #options ALTQ_RED # Random Early Drop #options ALTQ_RIO # RED In/Out #options ALTQ_HFSC # Hierarchical Packet Scheduler #options ALTQ_CDNR # Traffic conditioner #options ALTQ_PRIQ # Priority Queueing #options NETGRAPH #netgraph(4) system #options NETGRAPH_ASYNC #options NETGRAPH_ATMLLC #options NETGRAPH_ATM_ATMPIF #options NETGRAPH_BLUETOOTH # ng_bluetooth(4) #options NETGRAPH_BLUETOOTH_BT3C # ng_bt3c(4) #options NETGRAPH_BLUETOOTH_H4 # ng_h4(4) #options NETGRAPH_BLUETOOTH_HCI # ng_hci(4) #options NETGRAPH_BLUETOOTH_L2CAP # ng_l2cap(4) #options NETGRAPH_BLUETOOTH_SOCKET # ng_btsocket(4) #options NETGRAPH_BLUETOOTH_UBT # ng_ubt(4) #options NETGRAPH_BLUETOOTH_UBTBCMFW # ubtbcmfw(4) #options NETGRAPH_BPF #options NETGRAPH_BRIDGE #options NETGRAPH_CISCO #options NETGRAPH_ECHO #options NETGRAPH_EIFACE #options NETGRAPH_ETHER #options NETGRAPH_FEC #options NETGRAPH_FRAME_RELAY #options NETGRAPH_GIF #options NETGRAPH_GIF_DEMUX #options NETGRAPH_HOLE #options NETGRAPH_IFACE #options NETGRAPH_IP_INPUT #options NETGRAPH_KSOCKET #options NETGRAPH_L2TP #options NETGRAPH_LMI #options NETGRAPH_ONE2MANY #options NETGRAPH_PPP #options NETGRAPH_PPPOE #options NETGRAPH_PPTPGRE #options NETGRAPH_RFC1490 #options NETGRAPH_SOCKET #options NETGRAPH_SPLIT #options NETGRAPH_SPPP #options NETGRAPH_TEE #options NETGRAPH_TTY #options NETGRAPH_UI #options NETGRAPH_VJC # # Geom # #options GEOM_AES #options GEOM_APPLE #options GEOM_BDE #options GEOM_BSD #options GEOM_CONCAT #options GEOM_FOX #options GEOM_GATE #options GEOM_GPT #options GEOM_LABEL #options GEOM_MBR #options GEOM_MIRROR #options GEOM_NOP #options GEOM_PC98 #options GEOM_RAID3 #options GEOM_SHSEC #options GEOM_STRIPE #options GEOM_SUNLABEL #options GEOM_UZIP #options GEOM_VOL # # Pseudo devices # device random # Entropy device device mem # Memory and kernel memory devices device io device pty # Pseudo-ttys (telnet etc) device snp # Snoop device - to look at pty/vty/... #device ccd # Concatenated disk driver device md # Memory "disks" #device firmware # # Network pseudo devices # device loop # Network loopback device ether # Ethernet support device vlan # VLAN support (needs miibus) #device sl # Kernel SLIP #device ppp # Kernel PPP #device sppp # Generic Synchronous PPP device tun # Packet tunnel device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) #device stf # 6to4 IPv6 over IPv4 encapsulation device tap # Virtual Ethernet driver #device gre # IP over IP tunneling device bpf # Berkeley packet filter device if_bridge #options PPP_BSDCOMP # PPP BSD-compress support #options PPP_DEFLATE # PPP zlib/deflate/gzip support #options PPP_FILTER # Enable bpf filtering (needs bpf) # # Devices # device apic # I/O APIC device acpi #options ACPI_DEBUG device cpufreq # Bus support. Do not remove isa, even if you have no isa slots device isa 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 device atapicam # emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) 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) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse #options PSM_DEBUG device kbdmux options VESA # Support for VGA VESA video modes. device vga # VGA video card driver device splash # Splash screen and screen saver support device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Direct Rendering modules for 3D acceleration. #device drm # DRM core module required by DRM drivers #device i915drm # Intel i830 through i915 # Floating point support - do not disable device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254 device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges 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 # 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 the sio and/or ppc drivers): #device puc # PCI Ethernet NICs #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ether #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep #device wlan_ccmp #device wlan_tkip #device wlan_xauth #device wlan_acl #device an # Aironet 4500/4800 802.11 wireless NICs #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs #device wl # Older non 802.11 Wavelan wireless NIC #device ath_hal #device ath_rate_onoe #device ath #device iwi # # USB support # #options USB_DEBUG #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface #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 # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # # Sound # #device sound #device snd_maestro --LKTjZJSUETSlgu2t-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 18:04:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F98116A403; Wed, 15 Nov 2006 18:04:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C70043D5D; Wed, 15 Nov 2006 18:04:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkP7I-000MTQ-6o; Wed, 15 Nov 2006 18:04:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkP7E-000187-BK; Wed, 15 Nov 2006 08:04:04 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17755.22163.457287.603699@roam.psg.com> Date: Wed, 15 Nov 2006 08:04:03 -1000 To: Robert Watson References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> <20061114181823.K87081@fledge.watson.org> <17754.21277.210338.175055@roam.psg.com> Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 18:04:10 -0000 > Mike Tancsa suggested i try > ifconfig fxp0 media 10baseT/UTP > ifconfig fxp0 media autoselect > this worked! > > i will next reboot with in_fxp.c reverted to pre 2006.10.06. and this also worked. i.e. there is poison in the if_fxp.c update of 2006.10.06 randy From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 18:22:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D037216A412 for ; Wed, 15 Nov 2006 18:22:22 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D1843D5E for ; Wed, 15 Nov 2006 18:22:21 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so103637nzh for ; Wed, 15 Nov 2006 10:22:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B+SZ0neYo7Jx3A9JLRSEQHnnpzC2s9HxMngN41zb78oEOJK4cHrhaZuzUwww1r5CiBybqTy44TcVZZ13MgvyXAa5RU1YsAXfxpuDInZZJGP3hVq9ns4Xx6Y3/P457D25x/57uXgFyk938GI4dCFJLuQZc92O3fdUBcYiGk/DFE4= Received: by 10.35.103.1 with SMTP id f1mr3725027pym.1163614939476; Wed, 15 Nov 2006 10:22:19 -0800 (PST) Received: by 10.35.29.20 with HTTP; Wed, 15 Nov 2006 10:22:19 -0800 (PST) Message-ID: <3aaaa3a0611151022s38655a92ne2a7f450f97975bd@mail.gmail.com> Date: Wed, 15 Nov 2006 18:22:19 +0000 From: Chris To: "David Xu" In-Reply-To: <200611131701.25572.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061110151247.GA64530@zone3000.net> <200611130707.10220.davidxu@freebsd.org> <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com> <200611131701.25572.davidxu@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 18:22:22 -0000 On 13/11/06, David Xu wrote: > On Monday 13 November 2006 12:20, Chris wrote: > > > > Interesting libthr can use system or process scope? as far as I am > > aware it was using whatever the default is for libthr. > > > > Chris > > FreeBSD 6.1, the default is libthr uses process scope, but I know > mysql explicitly uses system scope thread unless you forced it > to use process scope(there is a knob in the ports's Makefile). > if the mysql uses system scope (the default), you should see > the same effect with libpthread, i.e you said it starved your > server. > > David Xu > in that case it was using process scope as I have that knob enabled. thanks Chris From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 17:48:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 420F516A412 for ; Wed, 15 Nov 2006 17:48:18 +0000 (UTC) (envelope-from beck@bofh.cns.ualberta.ca) Received: from bofh.cns.ualberta.ca (bofh.cns.ualberta.ca [129.128.11.10]) by mx1.FreeBSD.org (Postfix) with SMTP id CD0B843DAF for ; Wed, 15 Nov 2006 17:47:59 +0000 (GMT) (envelope-from beck@bofh.cns.ualberta.ca) Received: (qmail 4390 invoked from network); 15 Nov 2006 17:47:49 -0000 Received: from localhost (HELO bofh.cns.ualberta.ca) (127.0.0.1) by bofh.cns.ualberta.ca with SMTP; 15 Nov 2006 17:47:49 -0000 Received: (from beck@localhost) by bofh.cns.ualberta.ca (8.13.3/8.12.10/Submit) id kAFHlmgh026636; Wed, 15 Nov 2006 10:47:48 -0700 (MST) Date: Wed, 15 Nov 2006 10:47:47 -0700 From: Bob Beck To: Andre Oppermann Message-ID: <20061115174747.GE26418@bofh.cns.ualberta.ca> Mail-Followup-To: Andre Oppermann , Daniel Hartmeier , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org, markus@openbsd.org References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455B29A4.3000601@freebsd.org> User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Wed, 15 Nov 2006 18:55:05 +0000 Cc: Daniel Hartmeier , tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 17:48:18 -0000 Sigh. My objections to this are my objections to PKI implementations in general. In my experience PKI methods are implemented and deployed the same way people deploy half done raid drivers - we'll make the disk work, but we won't worry about how to monitor and fix it when it gets fucked up. "that'll be implemented later/left as an exercise for the deployer to hack up something disgusting" > > b) It adds a certificate to the public key of a ssh user so the ssh > server can verify the authenticity of a users pubkey without having > to have a pre-populated authorized_keys file in each users home > directory on all machines this user has access to. > keys and authorized keys files). I maintain it does NOT do this - and here is why : > > Less severe incidents include lost or compromised user keys. OpenSSH > PKI gives two methods to deal with this. First it allows to specify > an expiry date for all certificates. If set sufficiently short all > certs lose their usefulness quickly. All users have to be re-certified > in intervals and the re-certification can be tied to any number of > administrative criteria. For immediate reactions any number of public > key fingerprints can be blacklisted on the ssh server. This is a simple > file based certificate revocation. Online revocation checks could > optionally be implemented as well. The operator then has to specify > whether to fail open or close depending on priorities and risk > assessments. In other words, I have to maintain a pre-populated "un-authorized" keys file because in any real deployment you are GOING to have these. and quite frequently with any sizable deployment. So I still have to maintain a file. "authorized keys" -> anything that is not allowed is denied. "un-authorized keys" -> anything that is not denied is allowed. NOT being prepared to maintain a file when doing this is pretty much akin to "Don't worry, I'll pull out before I cum". Everything's great until there a problem and then it's a fuckshow. I.E. this is the same "it's really cool and we almost have it right" argument I've seen from everything pushing PKI and x509 goo as authentication. An expiry date for all the user certs? gimme a break. even setting it to a month (which would be a pita to have users constantly re-certed) means someone gets a month to fuck around. Even suggesting that certificate expiry times should be used to mitigate this is irresponsible. You have to be able to nail something you know is compromised quickly. The only thing expiry times to is A) make money for commercial CA's, B) make stuff not have to stay forever in your CRL if you have one. Don't get me wrong, I think this is possibly useful, but I don't think it should go in incomplete like this. In my view it is complete where when turning it on you specify a set of (possibly other) ssh server(s) the server itself will connect to and use as a CRL when presented with a key. - i.e. we should make it decently doable and document how to use a CRL in this case. I feel quite strongly that without tying the last piece together, we're handing people an incomplete thing with enough rope to hang themselves - "Here's a nice thing for a centralized deployment but oops if a luser loses a key you have to run around and do a panty raid to all your servers, because we left that as an exercise just like every other fucktard that implements this stuff does instead of giving you the tools to do it right" So, My two cents, make it complete first. Making an archetecture for ssh that makes it easy to add trust centrally WITHOUT MAKING IT EASY TO REMOVE IT is irresponsible. (Now I'll go away and be cranky elsewhere, having a bad day) -Bob From owner-freebsd-current@FreeBSD.ORG Wed Nov 15 22:33:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEB7A16A4A0 for ; Wed, 15 Nov 2006 22:33:10 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D03FF43D62 for ; Wed, 15 Nov 2006 22:32:49 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 25076 invoked from network); 15 Nov 2006 22:25:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 22:25:14 -0000 Message-ID: <455B9590.3050104@freebsd.org> Date: Wed, 15 Nov 2006 23:32:48 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andre Oppermann , Daniel Hartmeier , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org, markus@openbsd.org References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> In-Reply-To: <20061115174747.GE26418@bofh.cns.ualberta.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Nov 2006 22:33:11 -0000 Bob Beck wrote: > Sigh. My objections to this are my objections to PKI implementations > in general. In my experience PKI methods are implemented and deployed > the same way people deploy half done raid drivers - we'll make the > disk work, but we won't worry about how to monitor and fix it when it > gets fucked up. "that'll be implemented later/left as an exercise for > the deployer to hack up something disgusting" Well, we post these patches to solicit valuable input and to refine it based on all the smart brains choosing to care. In our primary application we exactly want offline mode (the ability to login even if half or most of the network is down). We actually are the network we want to bring up again. Here we had to make a tradeoff and traded the ability to revoke a certificate against not being able to recover the network. Yeah, this is an easy one to make. ;-) Nonetheless we want to feed back a useful solution to the community and I've assigned some more developer time (Daniel Hartmeier) to address your concerns. >> b) It adds a certificate to the public key of a ssh user so the ssh >> server can verify the authenticity of a users pubkey without having >> to have a pre-populated authorized_keys file in each users home >> directory on all machines this user has access to. >> keys and authorized keys files). > > I maintain it does NOT do this - and here is why : > >> Less severe incidents include lost or compromised user keys. OpenSSH >> PKI gives two methods to deal with this. First it allows to specify >> an expiry date for all certificates. If set sufficiently short all >> certs lose their usefulness quickly. All users have to be re-certified >> in intervals and the re-certification can be tied to any number of >> administrative criteria. For immediate reactions any number of public >> key fingerprints can be blacklisted on the ssh server. This is a simple >> file based certificate revocation. Online revocation checks could >> optionally be implemented as well. The operator then has to specify >> whether to fail open or close depending on priorities and risk >> assessments. > > In other words, I have to maintain a pre-populated "un-authorized" > keys file because in any real deployment you are GOING to have these. > and quite frequently with any sizable deployment. So I still have > to maintain a file. > > "authorized keys" -> anything that is not allowed is denied. > "un-authorized keys" -> anything that is not denied is allowed. > > NOT being prepared to maintain a file when doing this > is pretty much akin to "Don't worry, I'll pull out before I cum". Everything's > great until there a problem and then it's a fuckshow. Well, step 1 is to have something that is better than reality shows today while requiring the same effort or dealing with the same laziness. There are way too many people out there who handle the security OpenSSH could provide in a very ineffective and dangerous way. If we can lift them up to the next practical security level while maintaining the same ease of use (or inappropriate practices) and laziness I call it a first success. Step 2 is to make the theoretical perfect security a reality by maintaining (almost) the same ease of use and laziness on part of the user. For the administrator it must mean only a very slight increase in inconvenience and effort with the clear payoff of much increased security. Step 1 we IMHO have mastered. Lets work on Step 2. See below. > I.E. this is the same "it's really cool and we almost have it right" > argument I've seen from everything pushing PKI and x509 goo as > authentication. An expiry date for all the user certs? gimme a break. > even setting it to a month (which would be a pita to have users > constantly re-certed) means someone gets a month to fuck around. Even > suggesting that certificate expiry times should be used to mitigate > this is irresponsible. You have to be able to nail something you know > is compromised quickly. The only thing expiry times to is A) make > money for commercial CA's, B) make stuff not have to stay forever in > your CRL if you have one. The latter is our main motivator. ;-) > Don't get me wrong, I think this is possibly useful, but I don't > think it should go in incomplete like this. In my view it is complete > where when turning it on you specify a set of (possibly other) ssh > server(s) the server itself will connect to and use as a CRL when > presented with a key. - i.e. we should make it decently doable and > document how to use a CRL in this case. I feel quite strongly that > without tying the last piece together, we're handing people an > incomplete thing with enough rope to hang themselves - "Here's a nice > thing for a centralized deployment but oops if a luser loses a key you > have to run around and do a panty raid to all your servers, because we > left that as an exercise just like every other fucktard that > implements this stuff does instead of giving you the tools to do it > right" > > So, My two cents, make it complete first. Making an archetecture > for ssh that makes it easy to add trust centrally WITHOUT MAKING IT EASY > TO REMOVE IT is irresponsible. Ok, I've devised a way to easily configure and run a secure CAL (Certificate Authorization List) that can just as easily be distributed to multiple redundant CAL Servers. We'll implement it tomorrow (after some internal discussion with claudio&dhartmei) and post it here for review as an updated OpenSSH PKI patch. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 01:59:26 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D9316A412; Thu, 16 Nov 2006 01:59:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DC6843D4C; Thu, 16 Nov 2006 01:59:24 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DA30748800; Thu, 16 Nov 2006 02:59:23 +0100 (CET) Received: from localhost (djy66.neoplus.adsl.tpnet.pl [83.24.2.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3A10045684; Thu, 16 Nov 2006 02:59:17 +0100 (CET) Date: Thu, 16 Nov 2006 02:59:08 +0100 From: Pawel Jakub Dawidek To: freebsd-fs@FreeBSD.org Message-ID: <20061116015908.GB63195@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-current@FreeBSD.org Subject: ZFS patches for FreeBSD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@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, 16 Nov 2006 01:59:26 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. This is a first set of patches, which allows to use ZFS file system from OpenSolaris on FreeBSD. To apply the patch you need to have recent FreeBSD source (be sure you have rev. 1.284 of src/sys/kern/kern_synch.c). To try it out you need i386 machine (this is what I tested) and kernel without WITNESS compiled in (there are probably some warnings still). Currently it can only be compiled as a kernel module. To apply the patch you need the following steps: # cd /usr/src # mkdir -p cddl/lib/lib{avl,nvpair,umem,uutil,zfs,zpool} # mkdir -p cddl/usr.bin/ztest # mkdir -p cddl/usr.sbin/{zdb,zfs,zpool} # mkdir -p compat/opensolaris/{include,misc} # mkdir -p contrib/opensolaris/cmd/{zdb,zfs,zpool,ztest} # mkdir -p contrib/opensolaris/common/{acl,avl,nvpair,zfs} # mkdir -p contrib/opensolaris/head # mkdir -p contrib/opensolaris/lib/libnvpair # mkdir -p contrib/opensolaris/lib/lib{uutil,zfs}/common # mkdir -p contrib/opensolaris/lib/libzpool/common/sys # mkdir -p sys/compat/opensolaris/{kern,machine,rpc,sys} # mkdir -p sys/contrib/opensolaris/uts/common/fs/zfs/sys # mkdir -p sys/contrib/opensolaris/uts/common/{os,rpc} # mkdir -p sys/contrib/opensolaris/uts/common/sys/fm/fs # mkdir -p sys/contrib/opensolaris/uts/common/sys/fs # mkdir -p sys/modules/zfs # fetch http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2 # bzip2 -d zfs_20061117.patch.bz2 # patch < zfs_20061117.patch # make buildworld # make kernel # make installworld # kldload zfs.ko (zfs and zpool command should work now) Before reboot: # zfs export After reboot: # kldload zfs.ko # zfs import After a panic: # kldload zfs.ko # zfs mount -a # zfs volinit Most of the functionality should work, but there are exceptions. zfs share/unshare don't work yet, you also won't be able to export ZFS files systems via NFS. ACLs don't work yet. The ZFS file system is MPSAFE (it operates without the Giant lock), but performance isn't quite there yet. Please do not report that it is slower than UFS, etc. I know it is. On the other hand you should report if there are some huge differences in performance between UFS and ZFS, for example if ZFS is few times slower in some workloads. Under very heavy load (or maybe even under not that heavy load, but after a longer time) it may panic with "kmem_malloc(X): kmem_map too small: Y total allocated" message. The back-presure mechanism doesn't work well and SUN guys are helping me to figure out why. If you see such panic, please do not report it, just reboot your machine and continue (or not). Please do report any other strange panics or situations (like various commands not working as they should, you see strange file system behaviour, etc.), _but_ before reporting any issue, verify that it wasn't already reported on freebsd-fs@FreeBSD.org mailing list. If you have any questions or comments, I'd prefer if you send them to the mailing list instead of me privately, as it's quite possible others would like to know too. Good luck and enjoy! Big thanks to ZFS developers for great work and to SUN for opening ZFS source! --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFW8XsForvXbEpPzQRAopsAKCxij/eju0khuMs7X9QQyXlM8ZunwCdG59o GSciI9I5WqSCoCavql2RGAk= =3p1N -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 01:05:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C82D016A47B for ; Thu, 16 Nov 2006 01:05:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D0CF43D75 for ; Thu, 16 Nov 2006 01:05:06 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GkVgc-0007Ds-Jh for freebsd-current@freebsd.org; Thu, 16 Nov 2006 02:05:02 +0100 Received: from wsrcc-nat.wsrcc.com ([64.142.50.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 02:05:02 +0100 Received: from wolfgang+gnus200611 by wsrcc-nat.wsrcc.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 02:05:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wolfgang S. Rupprecht" Date: Wed, 15 Nov 2006 16:53:55 -0800 Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 40 Message-ID: <87odr8i53w.fsf@arbol.wsrcc.com> References: <20061115142820.GB14649@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: wsrcc-nat.wsrcc.com X-WSRCC: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:za2CuzvPV9XNUyvSzjpNFmSUPes= Sender: news X-Mailman-Approved-At: Thu, 16 Nov 2006 02:13:41 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 01:05:11 -0000 Daniel Hartmeier writes: > This patch against OpenBSD -current adds a simple form of PKI to > OpenSSH. We'll be using it at work. Sounds like something that was needed for a while. > +A host certificate is a guarantee made by the CA that a host public key is > +valid. When a host public key carries a valid certificate, the client can > +use the host public key without asking the user to confirm the fingerprint > +manually and through out-of-band communication the first time. The CA takes > +the responsibility of verifying host keys, and users do no longer need to > +maintain known_hosts files of their own. This confuses the whole authentication vs. authorization concepts. authentication - "May I please see your drivers license?" authorization - "That's a valid license but I don't see your name on the list to go in." I would hate to have my ssh allow anyone in just because we used the same CA. I still see the authorized_keys file as having a very important role even if the first layer defense is to check if the certificate is signed by a CA I trust. > +The CA, specifically the holder of the CA private key (and its password, if it > +is password encrypted), holds broad control over hosts and user accounts set > +up in this way. Should the CA private key become compromised, all user > +accounts become compromised. > + > +There is no way to revoke a certificate once it has been published, the > +certificate is valid until it reaches the expiry date set by the CA. This fix is in the bag once authorized_keys gets consulted even for certificates. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 07:42:24 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1183E16A412 for ; Thu, 16 Nov 2006 07:42:24 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1109043D46 for ; Thu, 16 Nov 2006 07:42:22 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 66562 invoked from network); 16 Nov 2006 07:42:40 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 16 Nov 2006 07:42:40 -0000 Message-ID: <455C165D.5080702@FreeBSD.org> Date: Thu, 16 Nov 2006 08:42:21 +0100 From: Alex Dupre User-Agent: Thunderbird 1.5.0.8 (X11/20061114) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <20061116015908.GB63195@garage.freebsd.pl> In-Reply-To: <20061116015908.GB63195@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS patches 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, 16 Nov 2006 07:42:24 -0000 Pawel Jakub Dawidek wrote: > This is a first set of patches, which allows to use ZFS file system from > OpenSolaris on FreeBSD. Thanks for your much appreciated work! > To apply the patch you need the following steps: > > # cd /usr/src > # mkdir -p cddl/lib/lib{avl,nvpair,umem,uutil,zfs,zpool} > # mkdir -p cddl/usr.bin/ztest > # mkdir -p cddl/usr.sbin/{zdb,zfs,zpool} > # mkdir -p compat/opensolaris/{include,misc} > # mkdir -p contrib/opensolaris/cmd/{zdb,zfs,zpool,ztest} > # mkdir -p contrib/opensolaris/common/{acl,avl,nvpair,zfs} > # mkdir -p contrib/opensolaris/head > # mkdir -p contrib/opensolaris/lib/libnvpair > # mkdir -p contrib/opensolaris/lib/lib{uutil,zfs}/common > # mkdir -p contrib/opensolaris/lib/libzpool/common/sys > # mkdir -p sys/compat/opensolaris/{kern,machine,rpc,sys} > # mkdir -p sys/contrib/opensolaris/uts/common/fs/zfs/sys > # mkdir -p sys/contrib/opensolaris/uts/common/{os,rpc} > # mkdir -p sys/contrib/opensolaris/uts/common/sys/fm/fs > # mkdir -p sys/contrib/opensolaris/uts/common/sys/fs > # mkdir -p sys/modules/zfs > # fetch http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2 > # bzip2 -d zfs_20061117.patch.bz2 > # patch < zfs_20061117.patch Is it not simpler/enough to replace all these commands with: # cd /usr/src # fetch http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2 # bzip2 -d zfs_20061117.patch.bz2 # patch -p0 < zfs_20061117.patch or even shorter: # cd /usr/src # fetch -o - \ http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2 \ | bunzip2 | patch -p0 ? The point is that using the '-p0' option we can avoid creating directories manually. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 11:08:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA3CA16A4D2; Thu, 16 Nov 2006 11:08:11 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F04D43D7E; Thu, 16 Nov 2006 11:06:45 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1Gkf4i-0004XL-IS; Thu, 16 Nov 2006 13:06:32 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gkf4h-00011r-PC; Thu, 16 Nov 2006 13:06:31 +0200 To: Robert Watson From: Ian FREISLICH In-Reply-To: Message from Robert Watson of "Wed, 15 Nov 2006 09:03:28 GMT." <20061115085427.R79655@fledge.watson.org> X-Attribution: BOFH Date: Thu, 16 Nov 2006 13:06:31 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2199/Thu Nov 16 05:54:28 2006) Cc: current@freebsd.org Subject: Re: Panic during boot (in_arpinput). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 11:08:11 -0000 Robert Watson wrote: > > On Wed, 15 Nov 2006, Ian FREISLICH wrote: > > > Robert Watson wrote: > >> On Wed, 15 Nov 2006, Ian FREISLICH wrote: > >> > >>> Ian FREISLICH wrote: > >>>> > >>>> I have 2 servers each with 255 vlan interfaces and carp interfaces in > >>>> each vlan.During the boot up while it's configuring the interfaces, it > >>>> reliably panics. It boots fine if no network cables are plugged in (and > >>>> in the test evironment on a quient lan). > >>>> > >>>> It's an SMP machine. My guess (from the panic message below) is that an > >>>> arp query arives on an interface it's in the middle of creating or > >>>> something like that (highly unsophisticated debugging conjecture). > >>>> > >>>> In the mean time I'm going to try a UP kernel and see if that masks the > >>>> problem. > >>> > >>> FWIW, a UP kernel has the same problem. > >> > >> What happens if you disable PREEMPTION on UP and try the same thing again? > > > > Same thing. > > > > If I don't assign the carp interfaces a vhid and pass at boot time, it boot s > > up OK, but I need the carp interfaces. I can arrange serial console access . > > I have a similar system from ~"Tue Aug 29 09:47:50 SAST 2006" that works, > > but I suspect it may suffer the same problem. I'm about to test this. > > This suggests that it is not the race I was worried it was, which is really > good news :-). This makes me suspect a CARP-specific bug as opposed to the > wider issue of under-synchronization of the address lists. I'm not sure that ia_hash from netinet/in_var.h: LIST_ENTRY(in_ifaddr) ia_hash; /* entry in bucket of inet addresses */ is being locked properly. Or somehow junk data is making its way into the list. I've narrowed it down to configuration errors in /etc/rc.conf. Bringing vlans or CARP interfaces up with some bogus data (due to cut and paste errors): ifconfig_vlan2001="vlandev em0 vlan 2001" ... ifconfig_vlan2001="vhid 1 pass 4f5116b5b66a5bcc3c096c72eeabb7bd" or ifconfig_carp166_name="vlan166_vrrp" ifconfig_carp167_name="vlan167_vrrp" ifconfig_vlan166_vrrp="vhid 161 advskew 0 pass 0f2c9a93eea6f38fabb3acb1c31488c6"ifconfig_vlan167_vrrp="vhid 161 advskew 0 pass 0f2c9a93eea6f38fabb3acb1c31488c6" Note that the 3rd and "4th" line depending on your terminal size are 1 line. It seems that when CARP interfaces are in play, even without addresses so their parent ip interfaces aren't in promiscuous mode, if an ifconfig at boot time produces an error: ifconfig: SIOCGVH: Invalid argument ifconfig: ioctl (SIOCAIFADDR): Can't assign requested address later, while it's printing the ifconfig data for the 255 vlans on the console, the system panics as previously written if it's ethernet recieves an arp request at a critical time. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 12:17:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6598A16A416 for ; Thu, 16 Nov 2006 12:17:49 +0000 (UTC) (envelope-from marc@msys.ch) Received: from sleipnir.msys.ch (smtp.msys.ch [157.161.101.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D7E43D5F for ; Thu, 16 Nov 2006 12:17:47 +0000 (GMT) (envelope-from marc@msys.ch) Received: from localhost (smtp.msys.ch [157.161.101.10]) by sleipnir.msys.ch (8.13.4/8.13.4) with ESMTP id kAGCHVOY008671; Thu, 16 Nov 2006 13:17:31 +0100 (CET) Received: from merlin.etc.msys.ch (merlin.etc.msys.ch [213.189.137.178]) by mail.msys.ch (Horde MIME library) with HTTP; Thu, 16 Nov 2006 13:17:31 +0100 Message-ID: <20061116131731.5101k7e5mokgw4o4@mail.msys.ch> Date: Thu, 16 Nov 2006 13:17:31 +0100 From: Marc Balmer To: Daniel Hartmeier References: <20061115142820.GB14649@insomnia.benzedrine.cx> In-Reply-To: <20061115142820.GB14649@insomnia.benzedrine.cx> 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.1) X-SMTP-Vilter-Version: 1.3.3 X-Spamd-Symbols: ALL_TRUSTED,AWL X-Mailman-Approved-At: Thu, 16 Nov 2006 12:34:54 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 12:17:49 -0000 Quoting Daniel Hartmeier : > This patch against OpenBSD -current adds a simple form of PKI to > OpenSSH. We'll be using it at work. See README.certkey (the first chunk > of the patch) for details. > > Everything below is BSD licensed, sponsored by Allamanda Networks AG. I like this very much. We have to administrate quite a number of OpenBSD machines (>100) so this comes in very handy. I have seen becks@ concerns and seeing that Andre already allocated ressources to extend it makes me confident that this actually is in good hands. That said, I am in favour of this new functionality. After all it's optional, nobody is forced to use it. It would be nice if this could get committet (after some more testing and with a huge number of oks ;) - Marc Balmer ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 13:03:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9877816A407 for ; Thu, 16 Nov 2006 13:03:01 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C03F143D4C for ; Thu, 16 Nov 2006 13:03:00 +0000 (GMT) (envelope-from gb@isis.u-strasbg.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 77D59FC21 for ; Thu, 16 Nov 2006 14:02:58 +0100 (CET) Received: from chimie.u-strasbg.fr ([127.0.0.1]) by localhost (chimie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07285-01 for ; Thu, 16 Nov 2006 14:02:58 +0100 (CET) Received: from 6nq.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 3D33F6DD28 for ; Thu, 16 Nov 2006 14:02:58 +0100 (CET) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 1498817D10; Thu, 16 Nov 2006 14:00:52 +0100 (CET) Date: Thu, 16 Nov 2006 14:00:51 +0100 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20061116130051.GJ1267@isis.u-strasbg.fr> References: <20061116015908.GB63195@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20061116015908.GB63195@garage.freebsd.pl> x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at chimie.u-strasbg.fr Subject: Re: ZFS patches 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, 16 Nov 2006 13:03:01 -0000 Pawel Jakub Dawidek (pjd@freebsd.org) on 16/11/2006 at 02:59 wrote: > have rev. 1.284 of src/sys/kern/kern_synch.c). > > # cd /usr/src [...dd...] > # patch < zfs_20061117.patch > # make buildworld ===> cddl/lib/libnvpair (all) cc -O2 -fno-strict-aliasing -pipe -I/usr/src/cddl/lib/libnvpair/../../../sys/compat/opensolaris -I/usr/src/cddl/lib/libnvpair/../../../include -I/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/uts/common -I/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/uts/intel -D_SOLARIS_C_SOURCE -D_SOLARIS_C_SOURCE -D_SOLARIS_C_SOURCE -D_SOLARIS_C_SOURCE -c /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:309: error: redefinition of 'indent' /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:43: error: previous definition of 'indent' was here /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:320: error: redefinition of 'nvlist_print_with_indent' /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:54: error: previous definition of 'nvlist_print_with_indent' was here /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:530: error: redefinition of 'nvlist_print' /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:264: error: previous definition of 'nvlist_print' was here *** Error code 1 On -CURRENT synced this morning (10:00 UTC). -- bug From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 13:18:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0DAC16A407 for ; Thu, 16 Nov 2006 13:18:46 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 112FF43D46 for ; Thu, 16 Nov 2006 13:18:44 +0000 (GMT) (envelope-from gb@isis.u-strasbg.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 15669FC21 for ; Thu, 16 Nov 2006 14:18:44 +0100 (CET) Received: from chimie.u-strasbg.fr ([127.0.0.1]) by localhost (chimie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10200-04 for ; Thu, 16 Nov 2006 14:18:44 +0100 (CET) Received: from 6nq.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by chimie.u-strasbg.fr (Postfix) with ESMTP id B8AE26DD28 for ; Thu, 16 Nov 2006 14:18:43 +0100 (CET) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id F2B3B17D10; Thu, 16 Nov 2006 14:16:43 +0100 (CET) Date: Thu, 16 Nov 2006 14:16:43 +0100 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20061116131643.GK1267@isis.u-strasbg.fr> References: <20061116015908.GB63195@garage.freebsd.pl> <20061116130051.GJ1267@isis.u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20061116130051.GJ1267@isis.u-strasbg.fr> x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at chimie.u-strasbg.fr Subject: Re: ZFS patches 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, 16 Nov 2006 13:18:46 -0000 Guy Brand (gb@isis.u-strasbg.fr) on 16/11/2006 at 14:00 wrote: > > # cd /usr/src > [...dd...] > > # patch < zfs_20061117.patch > > # make buildworld > > ===> cddl/lib/libnvpair (all) > cc -O2 -fno-strict-aliasing -pipe > -I/usr/src/cddl/lib/libnvpair/../../../sys/compat/opensolaris > -I/usr/src/cddl/lib/libnvpair/../../../include > -I/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/uts/common > -I/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/uts/intel > -D_SOLARIS_C_SOURCE -D_SOLARIS_C_SOURCE -D_SOLARIS_C_SOURCE > -D_SOLARIS_C_SOURCE -c > /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c > /usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c:309: > error: redefinition of 'indent' Usual "patch applied twice". Sorry. -- bug From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 14:17:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 767CE16A47E for ; Thu, 16 Nov 2006 14:17:35 +0000 (UTC) (envelope-from dl@leo.org) Received: from tortuga.leo.org (tortuga.leo.org [83.220.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFDFB43D6A for ; Thu, 16 Nov 2006 14:17:34 +0000 (GMT) (envelope-from dl@leo.org) Received: by tortuga.leo.org (Postfix, from userid 1000) id 80117E02E3; Thu, 16 Nov 2006 14:56:27 +0100 (CET) Date: Thu, 16 Nov 2006 14:56:27 +0100 From: Daniel Lang To: "Wolfgang S. Rupprecht" Message-ID: <20061116135627.GA26343@tortuga.leo.org> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87odr8i53w.fsf@arbol.wsrcc.com> X-Geek: GCS/CC d-- s: a C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r+++ y+++ User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, tech@openbsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 14:17:35 -0000 Hi Wolfgang, Wolfgang S. Rupprecht wrote on Wed, Nov 15, 2006 at 04:53:55PM -0800: [..] > > +the responsibility of verifying host keys, and users do no longer need to > > +maintain known_hosts files of their own. ^^^^^^^^^^^ [..] > I would hate to have my ssh allow anyone in just because we used the > same CA. I still see the authorized_keys file as having a very > important role even if the first layer defense is to check if the > certificate is signed by a CA I trust. [..] Are you, by any chance, mixing up "known_hosts" and "authorized_keys"? Cheers, Daniel From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 15:22:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 761B116A4A7; Thu, 16 Nov 2006 15:22:04 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0CF243D64; Thu, 16 Nov 2006 15:22:00 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 16 Nov 2006 07:19:17 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id kAGFM0sP069217; Thu, 16 Nov 2006 07:22:00 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id kAGFLxP5069212; Thu, 16 Nov 2006 07:21:59 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200611161521.kAGFLxP5069212@ambrisko.com> In-Reply-To: <20061116015908.GB63195@garage.freebsd.pl> To: freebsd-fs@freebsd.org Date: Thu, 16 Nov 2006 07:21:59 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: ZFS patches 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, 16 Nov 2006 15:22:04 -0000 Pawel Jakub Dawidek writes: | This is a first set of patches, which allows to use ZFS file system from | OpenSolaris on FreeBSD. | | To apply the patch you need to have recent FreeBSD source (be sure you | have rev. 1.284 of src/sys/kern/kern_synch.c). | | To try it out you need i386 machine (this is what I tested) and kernel | without WITNESS compiled in (there are probably some warnings still). | | Currently it can only be compiled as a kernel module. | | To apply the patch you need the following steps: | | # cd /usr/src | # fetch http://people.freebsd.org/~pjd/patches/zfs_20061117.patch.bz2 | # bzip2 -d zfs_20061117.patch.bz2 | # patch < zfs_20061117.patch | # make buildworld | # make kernel | # make installworld | # kldload zfs.ko | (zfs and zpool command should work now) | | Before reboot: | # zfs export | | After reboot: | # kldload zfs.ko | # zfs import I skipped the mkdir and used patch -p0. Everything looked to compile okay but when I kldload zfs is fails since the kernel doesn't have memset: %kldload zfs link_elf: symbol memset undefined kldload: can't load zfs: No such file or directory % Is there another change required? Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 16:45:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D854716A412 for ; Thu, 16 Nov 2006 16:45:23 +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 152F943D5A for ; Thu, 16 Nov 2006 16:45:23 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GkkLq-0000Gv-TR for freebsd-current@freebsd.org; Thu, 16 Nov 2006 17:44:34 +0100 Received: from wsrcc-nat.wsrcc.com ([64.142.50.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 17:44:34 +0100 Received: from wolfgang+gnus200611 by wsrcc-nat.wsrcc.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 17:44:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wolfgang S. Rupprecht" Date: Thu, 16 Nov 2006 08:43:20 -0800 Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 23 Message-ID: <87ac2rjqaf.fsf@arbol.wsrcc.com> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: wsrcc-nat.wsrcc.com X-WSRCC: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:qbGUYo1DViXduXkRetl3eoQTwpo= Sender: news X-Mailman-Approved-At: Thu, 16 Nov 2006 17:10:27 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 16:45:23 -0000 Daniel Lang writes: > Are you, by any chance, mixing up "known_hosts" and "authorized_keys"? Oops. I quoted the wrong section. I had meant to quote the section about the user_certificates. This is what I meant to cite: +A user certificate is an authorization made by the CA that the +holder of a specific private key may login to the server as a +specific user, without the need of an authorized_keys file being +present. The CA gains the power to grant individual users access +to the server, and users do no longer need to maintain +authorized_keys files of their own. I don't see a problem with the host certificates methodology. (In fact I'd love to see the known_hosts files fade away as more hosts transition to using host certificates.) Thanks, -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 17:55:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB29F16A407 for ; Thu, 16 Nov 2006 17:55:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C542143D53 for ; Thu, 16 Nov 2006 17:55:44 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35224 invoked from network); 16 Nov 2006 17:48:00 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 17:48:00 -0000 Message-ID: <455CA61F.4060900@freebsd.org> Date: Thu, 16 Nov 2006 18:55:43 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: "Wolfgang S. Rupprecht" References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> <87ac2rjqaf.fsf@arbol.wsrcc.com> In-Reply-To: <87ac2rjqaf.fsf@arbol.wsrcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, tech@openbsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 17:55:45 -0000 Wolfgang S. Rupprecht wrote: > Daniel Lang writes: > >>Are you, by any chance, mixing up "known_hosts" and "authorized_keys"? > > > Oops. I quoted the wrong section. I had meant to quote the section > about the user_certificates. This is what I meant to cite: > > +A user certificate is an authorization made by the CA that the > +holder of a specific private key may login to the server as a > +specific user, without the need of an authorized_keys file being > +present. The CA gains the power to grant individual users access > +to the server, and users do no longer need to maintain > +authorized_keys files of their own. > > I don't see a problem with the host certificates methodology. (In > fact I'd love to see the known_hosts files fade away as more hosts > transition to using host certificates.) Host certificate verification is separate from user authentication/authorization through certificates. You you can use one without using and enabling the other. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 18:01:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0078116A40F; Thu, 16 Nov 2006 18:01:51 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA56943D58; Thu, 16 Nov 2006 18:01:41 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id kAGI1g3s015014 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Nov 2006 19:01:42 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id kAGI1fqc026042; Thu, 16 Nov 2006 19:01:41 +0100 (MET) Date: Thu, 16 Nov 2006 19:01:41 +0100 From: Daniel Hartmeier To: Andre Oppermann , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org, markus@openbsd.org Message-ID: <20061116180141.GH14649@insomnia.benzedrine.cx> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061115174747.GE26418@bofh.cns.ualberta.ca> User-Agent: Mutt/1.5.10i Cc: Subject: Re: OpenSSH Certkey (PKI) adding CAL (online verification) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 18:01:51 -0000 On Wed, Nov 15, 2006 at 10:47:47AM -0700, Bob Beck wrote: > So, My two cents, make it complete first. Making an archetecture > for ssh that makes it easy to add trust centrally WITHOUT MAKING IT EASY > TO REMOVE IT is irresponsible. Thank you for the rant ;) Here's the result. Adding a simple daemon that the OpenSSH servers can query (over UDP port 22) to check user keys. See the first patch chunk for details. Is this what you had in mind? Daniel --- /dev/null Thu Nov 16 18:55:22 2006 +++ README.cal Thu Nov 16 18:54:41 2006 @@ -0,0 +1,155 @@ +OpenSSH CAL + + +INTRODUCTION + +Certificate Authorization List (CAL) allows OpenSSH servers to verify the +validity of user keys online against one or more CAL servers. + +Especially in larger installations with many users, once-trusted users may +become untrusted, or user keys may become compromised. Removing such user keys +from many machines can become a tedious task that has to be repeated +regularly. + +Online verification has the advantage that the list of valid user keys (and +therefore, by absence, the list of invalid user keys) can be maintained in one +single place (or at least in only a few, if multiple CAL servers are used). + +The downside is that OpenSSH servers need to be able to contact at least one +of the CAL servers for every user login. + + +CONFIGURATION + +The feature is enabled through the following two options in the server +configuration: + + CertkeyAuthentication yes + CALHost "10.1.2.3" + CALHost "10.1.2.4" + +A CAL server maintains a list of all valid host's and user's public keys, +in form of files, one per key, stored under /etc/ssh/cal/users/ and +/etc/ssh/cal/hosts/ with file names equal to the key's fingerprint. + +Revoking a user key is done by simply removing its file on the CAL server. + +Conversely, every new user key must be added to the CAL server. + +Similarly, host keys must be created and can be revoked by file +creation/deletion. The CAL server does not have to be restarted or signaled +after such changes. + + +PROTOCOL + +When a user tries to login to an OpenSSH server using a user public key, the +OpenSSH server sends a query over UDP to the CAL server on port 22. The query +contains the OpenSSH server's host key fingerprint and the user key +fingerprint. It is signed by the OpenSSH server's host key. + +The CAL server finds the file containing the host public key based on its +fingerprint. It reads the host public key and verifies the query's signature. +If either of those two steps fails, the query is ignored. This ensures that +only holders of trusted host keys can gain any information from the CAL server +at all. + +Then the CAL server finds the file containing the user public key based on its +fingerprint. If the file is found, the user key is considered valid, otherwise +it is considered invalid. + +The CAL server sends a reply back to the OpenSSH server, indicating whether +the user key is valid or invalid. The reply contains the user key fingerprint, +the CAL public key, the CAL certificate, and a signature made by the CAL +private key. + +The OpenSSH server does not need a pre-arranged copy of the CAL public key to +verify the signature in the reply. Instead, it relies on the pre-arranged copy +of the CA public key to verify the certificate in the reply. If the +certificate is valid and has identity "OpenSSH CA CAL", the OpenSSH server +trusts the certified CAL public key contained in the reply, and uses it to +verify the signature of the reply. + +The OpenSSH server can be configured to use more than one CAL server, by +specifying additional CALHost configuration options. The OpenSSH server will +try the first CAL server in the list first, then cycle through the list in a +round-robin fashion, until it either gets a valid answer or times out. If no +valid answer can be obtained, the system fails closed, that is the user is not +allowed to login. + + +SECURITY IMPLICATIONS + +The CAL hosts and their /etc/ssh/cal directories must be protected. While a +compromised CAL cannot grant access to OpenSSH servers for users that don't +hold any valid keys (either certified or found in authorized_keys), a +compromise of a CAL host can lead to revoked user keys getting accepted or +valid user keys getting refused by OpenSSH servers. + +Because the OpenSSH servers configured to use CAL servers will fail closed +when they can't reach (any) of the CAL servers, a denial of service attack +against the CAL servers can render Certkey user authentication on the OpenSSH +servers non-functional. + +When Certkey user authentication fails either because no CAL server can be +reached or because one CAL server delivers a valid reply marking the user key +as invalid, the user key can still be used with other authentication methods +(publickey) to gain access (if found in authorized_keys). + + +IMPLEMENTATION + +Queries + +Queries consist of a single UDP packet containing one string of ASCII text. +The string contains values separated by semi-colons. Values must not contain +semi-colons, but may be empty. All queries have the form + + hostfp;userfp;rand1;sig + +'hostfp' is the host key's SSH_FP_MD5 SSH_FP_HEX fingerprint, as printed by +ssh-keygen -l. + +'userfp' is the user key's fingerprint, in the same format. + +'rand1' is a random number, acting as a salt. + +'sig' is the signature (in hex) over the first three values, made using the +host private key. + +Example: + + f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d;f2:c7:5c:a9:48:d8:8c:82:\ + 24:d5:2a:d6:75:48:ab:3d;384576238456;dbd33e932d80b5612...5a0b4759bee451 + +Replies + +Replies have the same form as queries (one string, separated by semi-colons), +but contain other fields: + + decision;userfp;rand1;rand2;calkey,calcert;sig + +'decision' is the CAL server's decision about the user key. "VALID" if the +user key should be accepted, "INVALID" if it should be refused. + +'userfp' is the user key's fingerprint, same as in the query. + +'rand1' is returned verbatim as supplied in the query. + +'rand2' has the same format and purpose as 'rand1', but is chosen by the CAL +server. + +'calkey' is the CAL server's public key, in hex. + +'calcert' is a certificate for the CAL server's public key, signed by the CA +for the special identity "OpenSSH CA CAL", in hex. + +'sig' is the signature (in hex) over the first five values, made using the CAL +server's private key. + +Example: + + VALID;f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d;384576238456;122345932;\ + 5a0b4759bee451...932d80b5612;33e932d80b561...4759bee;e932d80b...759bee4 + +$OpenBSD$ --- /dev/null Thu Nov 16 18:55:45 2006 +++ README.certkey Wed Nov 15 15:13:45 2006 @@ -0,0 +1,176 @@ +OpenSSH Certkey + +INTRODUCTION + +Certkey allows OpenSSH to transmit certificates from server to client for host +authentication and from client to server for user authentication. Certificates +are basically signatures made by a certificate authority (CA) private key. + +A host certificate is a guarantee made by the CA that a host public key is +valid. When a host public key carries a valid certificate, the client can +use the host public key without asking the user to confirm the fingerprint +manually and through out-of-band communication the first time. The CA takes +the responsibility of verifying host keys, and users do no longer need to +maintain known_hosts files of their own. + +A user certificate is an authorization made by the CA that the holder of a +specific private key may login to the server as a specific user, without the +need of an authorized_keys file being present. The CA gains the power to grant +individual users access to the server, and users do no longer need to maintain +authorized_keys files of their own. + +Functionally, the CA assumes responsibility and control over users' known_hosts +and authorized_keys files. + +Certkey does not involve online verfication, the CA is not contacted by either +client or server. Instead, the CA generates certificates which are (once) +distributed to hosts and users. Any subsequent logins take place without the +involvment of the CA, based solely on the certificates provided between client +and server. + +For example, a company sets up a new host where many existing users need to +login. Traditionally, every one of those users will have to verify the new +host's key the first time they login. Also, each user will have to authorize +their public key on the new host. With Certkey enabled in this case (and +assuming the users have already been certified), this procedure is reduced to +the CA generating a certificate for the new host and installing the +certificate on the new host. + + +SECURITY IMPLICATIONS + +The CA, specifically the holder of the CA private key (and its password, if it +is password encrypted), holds broad control over hosts and user accounts set +up in this way. Should the CA private key become compromised, all user +accounts become compromised. + +There is no way to revoke a certificate once it has been published, the +certificate is valid until it reaches the expiry date set by the CA. + + +CONFIGURATION + +The feature is enabled through the following two options in the client and +server configurations: + + CertkeyAuthentication yes + CAKeyFile /etc/ssh/ca.pub + + +USAGE + +(1) Generating a CA key pair + + # ssh-keygen + Generating public/private rsa key pair. + Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/ca + Enter passphrase (empty for no passphrase): + Enter same passphrase again: + Your identification has been saved in /root/.ssh/ca. + Your public key has been saved in /root/.ssh/ca.pub. + The key fingerprint is: + f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d root@host + +(2) Generating a host certificate + + # ssh-keygen -s + Enter file in which the CA key is (/root/.ssh/id_rsa): /root/.ssh/ca + CA key fingerprint f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d + Enter file in which the user/host key is: /etc/ssh/ssh_host_rsa_key.pub + host/user key fingerprint 68:8c:25:e3:b1:17:8a:7f:0c:19:fa:0d:f7:12:6f:8a + CA name : benzedrine.cx + identity : lenovo.benzedrine.cx + options : + valid from : 0 + valid until: 20061231 + Certificate has been saved in /etc/ssh/ssh_host_rsa_key.cert. + + # cp /root/.ssh/ca.pub /etc/ssh/ca.pub + +(3) Generating a user certificate + + # ssh-keygen -s + Enter file in which the CA key is (/root/.ssh/id_rsa): /root/.ssh/ca + CA key fingerprint f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d + Enter file in which the user/host key is: /home/dhartmei/.ssh/id_dsa.pub + host/user key fingerprint 86:c8:52:3e:b1:17:8a:7f:0c:19:fa:0d:f7:12:f6:a8 + CA name : benzedrine.cx + identity : dhartmei + options : + valid from : 20061101 + valid until: 20071231 + Certificate has been saved in /home/dhartmei/.ssh/id_dsa.cert. + + +IMPLEMENTATION + +Host and user certificates are introduced into the transport layer and +authentication protocol by addition of a new method respectively. + +Transport Layer Protocol + +An additional key exchange method "diffie-hellman-group-exchange-cert" has +been added. This method is completely identical to the existing method +"diffie-hellman-group-exchange-sha1", except for one additional string +(the host certificate), placed at the end of the message, after the signature. + +Authentication Protocol + +An additional authentication method "certkey" has been added. This method is +completely identical to the existing method "publickey", except for one +additional string (the user certificate), placed at the end of the message, +after the signature. + +Certificate format + +Both host and user certificates share the same format. They consist of a single +string, containing values separated by semi-colons, in the following order + + fingerprint;caname;identity;options;validfrom;validto;algorithm;signature + +Values must not contain semi-colons or NUL bytes, but may be empty. + +'fingerprint' is the SSH_FP_MD5 SSH_FP_HEX fingerprint of the RSA key signing +the certificate (the CA key), e.g. the output of ssh-keygen -l for +/etc/ssh/ca.pub. + +'caname' is the name of the CA. This can be used to associate certificates with +CAs. The format is not defined, though using domain names is suggested. + +'identity' is the identity being certified by the CA with this certificate. +For user certificates, this is the user name the certifcate grants login to. +For host certificates, the format is not defined, though using the host's +fully-qualified domain name is suggested. + +'options' may contain additional options, in form of key=value pairs separated +by pipes '|', like 'foo=bar|src=10/8,*.networx.ch|dst=192.168/16'. keys and +values must not contain semi-colons, pipes, '=' or NUL bytes. The meaning of +options is not currently defined, though keys 'src' and 'dst' are reserved for +later implementation of restrictions based on client/server addresses. + +'validfrom' and 'validto' are timestamps (UNIX Epoch time) defining the time +frame the certificate is valid in. When, upon certificate verification, the +current time is outside this period, the certificate is not valid. If zero is +used as value for 'validto', the certificate is valid indefinitely after +'validfrom'. + +'algorithm' defines the hash algorithm used for the signature. Currently, the +only legal value is 'ripemd160'. + +'signature' is the signature itself in hex without colons. The data being +signed consists of + + fingerprint;caname;identity;options;validfrom;validto + +where 'fingerprint' is the SSH_FP_MD5 SSH_FP_HEX fingerprint of the user or +host key (not the CA key). + +Example: + + f2:c7:5c:a9:48:d8:8c:82:24:d5:2a:d6:75:48:ab:3d;networx.ch;dhartmei;; + 1136070000;1451602800;ripemd160;dbd33e932d80b5612...5a0b4759bee451 + +Note that the certificate does not contain any newline characters, it's +wrapped onto two lines here to improve readability. + +$OpenBSD$ --- /dev/null Thu Nov 16 18:56:03 2006 +++ sshcald.1 Thu Nov 16 17:38:00 2006 @@ -0,0 +1,70 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2006 Daniel Hartmeier. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd November 15, 2006 +.Dt SSHCALD 1 +.Os +.Sh NAME +.Nm sshcald +.Nd Certificate Authorization List (CAL) daemon +.Sh SYNOPSIS +.Nm sshcald +.Bk -words +.Op Fl D +.Sh DESCRIPTION +.Nm +listens on UDP port 22 and answers queries made by OpenSSH servers during +Certkey user authentication. +.Pp +The user trying to login to the server supplies his public key as well as +a certificate made by the certificate authority (CA). +The server then queries +.Nm +to check whether the user's public key has been revoked or is still valid. +.Pp +The options are as follows: +.Bl -tag -width Ds +.It Fl D +When this option is specified, +.Nm +will not detach and does not become a daemon. +.El +.Sh FILES +.Bl -tag -width "/etc/ssh/cal/users/*" -compact +.It Pa /etc/ssh/cal/cal +CAL private key. +.It Pa /etc/ssh/cal/cal.pub +CAL public key. +.It Pa /etc/ssh/cal/users/ +Location of user public keys. +The file names must equal the key fingerprints, as printed by +.Xr ssh-keygen -l . +.It Pa /etc/ssh/cal/hosts/ +Location of host public keys. +.El +.Sh SEE ALSO +.Xr sshd_config 5 , +.Xr sshd 8 --- /dev/null Thu Nov 16 18:56:06 2006 +++ sshcald.c Thu Nov 16 17:49:26 2006 @@ -0,0 +1,296 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2006 Daniel Hartmeier. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * - Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "key.h" +#include "authfile.h" +#include "rsa.h" + +#define FILE_CAL_KEY "/etc/ssh/cal/cal" +#define PATH_HOST_KEYS "/etc/ssh/cal/hosts" +#define PATH_USER_KEYS "/etc/ssh/cal/users" +#define INTBLOB_LEN 20 + +static Key *calkey = NULL; +static u_char calkeystr[8192] = ""; +static u_char calcertstr[8192] = ""; + +static u_int +hex(const u_char *bin, u_int binlen, u_char *buf, u_int bufsiz) +{ + u_int len = 0, i; + + buf[0] = 0; + for (i = 0; i < binlen && len + 3 < bufsiz; ++i) { + snprintf(buf + len, bufsiz - len, "%2.2x", bin[i]); + len += 2; + } + buf[len] = 0; + return (len); +} + +static u_int +de_hex(const u_char *hex, u_char *buf, u_int siz) +{ + u_int len = 0, i; + u_char c; + + for (i = 0; hex[i] && len <= siz; ++i) { + if (hex[i] >= '0' && hex[i] <= '9') + c = hex[i] - '0'; + else if (hex[i] >= 'a' && hex[i] <= 'f') + c = hex[i] - 'a' + 10; + else + break; + if ((i % 2) == 0) + buf[len] = c << 4; + else + buf[len++] |= c; + } + return (len); +} + +static void +token(const u_char **c, u_char *buf, int len) +{ + int i = 0; + + while (**c && **c != ';' && i + 1 < len) + buf[i++] = *(*c)++; + if (**c == ';') + (*c)++; + buf[i] = 0; +} + +static Key * +get_key(const u_char *path, const u_char *fp) +{ + Key *key = NULL; + u_char fn[MAXPATHLEN], *fpl; + + if (strlen(fp) != 47 || strchr(fp, '/')) { + fprintf(stderr, "get_key: invalid fingerprint '%s'\n", fp); + return (NULL); + } + snprintf(fn, sizeof(fn), "%s/%s", path, fp); + key = key_load_public(fn, NULL); + if (key == NULL) { + fprintf(stderr, "get_key: key_load_public() failed for %s\n", fn); + return (NULL); + } + fpl = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + if (strcmp(fpl, fp)) { + fprintf(stderr, "get_key: fingerprint mismatch in %s\n", fn); + xfree(fpl); + key_free(key); + return (NULL); + } + xfree(fpl); + return (key); +} + +static void +reply(int fd, const struct sockaddr_in *sa, const u_char *answer, + const u_char *fpu, const u_char *ran) +{ + u_char pkt[8192], buf[8192], *sig; + u_int siglen; + ssize_t len; + + snprintf(pkt, sizeof(pkt), "%s;%s;%s;%lu;%s;%s", answer, + fpu, ran, (unsigned long)arc4random(), calkeystr, calcertstr); + siglen = sizeof(sig); + if (key_sign(calkey, &sig, &siglen, pkt, strlen(pkt)) < 0) { + fprintf(stderr, "reply: sign() failed\n"); + return; + } + hex(sig, siglen, buf, sizeof(buf)); + xfree(sig); + snprintf(pkt + strlen(pkt), sizeof(pkt) - strlen(pkt), ";%s", buf); + len = sendto(fd, pkt, strlen(pkt), 0, (const struct sockaddr *)sa, sizeof(*sa)); + if (len < 0) { + fprintf(stderr, "sendto: %s\n", strerror(errno)); + return; + } + if (len != strlen(pkt)) { + fprintf(stderr, "sendto: wrote %d != %d bytes\n", (int)len, strlen(pkt)); + return; + } +} + +static void +message(int fd, const struct sockaddr_in *sa, const u_char *buf) +{ + u_char fph[512], fpu[512], ran[512], sig[1024]; + u_char sigbuf[1024], datbuf[8192]; + u_int siglen; + Key *host, *user; + + printf("%s:%u %s\n", inet_ntoa(sa->sin_addr), (unsigned)ntohs(sa->sin_port), buf); + token(&buf, fph, sizeof(fph)); + token(&buf, fpu, sizeof(fpu)); + token(&buf, ran, sizeof(ran)); + token(&buf, sig, sizeof(sig)); + printf(" fph '%s'\n", fph); + printf(" fpu '%s'\n", fpu); + printf(" ran '%s'\n", ran); + printf(" sig '%s'\n", sig); + + if ((host = get_key(PATH_HOST_KEYS, fph)) == NULL) { + fprintf(stderr, "message: couldn't load host key %s\n", fph); + return; + } + + snprintf(datbuf, sizeof(datbuf), "%s;%s;%s", fph, fpu, ran); + siglen = de_hex(sig, sigbuf, sizeof(sigbuf)); + if (key_verify(host, sigbuf, siglen, datbuf, strlen(datbuf)) < 0) { + fprintf(stderr, "message: key_verify() failed, incorrect signature\n"); + key_free(host); + return; + } + + /* signature correct, accept message */ + if ((user = get_key(PATH_USER_KEYS, fpu)) == NULL) { + printf("message: couldn't load user key %s\n", fpu); + reply(fd, sa, "INVALID", fpu, ran); + } else { + key_free(user); + printf("message: user key %s is valid\n", fpu); + reply(fd, sa, "VALID", fpu, ran); + } + + key_free(host); +} + +static void +usage(void) +{ + extern char *__progname; + + fprintf(stderr, "%s [-D]\n", __progname); + exit(1); +} + +int main(int argc, char *argv[]) +{ + int detach = 1; + int ch; + int fd; + u_char buf[65536]; + struct sockaddr_in sa; + socklen_t salen; + u_char *blob; + u_int len; + int n; + + while ((ch = getopt(argc, argv, "D")) != -1) { + switch (ch) { + case 'D': + detach = 0; + break; + default: + usage(); + } + } + if (optind < argc) + usage(); + + ERR_load_crypto_strings(); + OpenSSL_add_all_digests(); + + calkey = key_load_private(FILE_CAL_KEY, "", NULL); + if (calkey == NULL) { + fprintf(stderr, "couldn't load CAL key from %s\n", FILE_CAL_KEY); + return (1); + } + key_to_blob(calkey, &blob, &len); + hex(blob, len, calkeystr, sizeof(calkeystr)); + xfree(blob); + if (calkey->cert == NULL) { + fprintf(stderr, "CAL key %s has no certificate\n", FILE_CAL_KEY); + return (1); + } + hex(calkey->cert, strlen(calkey->cert), calcertstr, sizeof(calcertstr)); + + fd = socket(PF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + fprintf(stderr, "socket: %s\n", strerror(errno)); + return (1); + } + memset(&sa, 0, sizeof(sa)); + sa.sin_family = AF_INET; + sa.sin_addr.s_addr = inet_addr("0.0.0.0"); + sa.sin_port = htons(22); + if (bind(fd, (struct sockaddr *)&sa, sizeof(sa))) { + fprintf(stderr, "bind: %s\n", strerror(errno)); + close(fd); + return (1); + } + + if (detach && daemon(0, 0)) { + fprintf(stderr, "daemon: %s\n", strerror(errno)); + return (1); + } + + while (1) { + ssize_t len; + + memset(&sa, 0, sizeof(sa)); + salen = sizeof(sa); + len = recvfrom(fd, buf, sizeof(buf) - 1, 0, (struct sockaddr *)&sa, &salen); + if (len <= 0) { + if (len < 0 && errno != EINTR) + fprintf(stderr, "recvfrom: %s\n", strerror(errno)); + continue; + } + if (salen != sizeof(sa)) { + fprintf(stderr, "recvfrom: salen %u != sizeof(sa) %u\n", + (unsigned)salen, (unsigned)sizeof(sa)); + continue; + } + if (buf[len - 1] == '\n') + buf[len - 1] = 0; + else + buf[len] = 0; + message(fd, &sa, buf); + } + + close(fd); + return (0); +} --- /dev/null Thu Nov 16 18:56:18 2006 +++ sshcald/Makefile Thu Nov 16 17:17:54 2006 @@ -0,0 +1,32 @@ +# $OpenBSD$ + +.PATH: ${.CURDIR}/.. + +PROG= sshcald +BINOWN= root + +#BINMODE?=4555 + +BINDIR= /usr/sbin +MAN= +MAN= sshcald.1 +#LINKS= ${BINDIR}/ssh ${BINDIR}/slogin +#MLINKS= ssh.1 slogin.1 + +SRCS= sshcald.c + +.include # for AFS + +.if (${KERBEROS5:L} == "yes") +CFLAGS+= -DKRB5 -I${DESTDIR}/usr/include/kerberosV -DGSSAPI +.endif # KERBEROS5 + +.include + +.if (${KERBEROS5:L} == "yes") +DPADD+= ${LIBGSSAPI} ${LIBKRB5} +LDADD+= -lgssapi -lkrb5 +.endif # KERBEROS5 + +DPADD+= ${LIBCRYPTO} ${LIBZ} ${LIBDES} +LDADD+= -lcrypto -lz -ldes --- /dev/null Thu Nov 16 18:56:26 2006 +++ auth2-certkey.c Thu Nov 16 17:18:51 2006 @@ -0,0 +1,319 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2000 Markus Friedl. All rights reserved. + * Copyright (c) 2006 Daniel Hartmeier. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include "xmalloc.h" +#include "ssh.h" +#include "ssh2.h" +#include "packet.h" +#include "buffer.h" +#include "log.h" +#include "servconf.h" +#include "compat.h" +#include "key.h" +#include "authfile.h" +#include "hostfile.h" +#include "auth.h" +#include "pathnames.h" +#include "uidswap.h" +#include "auth-options.h" +#include "canohost.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif +#include "monitor_wrap.h" +#include "misc.h" + +/* import */ +extern ServerOptions options; +extern u_char *session_id2; +extern u_int session_id2_len; + +static int +userauth_certkey(Authctxt *authctxt) +{ + Buffer b; + Key *key = NULL; + char *pkalg; + u_char *pkblob, *sig, *cert; + u_int alen, blen, slen, clen; + int have_sig, pktype; + int authenticated = 0; + + if (!authctxt->valid) { + debug2("userauth_certkey: disabled because of invalid user"); + return 0; + } + have_sig = packet_get_char(); + if (datafellows & SSH_BUG_PKAUTH) { + debug2("userauth_certkey: SSH_BUG_PKAUTH"); + /* no explicit pkalg given */ + pkblob = packet_get_string(&blen); + buffer_init(&b); + buffer_append(&b, pkblob, blen); + /* so we have to extract the pkalg from the pkblob */ + pkalg = buffer_get_string(&b, &alen); + buffer_free(&b); + } else { + pkalg = packet_get_string(&alen); + pkblob = packet_get_string(&blen); + } + pktype = key_type_from_name(pkalg); + if (pktype == KEY_UNSPEC) { + /* this is perfectly legal */ + logit("userauth_certkey: unsupported public key algorithm: %s", + pkalg); + goto done; + } + key = key_from_blob(pkblob, blen); + if (key == NULL) { + error("userauth_certkey: cannot decode key: %s", pkalg); + goto done; + } + if (key->type != pktype) { + error("userauth_certkey: type mismatch for decoded key " + "(received %d, expected %d)", key->type, pktype); + goto done; + } + if (have_sig) { + sig = packet_get_string(&slen); + cert = packet_get_string(&clen); + if (!cert || clen <= 0) { + error("userauth_certkey: no cert"); + goto done; + } + key->cert = xstrdup(cert); + packet_check_eom(); + buffer_init(&b); + if (datafellows & SSH_OLD_SESSIONID) { + buffer_append(&b, session_id2, session_id2_len); + } else { + buffer_put_string(&b, session_id2, session_id2_len); + } + /* reconstruct packet */ + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->user); + buffer_put_cstring(&b, + datafellows & SSH_BUG_PKSERVICE ? + "ssh-userauth" : + authctxt->service); + if (datafellows & SSH_BUG_PKAUTH) { + buffer_put_char(&b, have_sig); + } else { + buffer_put_cstring(&b, "certkey"); + buffer_put_char(&b, have_sig); + buffer_put_cstring(&b, pkalg); + } + buffer_put_string(&b, pkblob, blen); +#ifdef DEBUG_PK + buffer_dump(&b); +#endif + /* test for correct signature */ + authenticated = 0; + if (PRIVSEP(user_cert_key_allowed(authctxt->pw, key)) && + PRIVSEP(key_verify(key, sig, slen, buffer_ptr(&b), + buffer_len(&b))) == 1) + authenticated = 1; + buffer_free(&b); + xfree(sig); + } else { + debug("test whether pkalg/pkblob are acceptable"); + cert = packet_get_string(&clen); + if (!cert || clen <= 0) { + error("userauth_certkey: no cert"); + goto done; + } + key->cert = xstrdup(cert); + packet_check_eom(); + + if (PRIVSEP(user_cert_key_allowed(authctxt->pw, key))) { + packet_start(SSH2_MSG_USERAUTH_PK_OK); + packet_put_string(pkalg, alen); + packet_put_string(pkblob, blen); + packet_send(); + packet_write_wait(); + authctxt->postponed = 1; + } + } + if (authenticated != 1) + auth_clear_options(); +done: + debug2("userauth_certkey: authenticated %d pkalg %s", authenticated, pkalg); + if (key != NULL) + key_free(key); + xfree(pkalg); + xfree(pkblob); + return authenticated; +} + +static int +user_cert_key_cal_approved(Key *key, Key *ca_key) +{ + const char *caladdr = "127.0.0.1"; + int approved = 0; + Key *host_key; + int fd, i, j, ret; + struct sockaddr_in sa; + socklen_t salen; + u_char pkt[65536] = "TEST"; + u_char fph[128], fpu[128], rand1[128]; + u_char *fp, *sig; + u_int siglen; + ssize_t len; + time_t timeout; + + if ((host_key = get_hostkey_by_type(KEY_RSA)) == NULL) { + debug2("user_cert_key_cal_approved: no host key available"); + return 0; + } + if ((fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX)) == NULL) + return 0; + strlcpy(fph, fp, sizeof(fph)); + xfree(fp); + if ((fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX)) == NULL) + return 0; + strlcpy(fpu, fp, sizeof(fpu)); + xfree(fp); + snprintf(rand1, sizeof(rand1), "%lu", (unsigned long)arc4random()); + snprintf(pkt, sizeof(pkt), "%s;%s;%s", fph, fpu, rand1); + if (key_sign(host_key, &sig, &siglen, pkt, strlen(pkt)) < 0) { + debug2("user_cert_key_cal_approved: key_sign() failed"); + return 0; + } + strlcat(pkt, ";", sizeof(pkt)); + for (i = 0; i < siglen; ++i) + snprintf(pkt + strlen(pkt), sizeof(pkt) - strlen(pkt), "%2.2x", sig[i]); + fd = socket(PF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + debug2("user_cert_key_cal_approved: socket: %s", strerror(errno)); + return 0; + } + + timeout = time(NULL) + 3; + for (i = 0; time(NULL) < timeout; i = (i + 1) % options.num_cal_hosts) { + + debug3("user_cert_key_cal_approved: trying host %d '%s'", + i, options.cal_hosts[i]); + + memset(&sa, 0, sizeof(sa)); + sa.sin_family = AF_INET; + sa.sin_addr.s_addr = inet_addr(options.cal_hosts[i]); + sa.sin_port = htons(22); + len = sendto(fd, pkt, strlen(pkt), 0, (const struct sockaddr *)&sa, sizeof(sa)); + if (len < 0) { + debug2("user_cert_key_cal_approved: sendto: %s", strerror(errno)); + continue; + } + + /* wait at most 1s and read at most 4 messages from this host */ + for (j = 0; j < 4; ++j) { + fd_set fds; + struct timeval tv; + int r; + ssize_t len; + + FD_ZERO(&fds); + FD_SET(fd, &fds); + tv.tv_sec = 0; + tv.tv_usec = 250000; + r = select(fd + 1, &fds, NULL, NULL, &tv); + if (r < 0) { + if (errno == EINTR) + continue; + debug2("user_cert_key_cal_approved: select: %s", + strerror(errno)); + break; + } + if (r == 0 || !FD_ISSET(fd, &fds)) + continue; + salen = sizeof(sa); + len = recvfrom(fd, pkt, sizeof(pkt) - 1, 0, (struct sockaddr *)&sa, &salen); + if (len < 0) { + if (errno == EINTR) + continue; + debug2("user_cert_key_cal_approved: recvfrom: %s\n", + strerror(errno)); + break; + } + if (len == 0 || salen != sizeof(sa)) + continue; + pkt[len] = 0; + if (strcmp(inet_ntoa(sa.sin_addr), options.cal_hosts[i]) || + ntohs(sa.sin_port) != 22) { + debug2("user_cert_key_cal_approved: " + "answer from unexpected source %s:%u\n", + inet_ntoa(sa.sin_addr), (unsigned)ntohs(sa.sin_port)); + continue; + } + if (!(ret = cal_answer_verify(ca_key, pkt, fpu, rand1))) { + debug2("user_cert_key_cal_approved: cal_answer_verify() failed\n"); + continue; + } + /* we have a trusted answer, but it may not be positive */ + if (ret > 0) + approved = 1; + goto done; + } + } +done: + close(fd); + return approved; +} + +/* check whether given key is signed by certificate */ +int +user_cert_key_allowed(struct passwd *pw, Key *key) +{ + int allowed = 0; + Key *ca_key; + + temporarily_use_uid(pw); + ca_key = key_load_public(options.ca_key_file, NULL); + restore_uid(); + allowed = cert_verify(key->cert, ca_key, key, pw->pw_name); + if (options.num_cal_hosts > 0) + allowed = allowed && user_cert_key_cal_approved(key, ca_key); + if (ca_key != NULL) + key_free(ca_key); + return allowed; +} + + +Authmethod method_certkey = { + "certkey", + userauth_certkey, + &options.certkey_authentication +}; Index: Makefile =================================================================== RCS file: /cvs/src/usr.bin/ssh/Makefile,v retrieving revision 1.12 diff -u -r1.12 Makefile --- Makefile 1 Dec 2003 15:47:20 -0000 1.12 +++ Makefile 16 Nov 2006 17:56:40 -0000 @@ -3,7 +3,7 @@ .include SUBDIR= lib ssh sshd ssh-add ssh-keygen ssh-agent scp sftp-server \ - ssh-keysign ssh-keyscan sftp scard + ssh-keysign ssh-keyscan sftp scard sshcald distribution: ${INSTALL} -C -o root -g wheel -m 0644 ${.CURDIR}/ssh_config \ Index: auth.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.h,v retrieving revision 1.58 diff -u -r1.58 auth.h --- auth.h 18 Aug 2006 09:15:20 -0000 1.58 +++ auth.h 16 Nov 2006 17:56:40 -0000 @@ -115,6 +115,7 @@ int auth_rhosts_rsa_key_allowed(struct passwd *, char *, char *, Key *); int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); int user_key_allowed(struct passwd *, Key *); +int user_cert_key_allowed(struct passwd *, Key *); #ifdef KRB5 int auth_krb5(Authctxt *authctxt, krb5_data *auth, char **client, krb5_data *); Index: auth2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth2.c,v retrieving revision 1.113 diff -u -r1.113 auth2.c --- auth2.c 3 Aug 2006 03:34:41 -0000 1.113 +++ auth2.c 16 Nov 2006 17:56:40 -0000 @@ -55,6 +55,7 @@ /* methods */ extern Authmethod method_none; +extern Authmethod method_certkey; extern Authmethod method_pubkey; extern Authmethod method_passwd; extern Authmethod method_kbdint; @@ -65,6 +66,7 @@ Authmethod *authmethods[] = { &method_none, + &method_certkey, &method_pubkey, #ifdef GSSAPI &method_gssapi, Index: authfile.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/authfile.c,v retrieving revision 1.76 diff -u -r1.76 authfile.c --- authfile.c 3 Aug 2006 03:34:41 -0000 1.76 +++ authfile.c 16 Nov 2006 17:56:40 -0000 @@ -302,6 +302,43 @@ return pub; } +static void +key_try_load_cert(Key *key, const char *filename) +{ + char fn[MAXPATHLEN]; + int fd; + ssize_t r; + + if (key->cert) { + xfree(key->cert); + key->cert = NULL; + } + if (strlen(filename) > 4 && strlen(filename) < sizeof(fn) && + !strcmp(filename + strlen(filename) - 4, ".pub")) + strlcpy(fn, filename, strlen(filename) - 3); + else + strlcpy(fn, filename, sizeof(fn)); + strlcat(fn, ".cert", sizeof(fn)); + + fd = open(fn, O_RDONLY); + if (fd >= 0) { + key->cert = xmalloc(8192); + if (key->cert) { + r = read(fd, key->cert, 8192); + if (r > 0) { + if (key->cert[r - 1] == '\n') + key->cert[r - 1] = 0; + else + key->cert[r] = 0; + } else { + xfree(key->cert); + key->cert = NULL; + } + } + close(fd); + } +} + /* load public key from private-key file, works only for SSH v1 */ Key * key_load_public_type(int type, const char *filename, char **commentp) @@ -315,6 +352,8 @@ return NULL; pub = key_load_public_rsa1(fd, filename, commentp); close(fd); + if (pub != NULL) + key_try_load_cert(pub, filename); return pub; } return NULL; @@ -604,6 +643,8 @@ /* closes fd */ prv = key_load_private_rsa1(fd, filename, passphrase, NULL); } + if (prv != NULL) + key_try_load_cert(prv, filename); return prv; } @@ -634,6 +675,7 @@ if (commentp) *commentp=xstrdup(filename); fclose(f); + key_try_load_cert(k, filename); return 1; } } Index: kex.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kex.c,v retrieving revision 1.76 diff -u -r1.76 kex.c --- kex.c 3 Aug 2006 03:34:42 -0000 1.76 +++ kex.c 16 Nov 2006 17:56:41 -0000 @@ -312,6 +312,9 @@ } else if (strcmp(k->name, KEX_DHGEX_SHA256) == 0) { k->kex_type = KEX_DH_GEX_SHA256; k->evp_md = evp_ssh_sha256(); + } else if (strcmp(k->name, KEX_DHGEX_CERT) == 0) { + k->kex_type = KEX_DH_GEX_CERT; + k->evp_md = EVP_sha1(); } else fatal("bad kex alg %s", k->name); } Index: kex.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/kex.h,v retrieving revision 1.44 diff -u -r1.44 kex.h --- kex.h 3 Aug 2006 03:34:42 -0000 1.44 +++ kex.h 16 Nov 2006 17:56:41 -0000 @@ -32,6 +32,7 @@ #define KEX_DH14 "diffie-hellman-group14-sha1" #define KEX_DHGEX_SHA1 "diffie-hellman-group-exchange-sha1" #define KEX_DHGEX_SHA256 "diffie-hellman-group-exchange-sha256" +#define KEX_DHGEX_CERT "diffie-hellman-group-exchange-cert" #define COMP_NONE 0 #define COMP_ZLIB 1 @@ -62,6 +63,7 @@ KEX_DH_GRP14_SHA1, KEX_DH_GEX_SHA1, KEX_DH_GEX_SHA256, + KEX_DH_GEX_CERT, KEX_MAX }; Index: kexgexc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kexgexc.c,v retrieving revision 1.11 diff -u -r1.11 kexgexc.c --- kexgexc.c 6 Nov 2006 21:25:28 -0000 1.11 +++ kexgexc.c 16 Nov 2006 17:56:41 -0000 @@ -124,8 +124,6 @@ fatal("type mismatch for decoded server_host_key_blob"); if (kex->verify_host_key == NULL) fatal("cannot verify server_host_key"); - if (kex->verify_host_key(server_host_key) == -1) - fatal("server_host_key verification failed"); /* DH parameter f, server public DH key */ if ((dh_server_pub = BN_new()) == NULL) @@ -141,7 +139,20 @@ /* signed H */ signature = packet_get_string(&slen); + if (kex->kex_type == KEX_DH_GEX_CERT) { + u_char *cert; + u_int len; + + cert = packet_get_string(&len); + if (cert != NULL) { + server_host_key->cert = xstrdup(cert); + xfree(cert); + } + } packet_check_eom(); + + if (kex->verify_host_key(server_host_key) == -1) + fatal("server_host_key verification failed"); if (!dh_pub_is_valid(dh, dh_server_pub)) packet_disconnect("bad server public DH value"); Index: kexgexs.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/kexgexs.c,v retrieving revision 1.10 diff -u -r1.10 kexgexs.c --- kexgexs.c 6 Nov 2006 21:25:28 -0000 1.10 +++ kexgexs.c 16 Nov 2006 17:56:41 -0000 @@ -183,6 +183,13 @@ packet_put_string(server_host_key_blob, sbloblen); packet_put_bignum2(dh->pub_key); /* f */ packet_put_string(signature, slen); + if (kex->kex_type == KEX_DH_GEX_CERT) { + if (server_host_key->cert != NULL) + packet_put_string(server_host_key->cert, + strlen(server_host_key->cert)); + else + packet_put_string("", 0); + } packet_send(); xfree(signature); Index: key.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.c,v retrieving revision 1.68 diff -u -r1.68 key.c --- key.c 6 Nov 2006 21:25:28 -0000 1.68 +++ key.c 16 Nov 2006 17:56:41 -0000 @@ -57,6 +57,7 @@ k->type = type; k->dsa = NULL; k->rsa = NULL; + k->cert = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -145,6 +146,9 @@ fatal("key_free: bad key type %d", k->type); break; } + if (k->cert != NULL) + xfree(k->cert); + k->cert = NULL; xfree(k); } @@ -833,6 +837,7 @@ pk->flags = k->flags; pk->dsa = NULL; pk->rsa = NULL; + pk->cert = k->cert ? xstrdup(k->cert) : NULL; switch (k->type) { case KEY_RSA1: @@ -862,4 +867,167 @@ } return (pk); +} + +static void +cert_token(const u_char **c, u_char *buf, int len) +{ + int i = 0; + + while (**c && **c != ';' && i + 1 < len) + buf[i++] = *(*c)++; + if (**c == ';') + (*c)++; + buf[i] = 0; +} + +static u_int +de_hex(const u_char *hex, u_char *buf, u_int siz) +{ + u_int len = 0, i; + u_char c; + + for (i = 0; hex[i] && len <= siz; ++i) { + if (hex[i] >= '0' && hex[i] <= '9') + c = hex[i] - '0'; + else if (hex[i] >= 'a' && hex[i] <= 'f') + c = hex[i] - 'a' + 10; + else + break; + if ((i % 2) == 0) + buf[len] = c << 4; + else + buf[len++] |= c; + } + return (len); +} + +/* check whether CAL anwser packet is valid and signature correct */ +int +cal_answer_verify(const Key *ca_key, const u_char *pkt, const u_char *fpu, + const u_char *rand1) +{ + u_char cal_reply[64], cal_fpu[128], cal_rand1[128], cal_rand2[128]; + u_char cal_pubkey_hex[8192], cal_cert_hex[8192], cal_sig_hex[8192]; + u_char cal_pubkey[8192], cal_cert[8192], cal_sig[8192]; + u_char dat[8192]; + u_int cal_pubkey_len, cal_cert_len, cal_sig_len; + Key *cal_key; + + cert_token(&pkt, cal_reply, sizeof(cal_reply)); + cert_token(&pkt, cal_fpu, sizeof(cal_fpu)); + cert_token(&pkt, cal_rand1, sizeof(cal_rand1)); + cert_token(&pkt, cal_rand2, sizeof(cal_rand2)); + cert_token(&pkt, cal_pubkey_hex, sizeof(cal_pubkey_hex)); + cert_token(&pkt, cal_cert_hex, sizeof(cal_cert_hex)); + cert_token(&pkt, cal_sig_hex, sizeof(cal_sig_hex)); + cal_pubkey_len = de_hex(cal_pubkey_hex, cal_pubkey, sizeof(cal_pubkey)); + cal_cert_len = de_hex(cal_cert_hex, cal_cert, sizeof(cal_cert) - 1); + cal_cert[cal_cert_len] = 0; + cal_sig_len = de_hex(cal_sig_hex, cal_sig, sizeof(cal_sig)); + + cal_key = key_from_blob(cal_pubkey, cal_pubkey_len); + if (cal_key == NULL) { + debug2("cal_answer_verify: key_from_blob() failed"); + return 0; + } + + if (!cert_verify(cal_cert, ca_key, cal_key, "OpenSSH CA CAL")) { + debug2("cal_answer_verify: certificate not valid"); + key_free(cal_key); + return 0; + } + + snprintf(dat, sizeof(dat), "%s;%s;%s;%s;%s;%s", cal_reply, cal_fpu, + cal_rand1, cal_rand2, cal_pubkey_hex, cal_cert_hex); + if (key_verify(cal_key, cal_sig, cal_sig_len, dat, strlen(dat)) < 0) { + debug2("cal_answer_verify: signature is not valid"); + key_free(cal_key); + return 0; + } + key_free(cal_key); + + if (strcmp(cal_fpu, fpu)) { + debug2("cal_answer_verify: CAL fpu mismatch"); + return 0; + } + if (strcmp(cal_rand1, rand1)) { + debug2("cal_answer_verify: CAL rand1 mismatch"); + return 0; + } + if (strcmp(cal_reply, "VALID")) + return -1; + return 1; +} + +/* check whether certificate is valid and signature correct */ +int +cert_verify(const u_char *cert, const Key *ca_key, const Key *key, + const u_char *identity) +{ + u_char ca_fp[128], ca_name[128], ca_id[128], ca_opts[512]; + u_char ca_vf[16], ca_vt[16], ca_alg[64], ca_sig[1024]; + u_char sigbuf[1024], datbuf[2048], c, *fp; + unsigned long vf, vt, now = time(NULL); + u_int siglen, i; + + if (cert == NULL || ca_key == NULL || ca_key->type != KEY_RSA || + ca_key->rsa == NULL || key == NULL) { + debug2("cert_verify: invalid arguments"); + return 0; + } + + cert_token(&cert, ca_fp, sizeof(ca_fp)); + cert_token(&cert, ca_name, sizeof(ca_name)); + cert_token(&cert, ca_id, sizeof(ca_id)); + cert_token(&cert, ca_opts, sizeof(ca_opts)); + cert_token(&cert, ca_vf, sizeof(ca_vf)); + vf = strtoul(ca_vf, NULL, 10); + cert_token(&cert, ca_vt, sizeof(ca_vt)); + vt = strtoul(ca_vt, NULL, 10); + cert_token(&cert, ca_alg, sizeof(ca_alg)); + cert_token(&cert, ca_sig, sizeof(ca_sig)); + + if (strcmp(ca_alg, "ripemd160")) { + debug2("cert_verify: unsupported alg '%s'\n", ca_alg); + return 0; + } + + siglen = de_hex(ca_sig, sigbuf, sizeof(sigbuf)); + + fp = key_fingerprint(ca_key, SSH_FP_MD5, SSH_FP_HEX); + if (strcmp(fp, ca_fp)) { + debug2("cert_verify: CA key fingerprint mismatch ('%s' != '%s')", + fp, ca_fp); + xfree(fp); + return 0; + } + xfree(fp); + + fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + snprintf(datbuf, sizeof(datbuf), "%s;%s;%s;%s;%lu;%lu", + fp, ca_name, ca_id, ca_opts, vf, vt); + xfree(fp); + + if (RSA_verify(NID_ripemd160, datbuf, strlen(datbuf), sigbuf, siglen, + ca_key->rsa) != 1) { + debug2("cert_verify: signature not valid ('%s')", ca_sig); + return 0; + } + if (vf && vf > now) { + debug2("cert_verify: certificate is not yet valid (%lu > %lu)", + vf, now); + return 0; + } + if (vt && vt < now) { + debug2("cert_verify: certificate has expired (%lu < %lu)", + vt, now); + return 0; + } + if (identity != NULL && strcmp(identity, ca_id)) { + debug2("cert_verify: identity mismatches ('%s' != '%s')", + identity, ca_id); + return 0; + } + return 1; } Index: key.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.h,v retrieving revision 1.26 diff -u -r1.26 key.h --- key.h 3 Aug 2006 03:34:42 -0000 1.26 +++ key.h 16 Nov 2006 17:56:41 -0000 @@ -53,6 +53,7 @@ int flags; RSA *rsa; DSA *dsa; + u_char *cert; }; Key *key_new(int); @@ -83,5 +84,9 @@ int ssh_dss_verify(const Key *, const u_char *, u_int, const u_char *, u_int); int ssh_rsa_sign(const Key *, u_char **, u_int *, const u_char *, u_int); int ssh_rsa_verify(const Key *, const u_char *, u_int, const u_char *, u_int); + +int cert_verify(const u_char *cert, const Key *, const Key *, const u_char *); +int cal_answer_verify(const Key *, const u_char *, const u_char *, + const u_char *); #endif Index: monitor.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor.c,v retrieving revision 1.89 diff -u -r1.89 monitor.c --- monitor.c 7 Nov 2006 10:31:31 -0000 1.89 +++ monitor.c 16 Nov 2006 17:56:42 -0000 @@ -797,6 +797,17 @@ if (key != NULL && authctxt->valid) { switch (type) { + case MM_CERTKEY: { + u_char *cert; + u_int clen; + + cert = buffer_get_string(m, &clen); + key->cert = xstrdup(cert); + allowed = options.certkey_authentication && + user_cert_key_allowed(authctxt->pw, key); + auth_method = "certkey"; + break; + } case MM_USERKEY: allowed = options.pubkey_authentication && user_key_allowed(authctxt->pw, key); @@ -859,7 +870,7 @@ } static int -monitor_valid_userblob(u_char *data, u_int datalen) +monitor_valid_userblob(u_char *data, u_int datalen, u_char *name) { Buffer b; char *p; @@ -900,7 +911,7 @@ fail++; } else { p = buffer_get_string(&b, NULL); - if (strcmp("publickey", p) != 0) + if (strcmp(name, p) != 0) fail++; xfree(p); if (!buffer_get_char(&b)) @@ -992,8 +1003,11 @@ fatal("%s: bad public key blob", __func__); switch (key_blobtype) { + case MM_CERTKEY: + valid_data = monitor_valid_userblob(data, datalen, "certkey"); + break; case MM_USERKEY: - valid_data = monitor_valid_userblob(data, datalen); + valid_data = monitor_valid_userblob(data, datalen, "publickey"); break; case MM_HOSTKEY: valid_data = monitor_valid_hostbasedblob(data, datalen, @@ -1015,7 +1029,12 @@ xfree(signature); xfree(data); - auth_method = key_blobtype == MM_USERKEY ? "publickey" : "hostbased"; + if (key_blobtype == MM_CERTKEY) + auth_method = "certkey"; + else if (key_blobtype == MM_USERKEY) + auth_method = "publickey"; + else + auth_method = "hostbased"; monitor_reset_key_state(); Index: monitor_wrap.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.c,v retrieving revision 1.54 diff -u -r1.54 monitor_wrap.c --- monitor_wrap.c 12 Aug 2006 20:46:46 -0000 1.54 +++ monitor_wrap.c 16 Nov 2006 17:56:42 -0000 @@ -295,6 +295,12 @@ } int +mm_user_cert_key_allowed(struct passwd *pw, Key *key) +{ + return (mm_key_allowed(MM_CERTKEY, NULL, NULL, key)); +} + +int mm_user_key_allowed(struct passwd *pw, Key *key) { return (mm_key_allowed(MM_USERKEY, NULL, NULL, key)); @@ -351,6 +357,8 @@ buffer_put_cstring(&m, user ? user : ""); buffer_put_cstring(&m, host ? host : ""); buffer_put_string(&m, blob, len); + if (type == MM_CERTKEY && key && key->cert) + buffer_put_string(&m, key->cert, strlen(key->cert)); xfree(blob); mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_KEYALLOWED, &m); Index: monitor_wrap.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.h,v retrieving revision 1.20 diff -u -r1.20 monitor_wrap.h --- monitor_wrap.h 3 Aug 2006 03:34:42 -0000 1.20 +++ monitor_wrap.h 16 Nov 2006 17:56:42 -0000 @@ -31,7 +31,7 @@ extern int use_privsep; #define PRIVSEP(x) (use_privsep ? mm_##x : x) -enum mm_keytype {MM_NOKEY, MM_HOSTKEY, MM_USERKEY, MM_RSAHOSTKEY, MM_RSAUSERKEY}; +enum mm_keytype {MM_NOKEY, MM_HOSTKEY, MM_CERTKEY, MM_USERKEY, MM_RSAHOSTKEY, MM_RSAUSERKEY}; struct monitor; struct mm_master; @@ -46,6 +46,7 @@ int mm_auth_password(struct Authctxt *, char *); int mm_key_allowed(enum mm_keytype, char *, char *, Key *); int mm_user_key_allowed(struct passwd *, Key *); +int mm_user_cert_key_allowed(struct passwd *, Key *); int mm_hostbased_key_allowed(struct passwd *, char *, char *, Key *); int mm_auth_rhosts_rsa_key_allowed(struct passwd *, char *, char *, Key *); int mm_key_verify(Key *, u_char *, u_int, u_char *, u_int); Index: myproposal.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/myproposal.h,v retrieving revision 1.21 diff -u -r1.21 myproposal.h --- myproposal.h 25 Mar 2006 22:22:43 -0000 1.21 +++ myproposal.h 16 Nov 2006 17:56:42 -0000 @@ -24,6 +24,7 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #define KEX_DEFAULT_KEX \ + "diffie-hellman-group-exchange-cert," \ "diffie-hellman-group-exchange-sha256," \ "diffie-hellman-group-exchange-sha1," \ "diffie-hellman-group14-sha1," \ Index: pathnames.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/pathnames.h,v retrieving revision 1.16 diff -u -r1.16 pathnames.h --- pathnames.h 25 Mar 2006 22:22:43 -0000 1.16 +++ pathnames.h 16 Nov 2006 17:56:42 -0000 @@ -36,6 +36,7 @@ #define _PATH_DH_MODULI ETCDIR "/moduli" /* Backwards compatibility */ #define _PATH_DH_PRIMES ETCDIR "/primes" +#define _PATH_CA_KEY_FILE SSHDIR "/ca.pub" #define _PATH_SSH_PROGRAM "/usr/bin/ssh" Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.159 diff -u -r1.159 readconf.c --- readconf.c 3 Aug 2006 03:34:42 -0000 1.159 +++ readconf.c 16 Nov 2006 17:56:43 -0000 @@ -117,7 +117,8 @@ oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression, oCompressionLevel, oTCPKeepAlive, oNumberOfPasswordPrompts, oUsePrivilegedPort, oLogLevel, oCiphers, oProtocol, oMacs, - oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, + oGlobalKnownHostsFile2, oUserKnownHostsFile2, oCertkeyAuthentication, + oCAKeyFile, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, @@ -148,6 +149,8 @@ { "kbdinteractiveauthentication", oKbdInteractiveAuthentication }, { "kbdinteractivedevices", oKbdInteractiveDevices }, { "rsaauthentication", oRSAAuthentication }, + { "certkeyauthentication", oCertkeyAuthentication }, + { "cakeyfile", oCAKeyFile }, { "pubkeyauthentication", oPubkeyAuthentication }, { "dsaauthentication", oPubkeyAuthentication }, /* alias */ { "rhostsrsaauthentication", oRhostsRSAAuthentication }, @@ -412,6 +415,10 @@ charptr = &options->kbd_interactive_devices; goto parse_string; + case oCertkeyAuthentication: + intptr = &options->certkey_authentication; + goto parse_flag; + case oPubkeyAuthentication: intptr = &options->pubkey_authentication; goto parse_flag; @@ -560,6 +567,10 @@ *charptr = xstrdup(arg); break; + case oCAKeyFile: + charptr = &options->ca_key_file; + goto parse_string; + case oGlobalKnownHostsFile: charptr = &options->system_hostfile; goto parse_string; @@ -1002,6 +1013,8 @@ options->gateway_ports = -1; options->use_privileged_port = -1; options->rsa_authentication = -1; + options->certkey_authentication = -1; + options->ca_key_file = NULL; options->pubkey_authentication = -1; options->challenge_response_authentication = -1; options->gss_authentication = -1; @@ -1088,6 +1101,10 @@ options->use_privileged_port = 0; if (options->rsa_authentication == -1) options->rsa_authentication = 1; + if (options->certkey_authentication == -1) + options->certkey_authentication = 0; + if (options->ca_key_file == NULL) + options->ca_key_file = _PATH_CA_KEY_FILE; if (options->pubkey_authentication == -1) options->pubkey_authentication = 1; if (options->challenge_response_authentication == -1) Index: readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.71 diff -u -r1.71 readconf.h --- readconf.h 3 Aug 2006 03:34:42 -0000 1.71 +++ readconf.h 16 Nov 2006 17:56:43 -0000 @@ -39,6 +39,8 @@ int rhosts_rsa_authentication; /* Try rhosts with RSA * authentication. */ int rsa_authentication; /* Try RSA authentication. */ + int certkey_authentication; /* Try ssh2 certkey authentication. */ + char *ca_key_file; /* File containing CA key. */ int pubkey_authentication; /* Try ssh2 pubkey authentication. */ int hostbased_authentication; /* ssh2's rhosts_rsa */ int challenge_response_authentication; Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.165 diff -u -r1.165 servconf.c --- servconf.c 14 Aug 2006 12:40:25 -0000 1.165 +++ servconf.c 16 Nov 2006 17:56:43 -0000 @@ -56,6 +56,8 @@ options->listen_addrs = NULL; options->address_family = -1; options->num_host_key_files = 0; + options->num_cal_hosts = 0; + options->ca_key_file = NULL; options->pid_file = NULL; options->server_key_bits = -1; options->login_grace_time = -1; @@ -77,6 +79,7 @@ options->hostbased_authentication = -1; options->hostbased_uses_name_from_packet_only = -1; options->rsa_authentication = -1; + options->certkey_authentication = -1; options->pubkey_authentication = -1; options->kerberos_authentication = -1; options->kerberos_or_local_passwd = -1; @@ -134,6 +137,8 @@ _PATH_HOST_DSA_KEY_FILE; } } + if (options->ca_key_file == NULL) + options->ca_key_file = _PATH_CA_KEY_FILE; if (options->num_ports == 0) options->ports[options->num_ports++] = SSH_DEFAULT_PORT; if (options->listen_addrs == NULL) @@ -180,6 +185,8 @@ options->hostbased_uses_name_from_packet_only = 0; if (options->rsa_authentication == -1) options->rsa_authentication = 1; + if (options->certkey_authentication == -1) + options->certkey_authentication = 0; if (options->pubkey_authentication == -1) options->pubkey_authentication = 1; if (options->kerberos_authentication == -1) @@ -260,8 +267,9 @@ sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, - sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, - sMaxStartups, sMaxAuthTries, + sCAKeyFile, sCALHost, + sGatewayPorts, sCertkeyAuthentication, sPubkeyAuthentication, sXAuthLocation, + sSubsystem, sMaxStartups, sMaxAuthTries, sBanner, sUseDNS, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, @@ -282,6 +290,8 @@ u_int flags; } keywords[] = { { "port", sPort, SSHCFG_GLOBAL }, + { "cakeyfile", sCAKeyFile, SSHCFG_GLOBAL }, + { "calhost", sCALHost, SSHCFG_GLOBAL }, { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ { "pidfile", sPidFile, SSHCFG_GLOBAL }, @@ -296,6 +306,7 @@ { "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_GLOBAL }, { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, SSHCFG_GLOBAL }, { "rsaauthentication", sRSAAuthentication, SSHCFG_GLOBAL }, + { "certkeyauthentication", sCertkeyAuthentication, SSHCFG_GLOBAL }, { "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, { "dsaauthentication", sPubkeyAuthentication, SSHCFG_GLOBAL }, /* alias */ #ifdef KRB5 @@ -738,6 +749,28 @@ } break; + case sCAKeyFile: + charptr = &options->ca_key_file; + goto parse_filename; + + case sCALHost: + intptr = &options->num_cal_hosts; + if (*intptr >= MAX_CAL_HOSTS) + fatal("%s line %d: too many CAL hosts specified (max %d).", + filename, linenum, MAX_CAL_HOSTS); + charptr = &options->cal_hosts[*intptr]; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing value.", + filename, linenum); + if (*activep && *charptr == NULL) { + *charptr = xstrdup(arg); + /* increase optional counter */ + if (intptr != NULL) + *intptr = *intptr + 1; + } + break; + case sPidFile: charptr = &options->pid_file; goto parse_filename; @@ -803,6 +836,10 @@ case sRSAAuthentication: intptr = &options->rsa_authentication; + goto parse_flag; + + case sCertkeyAuthentication: + intptr = &options->certkey_authentication; goto parse_flag; case sPubkeyAuthentication: Index: servconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.h,v retrieving revision 1.79 diff -u -r1.79 servconf.h --- servconf.h 14 Aug 2006 12:40:25 -0000 1.79 +++ servconf.h 16 Nov 2006 17:56:44 -0000 @@ -26,6 +26,7 @@ #define MAX_HOSTKEYS 256 /* Max # hostkeys. */ #define MAX_ACCEPT_ENV 256 /* Max # of env vars. */ #define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */ +#define MAX_CAL_HOSTS 16 /* Max # of CAL hosts. */ /* permit_root_login */ #define PERMIT_NOT_SET -1 @@ -43,6 +44,9 @@ char *listen_addr; /* Address on which the server listens. */ struct addrinfo *listen_addrs; /* Addresses on which the server listens. */ int address_family; /* Address family used by the server. */ + char *ca_key_file; /* File containing CA key. */ + int num_cal_hosts; /* Number of CAL host IP addresses */ + char *cal_hosts[MAX_CAL_HOSTS]; /* CAL host IP addresses */ char *host_key_files[MAX_HOSTKEYS]; /* Files containing host keys. */ int num_host_key_files; /* Number of files for host keys. */ char *pid_file; /* Where to put our pid */ @@ -75,6 +79,7 @@ int hostbased_uses_name_from_packet_only; /* experimental */ int rsa_authentication; /* If true, permit RSA authentication. */ int pubkey_authentication; /* If true, permit ssh2 pubkey authentication. */ + int certkey_authentication; /* If true, permit ssh2 certkey authentication. */ int kerberos_authentication; /* If true, permit Kerberos * authentication. */ int kerberos_or_local_passwd; /* If true, permit kerberos Index: ssh-keygen.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v retrieving revision 1.156 diff -u -r1.156 ssh-keygen.c --- ssh-keygen.c 14 Nov 2006 19:41:04 -0000 1.156 +++ ssh-keygen.c 16 Nov 2006 17:56:44 -0000 @@ -94,6 +94,8 @@ int print_public = 0; int print_generic = 0; +int sign_host_key = 0; + char *key_type_name = NULL; /* argv0 */ @@ -494,6 +496,142 @@ #endif /* SMARTCARD */ static void +ask_string(const char *question, char *buf, int len) +{ + printf("%s", question); + if (fgets(buf, len, stdin) == NULL) + exit(1); + buf[len - 1] = 0; + len = strlen(buf); + if (len > 0 && buf[len - 1] == '\n') + buf[len - 1] = 0; +} + +static unsigned long +ask_date(const char *question) +{ + char buf[64]; + int len; + unsigned year, mon = 1, mday = 1, hour = 0, min = 0, sec = 0; + struct tm tm; + + printf("%s", question); + if (fgets(buf, sizeof(buf), stdin) == NULL) + exit(1); + buf[sizeof(buf) - 1] = 0; + len = strlen(buf); + if (len > 0 && buf[len - 1] == '\n') + buf[len - 1] = 0; + if (sscanf(buf, "%4u%2u%2u%2u%2u%2u", + &year, &mon, &mday, &hour, &min, &sec) < 1) { + error("invalid date"); + exit(1); + } + if (!year) + return 0; + memset(&tm, 0, sizeof(tm)); + tm.tm_year = year - 1900; + tm.tm_mon = mon - 1; + tm.tm_mday = mday; + tm.tm_hour = hour; + tm.tm_min = min; + tm.tm_sec = sec; + return timegm(&tm); +} + +static void +do_sign_host_key(struct passwd *pw) +{ + struct stat st; + u_char ca_name[128], ca_id[128], ca_opts[512]; + u_char dat[8192], sig[8192], key_fn[1024], cert_fn[1024]; + unsigned long valid_from, valid_to; + u_int slen; + Key *ca_key, *host_key; + char *ca_fp, *host_fp; + FILE *f; + int i; + + if (!have_identity) + ask_filename(pw, "Enter file in which the CA key is"); + if (stat(identity_file, &st) < 0) { + perror(identity_file); + exit(1); + } + ca_key = load_identity(identity_file); + if (ca_key == NULL) { + error("load failed"); + exit(1); + } + if (ca_key->type != KEY_RSA || ca_key->rsa == NULL) { + error("key invalid"); + exit(1); + } + ca_fp = key_fingerprint(ca_key, SSH_FP_MD5, SSH_FP_HEX); + printf("CA key fingerprint %s\n", ca_fp); + + ask_string("Enter file in which the user/host key is: ", key_fn, sizeof(key_fn)); + if (stat(key_fn, &st) < 0) { + perror(key_fn); + exit(1); + } + host_key = key_load_public(key_fn, NULL); + if (host_key == NULL) { + error("load failed"); + exit(1); + } + strlcpy(cert_fn, key_fn, sizeof(cert_fn)); + if (strlen(cert_fn) > 4 && !strcmp(cert_fn + strlen(cert_fn) - 4, ".pub")) + cert_fn[strlen(cert_fn) - 4] = 0; + strlcat(cert_fn, ".cert", sizeof(cert_fn)); + host_fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + printf("host/user key fingerprint %s\n", host_fp); + + ask_string("CA name : ", ca_name, sizeof(ca_name)); + if (!ca_name[0] || strchr(ca_name, ';')) { + error("invalid CA name"); + exit(1); + } + ask_string("identity : ", ca_id, sizeof(ca_id)); + if (!ca_id[0] || strchr(ca_id, ';')) { + error("invalid identity"); + exit(1); + } + ask_string("options : ", ca_opts, sizeof(ca_opts)); + if (strchr(ca_opts, ';')) { + error("invalid options"); + exit(1); + } + valid_from = ask_date("valid from : "); + valid_to = ask_date("valid until: "); + + snprintf(dat, sizeof(dat), "%s;%s;%s;%s;%lu;%lu", + host_fp, ca_name, ca_id, ca_opts, valid_from, valid_to); + if (RSA_sign(NID_ripemd160, dat, strlen(dat), sig, &slen, ca_key->rsa) != 1 || !slen) { + fprintf(stderr, "RSA_sign() failed\n"); + exit(1); + } + if (RSA_verify(NID_ripemd160, dat, strlen(dat), sig, slen, ca_key->rsa) != 1) { + fprintf(stderr, "RSA_verify() failed\n"); + exit(1); + } + + snprintf(dat, sizeof(dat), "%s;%s;%s;%s;%lu;%lu;ripemd160;", + ca_fp, ca_name, ca_id, ca_opts, valid_from, valid_to); + for (i = 0; i < slen; ++i) + snprintf(dat + strlen(dat), sizeof(dat) - strlen(dat), "%.2x", sig[i]); + f = fopen(cert_fn, "w"); + if (f == NULL) { + fprintf(stderr, "fopen: %s: %s\n", cert_fn, strerror(errno)); + exit(1); + } + fprintf(f, "%s", dat); + fclose(f); + printf("Certificate has been saved in %s.\n", cert_fn); + exit(0); +} + +static void do_fingerprint(struct passwd *pw) { FILE *f; @@ -1026,6 +1164,7 @@ fprintf(stderr, " -R hostname Remove host from known_hosts file.\n"); fprintf(stderr, " -r hostname Print DNS resource record.\n"); fprintf(stderr, " -S start Start point (hex) for generating DH-GEX moduli.\n"); + fprintf(stderr, " -s Generate certificate for user/host key using CA key.\n"); fprintf(stderr, " -T file Screen candidates for DH-GEX moduli.\n"); fprintf(stderr, " -t type Specify type of key to create.\n"); #ifdef SMARTCARD @@ -1079,7 +1218,7 @@ } while ((opt = getopt(argc, argv, - "degiqpclBHvxXyF:b:f:t:U:D:P:N:C:r:g:R:T:G:M:S:a:W:")) != -1) { + "degiqpsclBHvxXyF:b:f:t:U:D:P:N:C:r:g:R:T:G:M:S:a:W:")) != -1) { switch (opt) { case 'b': bits = (u_int32_t)strtonum(optarg, 768, 32768, &errstr); @@ -1156,6 +1295,9 @@ case 'U': reader_id = optarg; break; + case 's': + sign_host_key = 1; + break; case 'v': if (log_level == SYSLOG_LEVEL_INFO) log_level = SYSLOG_LEVEL_DEBUG1; @@ -1221,6 +1363,8 @@ printf("Can only have one of -p and -c.\n"); usage(); } + if (sign_host_key) + do_sign_host_key(pw); if (delete_host || hash_hosts || find_host) do_known_hosts(pw, rr_hostname); if (print_fingerprint || print_bubblebabble) Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.97 diff -u -r1.97 ssh_config.5 --- ssh_config.5 27 Jul 2006 08:00:50 -0000 1.97 +++ ssh_config.5 16 Nov 2006 17:56:45 -0000 @@ -145,6 +145,15 @@ .Cm UsePrivilegedPort is set to .Dq yes . +.It Cm CAKeyFile +Specifies a file containing a public CA key. +The default is +.Pa /etc/ssh/ca.pub . +.It Cm CertkeyAuthentication +Specifies whether certified key authentication is allowed. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. .It Cm ChallengeResponseAuthentication Specifies whether to use challenge-response authentication. The argument to this keyword must be Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.200 diff -u -r1.200 sshconnect.c --- sshconnect.c 10 Oct 2006 10:12:45 -0000 1.200 +++ sshconnect.c 16 Nov 2006 17:56:45 -0000 @@ -21,6 +21,7 @@ #include +#include #include #include #include @@ -48,6 +49,7 @@ #include "misc.h" #include "dns.h" #include "version.h" +#include "authfile.h" char *client_version_string = NULL; char *server_version_string = NULL; @@ -884,6 +886,19 @@ { struct stat st; int flags = 0; + + if (options.certkey_authentication && host_key->cert != NULL) { + Key *ca_key; + int verified; + + ca_key = key_load_public(options.ca_key_file, NULL); + if (ca_key != NULL) { + verified = cert_verify(host_key->cert, ca_key, host_key, NULL); + key_free(ca_key); + if (verified) + return 0; + } + } if (options.verify_host_key_dns && verify_host_key_dns(host, hostaddr, host_key, &flags) == 0) { Index: sshconnect2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect2.c,v retrieving revision 1.162 diff -u -r1.162 sshconnect2.c --- sshconnect2.c 30 Aug 2006 00:06:51 -0000 1.162 +++ sshconnect2.c 16 Nov 2006 17:56:46 -0000 @@ -133,6 +133,7 @@ kex->kex[KEX_DH_GRP14_SHA1] = kexdh_client; kex->kex[KEX_DH_GEX_SHA1] = kexgex_client; kex->kex[KEX_DH_GEX_SHA256] = kexgex_client; + kex->kex[KEX_DH_GEX_CERT] = kexgex_client; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; kex->verify_host_key=&verify_host_key_callback; @@ -168,6 +169,7 @@ Key *key; /* public/private key */ char *filename; /* comment for agent-only keys */ int tried; + int triedcert; int isprivate; /* key points to the private key */ }; TAILQ_HEAD(idlist, identity); @@ -206,6 +208,7 @@ void input_userauth_passwd_changereq(int, u_int32_t, void *); int userauth_none(Authctxt *); +int userauth_certkey(Authctxt *); int userauth_pubkey(Authctxt *); int userauth_passwd(Authctxt *); int userauth_kbdint(Authctxt *); @@ -224,6 +227,7 @@ void userauth(Authctxt *, char *); static int sign_and_send_pubkey(Authctxt *, Identity *); +static int sign_and_send_certkey(Authctxt *, Identity *); static void pubkey_prepare(Authctxt *); static void pubkey_cleanup(Authctxt *); static Key *load_identity_file(char *); @@ -243,6 +247,10 @@ userauth_hostbased, &options.hostbased_authentication, NULL}, + {"certkey", + userauth_certkey, + &options.certkey_authentication, + NULL}, {"publickey", userauth_pubkey, &options.pubkey_authentication, @@ -472,7 +480,11 @@ */ TAILQ_FOREACH_REVERSE(id, &authctxt->keys, idlist, next) { if (key_equal(key, id->key)) { - sent = sign_and_send_pubkey(authctxt, id); + if (!strcmp(authctxt->method->name, "certkey")) { + if (id->key->cert != NULL) + sent = sign_and_send_certkey(authctxt, id); + } else + sent = sign_and_send_pubkey(authctxt, id); break; } } @@ -851,6 +863,93 @@ } static int +sign_and_send_certkey(Authctxt *authctxt, Identity *id) +{ + Buffer b; + u_char *blob, *signature; + u_int bloblen, slen; + u_int skip = 0; + int ret = -1; + int have_sig = 1; + + debug3("sign_and_send_certkey"); + + if (key_to_blob(id->key, &blob, &bloblen) == 0) { + /* we cannot handle this key */ + debug3("sign_and_send_certkey: cannot handle key"); + return 0; + } + /* data to be signed */ + buffer_init(&b); + if (datafellows & SSH_OLD_SESSIONID) { + buffer_append(&b, session_id2, session_id2_len); + skip = session_id2_len; + } else { + buffer_put_string(&b, session_id2, session_id2_len); + skip = buffer_len(&b); + } + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->server_user); + buffer_put_cstring(&b, + datafellows & SSH_BUG_PKSERVICE ? + "ssh-userauth" : + authctxt->service); + if (datafellows & SSH_BUG_PKAUTH) { + buffer_put_char(&b, have_sig); + } else { + buffer_put_cstring(&b, authctxt->method->name); + buffer_put_char(&b, have_sig); + buffer_put_cstring(&b, key_ssh_name(id->key)); + } + buffer_put_string(&b, blob, bloblen); + + /* generate signature */ + ret = identity_sign(id, &signature, &slen, + buffer_ptr(&b), buffer_len(&b)); + if (ret == -1) { + xfree(blob); + buffer_free(&b); + return 0; + } +#ifdef DEBUG_PK + buffer_dump(&b); +#endif + if (datafellows & SSH_BUG_PKSERVICE) { + buffer_clear(&b); + buffer_append(&b, session_id2, session_id2_len); + skip = session_id2_len; + buffer_put_char(&b, SSH2_MSG_USERAUTH_REQUEST); + buffer_put_cstring(&b, authctxt->server_user); + buffer_put_cstring(&b, authctxt->service); + buffer_put_cstring(&b, authctxt->method->name); + buffer_put_char(&b, have_sig); + if (!(datafellows & SSH_BUG_PKAUTH)) + buffer_put_cstring(&b, key_ssh_name(id->key)); + buffer_put_string(&b, blob, bloblen); + } + xfree(blob); + + /* append signature */ + buffer_put_string(&b, signature, slen); + xfree(signature); + + buffer_put_string(&b, id->key->cert, strlen(id->key->cert)); + + /* skip session id and packet type */ + if (buffer_len(&b) < skip + 1) + fatal("userauth_pubkey: internal error"); + buffer_consume(&b, skip + 1); + + /* put remaining data from buffer into packet */ + packet_start(SSH2_MSG_USERAUTH_REQUEST); + packet_put_raw(buffer_ptr(&b), buffer_len(&b)); + buffer_free(&b); + packet_send(); + + return 1; +} + +static int sign_and_send_pubkey(Authctxt *authctxt, Identity *id) { Buffer b; @@ -936,6 +1035,31 @@ } static int +send_certkey_test(Authctxt *authctxt, Identity *id) +{ + u_char *blob; + u_int bloblen, have_sig = 0; + + if (key_to_blob(id->key, &blob, &bloblen) == 0) + return 0; + /* register callback for USERAUTH_PK_OK message */ + dispatch_set(SSH2_MSG_USERAUTH_PK_OK, &input_userauth_pk_ok); + + packet_start(SSH2_MSG_USERAUTH_REQUEST); + packet_put_cstring(authctxt->server_user); + packet_put_cstring(authctxt->service); + packet_put_cstring(authctxt->method->name); + packet_put_char(have_sig); + if (!(datafellows & SSH_BUG_PKAUTH)) + packet_put_cstring(key_ssh_name(id->key)); + packet_put_string(blob, bloblen); + xfree(blob); + packet_put_string(id->key->cert, strlen(id->key->cert)); + packet_send(); + return 1; +} + +static int send_pubkey_test(Authctxt *authctxt, Identity *id) { u_char *blob; @@ -1095,6 +1219,42 @@ xfree(id->filename); xfree(id); } +} + +int +userauth_certkey(Authctxt *authctxt) +{ + Identity *id; + int sent = 0; + + while ((id = TAILQ_FIRST(&authctxt->keys))) { + if (id->triedcert++) + return (0); + /* move key to the end of the queue */ + TAILQ_REMOVE(&authctxt->keys, id, next); + TAILQ_INSERT_TAIL(&authctxt->keys, id, next); + /* + * send a test message if we have the public key. for + * encrypted keys we cannot do this and have to load the + * private key instead + */ + if (id->key && id->key->cert && id->key->type != KEY_RSA1) { + debug("Offering public key: %s", id->filename); + sent = send_certkey_test(authctxt, id); + } else if (id->key == NULL) { + debug("Trying private key: %s", id->filename); + id->key = load_identity_file(id->filename); + if (id->key != NULL && id->key->cert != NULL) { + id->isprivate = 1; + sent = sign_and_send_certkey(authctxt, id); + key_free(id->key); + id->key = NULL; + } + } + if (sent) + return (sent); + } + return (0); } int Index: sshd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd.c,v retrieving revision 1.348 diff -u -r1.348 sshd.c --- sshd.c 6 Nov 2006 21:25:28 -0000 1.348 +++ sshd.c 16 Nov 2006 17:56:46 -0000 @@ -1999,6 +1999,7 @@ kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server; kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; + kex->kex[KEX_DH_GEX_CERT] = kexgex_server; kex->server = 1; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; Index: sshd_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.70 diff -u -r1.70 sshd_config.5 --- sshd_config.5 21 Aug 2006 08:14:01 -0000 1.70 +++ sshd_config.5 16 Nov 2006 17:56:47 -0000 @@ -167,6 +167,19 @@ authentication is allowed. This option is only available for protocol version 2. By default, no banner is displayed. +.It Cm CAKeyFile +Specifies a file containing a public CA key. +The default is +.Pa /etc/ssh/ca.pub . +.It Cm CALHost +Adds a host IP address to the list of CAL hosts. +If the list is empty, which is the default, Certkey does not verify +certificates online against CAL hosts. +.It Cm CertkeyAuthentication +Specifies whether certified key authentication is allowed. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. .It Cm ChallengeResponseAuthentication Specifies whether challenge-response authentication is allowed. All authentication styles from Index: sshd/Makefile =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd/Makefile,v retrieving revision 1.64 diff -u -r1.64 Makefile --- sshd/Makefile 23 Aug 2004 14:26:39 -0000 1.64 +++ sshd/Makefile 16 Nov 2006 17:56:47 -0000 @@ -14,7 +14,7 @@ auth.c auth1.c auth2.c auth-options.c session.c \ auth-chall.c auth2-chall.c groupaccess.c \ auth-skey.c auth-bsdauth.c auth2-hostbased.c auth2-kbdint.c \ - auth2-none.c auth2-passwd.c auth2-pubkey.c \ + auth2-none.c auth2-passwd.c auth2-pubkey.c auth2-certkey.c \ monitor_mm.c monitor.c monitor_wrap.c \ kexdhs.c kexgexs.c From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 18:50:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED96616A403 for ; Thu, 16 Nov 2006 18:50:58 +0000 (UTC) (envelope-from lamont@scriptkiddie.org) Received: from sploit.scriptkiddie.org (sploit.scriptkiddie.org [216.231.47.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E82843D58 for ; Thu, 16 Nov 2006 18:50:56 +0000 (GMT) (envelope-from lamont@scriptkiddie.org) Received: from sploit (sploit [216.231.47.214]) by sploit.scriptkiddie.org (8.12.11/8.12.11) with ESMTP id kAGIos8T017647; Thu, 16 Nov 2006 10:50:54 -0800 (PST) Date: Thu, 16 Nov 2006 10:50:53 -0800 (PST) From: Lamont Granquist To: "Wolfgang S. Rupprecht" In-Reply-To: <87ac2rjqaf.fsf@arbol.wsrcc.com> Message-ID: References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> <87ac2rjqaf.fsf@arbol.wsrcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, tech@openbsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 18:50:59 -0000 On Thu, 16 Nov 2006, Wolfgang S. Rupprecht wrote: > +A user certificate is an authorization made by the CA that the > +holder of a specific private key may login to the server as a > +specific user, without the need of an authorized_keys file being > +present. The CA gains the power to grant individual users access > +to the server, and users do no longer need to maintain > +authorized_keys files of their own. User-maintained authorized_keys files tend to be SOX auditing violations (anyone with access to the account can grant anyone else access with any notification or audit trail). It also lends itself to abuses where software/generic accounts tend to accumulate the public keys of all the developers desktop accounts. The kerberos .k5login file is similarly problematic. I would love to see a CA-based approach which would solve both the authentication and authorization pieces in a way that could be wrapped with proper auditing on the granting of privs, particularly if it was simple enough that it was widely adopted instead of authorized_keys even at very small sites. From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 18:50:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A072316A412 for ; Thu, 16 Nov 2006 18:50:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A746043D5C for ; Thu, 16 Nov 2006 18:50:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35801 invoked from network); 16 Nov 2006 18:43:14 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 18:43:14 -0000 Message-ID: <455CB311.8040301@freebsd.org> Date: Thu, 16 Nov 2006 19:50:57 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 18:50:59 -0000 This is a patch adding automatic TCP send socket buffer sizing. Normally the socket buffers are static (either derived from global defaults or set with setsockopt) and do not adapt to real network conditions. Two things happen: a) your socket buffers are too small and you can't reach the full potential of the network between both hosts; b) your socket buffers are too big and you waste a lot of kernel memory for data just sitting around. With automatic TCP send socket buffers we can start with a small buffer and quickly grow it in parallel with the TCP congestion window to match real network conditions. FreeBSD has a default 32K send socket buffer. This supports a maximal transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer auto scaling and the default values below it supports 20Mbit/s at 100ms and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. New sysctl's are: net.inet.tcp.sndbuf_auto=1 (enabled) net.inet.tcp.sndbuf_inc=8192 (8K, step size) net.inet.tcp.sndbuf_max=262144 (256K, growth limit) The patch is available here: http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff Any testers, especially with busy FTP servers, are very welcome. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 19:15:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 167C516A415; Thu, 16 Nov 2006 19:15:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8581443D7B; Thu, 16 Nov 2006 19:15:33 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA07294; Thu, 16 Nov 2006 21:15:24 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <455CB8CA.8040603@icyb.net.ua> Date: Thu, 16 Nov 2006 21:15:22 +0200 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Doug Ambrisko References: <1163701391.00638085.1163691003@10.7.7.3> In-Reply-To: <1163701391.00638085.1163691003@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS patches 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, 16 Nov 2006 19:15:41 -0000 on 16/11/2006 17:21 Doug Ambrisko said the following: > I skipped the mkdir and used patch -p0. Everything looked to compile > okay but when I kldload zfs is fails since the kernel doesn't > have memset: > %kldload zfs > link_elf: symbol memset undefined > kldload: can't load zfs: No such file or directory > % > Is there another change required? Hmm, I saw errors like this with some other 3rd party kernel module when its sources had constructs like: struct some_struct s = {0}; Changing the above initialization to explicit bzero() call helped in that case, but I think that there should be some compiler flags or something to handle this. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 19:19:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C209516A403; Thu, 16 Nov 2006 19:19:33 +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 BFE4343D67; Thu, 16 Nov 2006 19:19:21 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5DD7D45696; Thu, 16 Nov 2006 20:19:19 +0100 (CET) Received: from localhost (dlv47.neoplus.adsl.tpnet.pl [83.24.51.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2A7D145681; Thu, 16 Nov 2006 20:19:12 +0100 (CET) Date: Thu, 16 Nov 2006 20:18:59 +0100 From: Pawel Jakub Dawidek To: Doug Ambrisko Message-ID: <20061116191858.GF63195@garage.freebsd.pl> References: <20061116015908.GB63195@garage.freebsd.pl> <200611161521.kAGFLxP5069212@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kR3zbvD4cgoYnS/6" Content-Disposition: inline In-Reply-To: <200611161521.kAGFLxP5069212@ambrisko.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL,RCVD_IN_XBL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS patches 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, 16 Nov 2006 19:19:33 -0000 --kR3zbvD4cgoYnS/6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 07:21:59AM -0800, Doug Ambrisko wrote: > I skipped the mkdir and used patch -p0. Everything looked to compile > okay but when I kldload zfs is fails since the kernel doesn't > have memset: > %kldload zfs > link_elf: symbol memset undefined > kldload: can't load zfs: No such file or directory > % > Is there another change required? I applied the patch before publishing on clean source and I don't see such problem... Interesting thing is that there is no memset() use in ZFS kernel source: # grep -r memset sys/ | grep -v zap_memset # Does anyone else seeing this problem? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --kR3zbvD4cgoYnS/6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFXLmiForvXbEpPzQRAmg6AJ9B9Vm6w59XL3zU6+ZU0++8WqyPOQCgxfXK +kygh5MdWPLchCb9BYGEPPg= =i+2z -----END PGP SIGNATURE----- --kR3zbvD4cgoYnS/6-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 19:22:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7679716A40F for ; Thu, 16 Nov 2006 19:22:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64ED143D5E for ; Thu, 16 Nov 2006 19:22:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kAGJMf5w042640; Thu, 16 Nov 2006 14:22:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Nov 2006 13:09:45 -0500 User-Agent: KMail/1.9.1 References: <700e45e50611110701y72351dc3j9ca947b352e62686@mail.gmail.com> In-Reply-To: <700e45e50611110701y72351dc3j9ca947b352e62686@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611161309.45859.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 16 Nov 2006 14:22:42 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2200/Thu Nov 16 09:10:16 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: "V.SriSaiGanesh" Subject: Re: LSI SAS1068 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 19:22:49 -0000 On Saturday 11 November 2006 10:01, V.SriSaiGanesh wrote: > Hi, > I want to support LSISAS 1068 with FreeBSD Current. So i need guidelines to > start. > > Thanks and Regards, man 4 mpt .. it's already supported by the mpt driver. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 19:36:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC3EE16A512; Thu, 16 Nov 2006 19:36:00 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 482C043D83; Thu, 16 Nov 2006 19:35:47 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.8.19] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Gkn1S2kMq-00035f; Thu, 16 Nov 2006 20:35:45 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Thu, 16 Nov 2006 20:35:35 +0100 User-Agent: KMail/1.9.4 References: <20061116015908.GB63195@garage.freebsd.pl> <200611161521.kAGFLxP5069212@ambrisko.com> <20061116191858.GF63195@garage.freebsd.pl> In-Reply-To: <20061116191858.GF63195@garage.freebsd.pl> 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="nextPart3023635.OcQkhFFqoK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611162035.41595.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS patches 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, 16 Nov 2006 19:36:00 -0000 --nextPart3023635.OcQkhFFqoK Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 16 November 2006 20:18, Pawel Jakub Dawidek wrote: > On Thu, Nov 16, 2006 at 07:21:59AM -0800, Doug Ambrisko wrote: > > I skipped the mkdir and used patch -p0. Everything looked to compile > > okay but when I kldload zfs is fails since the kernel doesn't > > have memset: > > %kldload zfs > > link_elf: symbol memset undefined > > kldload: can't load zfs: No such file or directory > > % > > Is there another change required? > > I applied the patch before publishing on clean source and I don't see > such problem... Interesting thing is that there is no memset() use in > ZFS kernel source: > > # grep -r memset sys/ | grep -v zap_memset > # > > Does anyone else seeing this problem? There is an older thread about this problem:=20 http://lists.freebsd.org/pipermail/freebsd-stable/2005-March/thread.html#13= 132 As pointed out by Andriy "struct foo =3D { 0 }" seems to be the culprit. =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 --nextPart3023635.OcQkhFFqoK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFXL2NXyyEoT62BG0RAlQUAJsH0zhOk1ZQJkoNXBhj7sCn49HSDACfZRy6 hoX23Uwain7Z3W9n67tuTNs= =haH7 -----END PGP SIGNATURE----- --nextPart3023635.OcQkhFFqoK-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 19:46:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8F9A16A416 for ; Thu, 16 Nov 2006 19:46:27 +0000 (UTC) (envelope-from lists@loveturtle.net) Received: from loveturtle.net (loveturtle.net [216.91.90.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id B415843D99 for ; Thu, 16 Nov 2006 19:45:32 +0000 (GMT) (envelope-from lists@loveturtle.net) Received: from localhost (localhost [127.0.0.1]) by loveturtle.net (Postfix) with ESMTP id A74551CC46 for ; Thu, 16 Nov 2006 14:45:24 -0500 (EST) X-Virus-Scanned: amavisd-new at loveturtle.net Received: from loveturtle.net ([127.0.0.1]) by localhost (loveturtle.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZJYm1SgShcO for ; Thu, 16 Nov 2006 14:45:22 -0500 (EST) Received: from [216.89.228.114] (macpro.loveturtle.net [216.89.228.114]) by loveturtle.net (Postfix) with ESMTP id 1B8031CC2F for ; Thu, 16 Nov 2006 14:45:22 -0500 (EST) Message-ID: <455CBFD0.2020305@loveturtle.net> Date: Thu, 16 Nov 2006 14:45:20 -0500 From: Dillon User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> In-Reply-To: <455CB8CA.8040603@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS patches 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, 16 Nov 2006 19:46:27 -0000 I applied the patch to todays -current a couple hours ago and got the same thing while trying to load the zfs.ko module. odd.. Andriy Gapon wrote: > on 16/11/2006 17:21 Doug Ambrisko said the following: > >> I skipped the mkdir and used patch -p0. Everything looked to compile >> okay but when I kldload zfs is fails since the kernel doesn't >> have memset: >> %kldload zfs >> link_elf: symbol memset undefined >> kldload: can't load zfs: No such file or directory >> % >> Is there another change required? >> > > Hmm, I saw errors like this with some other 3rd party kernel module when > its sources had constructs like: > > struct some_struct s = {0}; > > Changing the above initialization to explicit bzero() call helped in > that case, but I think that there should be some compiler flags or > something to handle this. > > From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:06:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD90016A49E; Thu, 16 Nov 2006 20:06:24 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id D48C843DE4; Thu, 16 Nov 2006 20:05:09 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 16 Nov 2006 12:02:25 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id kAGK58xr084522; Thu, 16 Nov 2006 12:05:08 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id kAGK58cB084521; Thu, 16 Nov 2006 12:05:08 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200611162005.kAGK58cB084521@ambrisko.com> In-Reply-To: <20061116191858.GF63195@garage.freebsd.pl> To: Pawel Jakub Dawidek Date: Thu, 16 Nov 2006 12:05:08 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS patches 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, 16 Nov 2006 20:06:24 -0000 Pawel Jakub Dawidek writes: | On Thu, Nov 16, 2006 at 07:21:59AM -0800, Doug Ambrisko wrote: | > I skipped the mkdir and used patch -p0. Everything looked to compile | > okay but when I kldload zfs is fails since the kernel doesn't | > have memset: | > %kldload zfs | > link_elf: symbol memset undefined | > kldload: can't load zfs: No such file or directory | > % | > Is there another change required? | | I applied the patch before publishing on clean source and I don't see | such problem... Interesting thing is that there is no memset() use in | ZFS kernel source: | | # grep -r memset sys/ | grep -v zap_memset | # | | Does anyone else seeing this problem? This is on i386: one% grep memset zfs_20061117.patch + (void) memset(p, 0, n); + (void) memset(wp, 0, sizeof (*wp)); + (void) memset(wp, 0, sizeof (*wp)); +zap_memset(void *a, int c, size_t n) + zap_memset(&l->l_phys->l_hdr, 0, sizeof (struct zap_leaf_header)); + zap_memset(l->l_phys->l_hash, CHAIN_END, 2*ZAP_LEAF_HASH_NUMENTRIES(l)); + zap_memset(l->l_phys->l_hash, CHAIN_END, 2*ZAP_LEAF_HASH_NUMENTRIES(l)); one% In contrib/opensolaris/lib/libuutil/common/uu_alloc.c +void * +uu_zalloc(size_t n) +{ + void *p = malloc(n); + + if (p == NULL) { + uu_set_error(UU_ERROR_SYSTEM); + return (NULL); + } + + (void) memset(p, 0, n); + + return (p); +} + %nm dmu_objset.o | grep memset U memset % If I run it compile -E I see static __inline void * memset(void *b, int c, size_t len) { char *bb; if (c == 0) bzero(b, len); else for (bb = (char *)b; len--; ) *bb++ = c; return (b); } and nothing calling it unless it is what Max. is talking about. I don't see other stuff breaking. Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:07:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BF5416A417 for ; Thu, 16 Nov 2006 20:07:51 +0000 (UTC) (envelope-from lists@loveturtle.net) Received: from loveturtle.net (loveturtle.net [216.91.90.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96AFD43D5A for ; Thu, 16 Nov 2006 20:07:19 +0000 (GMT) (envelope-from lists@loveturtle.net) Received: from localhost (localhost [127.0.0.1]) by loveturtle.net (Postfix) with ESMTP id E6E121CC40 for ; Thu, 16 Nov 2006 15:07:18 -0500 (EST) X-Virus-Scanned: amavisd-new at loveturtle.net Received: from loveturtle.net ([127.0.0.1]) by localhost (loveturtle.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcWxJf5rVowr for ; Thu, 16 Nov 2006 15:07:10 -0500 (EST) Received: from [216.89.228.114] (macpro.loveturtle.net [216.89.228.114]) by loveturtle.net (Postfix) with ESMTP id F373B1CC2F for ; Thu, 16 Nov 2006 15:07:09 -0500 (EST) Message-ID: <455CC4EC.6060906@loveturtle.net> Date: Thu, 16 Nov 2006 15:07:08 -0500 From: Dillon User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <455CBFD0.2020305@loveturtle.net> In-Reply-To: <455CBFD0.2020305@loveturtle.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS patches 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, 16 Nov 2006 20:07:51 -0000 Building shit in my vm is too slow to do it again to see if this is what made the difference but i deleted the tree, resynced, patched, and compiled again this time with -O1 instead of -O2 and it's working fine. like i said, i don't know if that is what made the difference or if something was screwed it up in my tree that went away when i deleted, resynced, and repatched but i just thought i'd share that. > > Andriy Gapon wrote: >> on 16/11/2006 17:21 Doug Ambrisko said the following: >> >>> I skipped the mkdir and used patch -p0. Everything looked to compile >>> okay but when I kldload zfs is fails since the kernel doesn't >>> have memset: >>> %kldload zfs >>> link_elf: symbol memset undefined >>> kldload: can't load zfs: No such file or directory >>> % >>> Is there another change required? >>> >> >> Hmm, I saw errors like this with some other 3rd party kernel module when >> its sources had constructs like: >> >> struct some_struct s = {0}; >> >> Changing the above initialization to explicit bzero() call helped in >> that case, but I think that there should be some compiler flags or >> something to handle this. >> >> > > _______________________________________________ > 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 Nov 16 20:08:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4548016A4D2; Thu, 16 Nov 2006 20:08:33 +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 A01F343D5F; Thu, 16 Nov 2006 20:07:46 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id kAGK7DqK054308; Thu, 16 Nov 2006 15:07:13 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 16 Nov 2006 15:06:56 -0500 User-Agent: KMail/1.6.2 References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> In-Reply-To: <455CB8CA.8040603@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200611161506.58128.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2200/Thu Nov 16 09:10:16 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, Andriy Gapon Subject: Re: ZFS patches 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, 16 Nov 2006 20:08:33 -0000 On Thursday 16 November 2006 02:15 pm, Andriy Gapon wrote: > Hmm, I saw errors like this with some other 3rd party kernel module > when its sources had constructs like: > > struct some_struct s = {0}; > > Changing the above initialization to explicit bzero() call helped > in that case, but I think that there should be some compiler flags > or something to handle this. AFAIK, there was no way to handle this GCC bug with compiler flags. '-ffreestanding' should prevent this to happen but it does not. As Max Laier pointed out, it was discussed long time ago. Bruce Evans had good analysis on this issue, too. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:13:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A345516A415 for ; Thu, 16 Nov 2006 20:13:58 +0000 (UTC) (envelope-from nbender@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6ABD43DE6 for ; Thu, 16 Nov 2006 20:13:12 +0000 (GMT) (envelope-from nbender@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so736697nfc for ; Thu, 16 Nov 2006 12:12:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SYUegZr2V09Th0d+uTKMIG1QrFWGE81W3Da3C5QlI/bSVExfSsZt8DPVmDQrScW8OL0kRl7AUH/iODDHckS3/GeYUalwPwRAv+qlALhef1huVqscuhXlBMMnOsreIW0mR25lzpkIMe2breXL+qQxVyuyCeAoKlPMCJcH44T7Syo= Received: by 10.82.126.5 with SMTP id y5mr120857buc.1163707978565; Thu, 16 Nov 2006 12:12:58 -0800 (PST) Received: by 10.82.172.9 with HTTP; Thu, 16 Nov 2006 12:12:58 -0800 (PST) Message-ID: Date: Thu, 16 Nov 2006 15:12:58 -0500 From: "Nick Bender" To: tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org In-Reply-To: <20061115142820.GB14649@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061115142820.GB14649@insomnia.benzedrine.cx> X-Mailman-Approved-At: Thu, 16 Nov 2006 20:30:44 +0000 Cc: Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 20:13:58 -0000 > +SECURITY IMPLICATIONS > + > +The CA, specifically the holder of the CA private key (and its password, if it > +is password encrypted), holds broad control over hosts and user accounts set > +up in this way. Should the CA private key become compromised, all user > +accounts become compromised. > + > +There is no way to revoke a certificate once it has been published, the > +certificate is valid until it reaches the expiry date set by the CA. > + After spending a good part of a night locking down a network when an admin "left" this leaves me feeling cold. I think the addition of CAL gives you at least a prayer of addressing this in a timely manner. In the event that you need to reauthorize from the top: 1. Shutdown your CAL servers. 2. Generate and distribute new CA cert. 3. Generate and distribute new host certs. 4. Startup CAL servers. 5. Generate and distribute new user certs. Did I miss anything? The vulnerability window is now time from compromise to time of shutdown of CAL servers. Note that there is one other time where the same procedure is required but without the time pressure - at CA cert expiry time. I think the procedure should at least be included in the documentation if not supported in some way by software... -N From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:17:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECD5F16A47E for ; Thu, 16 Nov 2006 20:17:15 +0000 (UTC) (envelope-from chefren@pi.net) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 282CA43DCF for ; Thu, 16 Nov 2006 20:16:48 +0000 (GMT) (envelope-from chefren@pi.net) Received: from [192.168.0.58] (lida.ii.nl [195.64.88.137]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id kAGKGE9f070275; Thu, 16 Nov 2006 21:16:15 +0100 (CET) (envelope-from chefren@pi.net) Message-ID: <455CC70D.4010607@pi.net> Date: Thu, 16 Nov 2006 21:16:13 +0100 From: chefren User-Agent: Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.7.12) Gecko/20060301 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hartmeier References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> <20061116180141.GH14649@insomnia.benzedrine.cx> In-Reply-To: <20061116180141.GH14649@insomnia.benzedrine.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Thu, 16 Nov 2006 20:31:17 +0000 Cc: Andre Oppermann , markus@openbsd.org, freebsd-current@freebsd.org, beck@bofh.cns.ualberta.ca, tech@openbsd.org, openssh-unix-dev@mindrot.org Subject: Re: OpenSSH Certkey (PKI) adding CAL (online verification) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 20:17:16 -0000 On 11/16/06 19:01, Daniel Hartmeier wrote: > On Wed, Nov 15, 2006 at 10:47:47AM -0700, Bob Beck wrote: > >>So, My two cents, make it complete first. Making an archetecture >>for ssh that makes it easy to add trust centrally WITHOUT MAKING IT >>EASY TO REMOVE IT is irresponsible. > > Thank you for the rant ;) > > Here's the result. Adding a simple daemon that the OpenSSH servers > can query (over UDP port 22) to check user keys. See the first patch > chunk for details. > > Is this what you had in mind? > > Daniel Gentlemen, I fully agree with the concerns of Bob Beck and I'm happy with the attention of Daniel Hartmeier. And while everything is better than SSL... The security and thus revocation should always be on, by default. So it's a certificate system with off-line use of certificates with inherent bad revocation since you cannot revoke a certificate without being on-line with the authorizing server. Or it should be an on-line (might of course be local) system where the authorizing server (and hopefully a well designed backup...) is at least always asked if access is OK at the beginning of a session (hopefully possible to limit with time or amount of traffic or packets or or... (but don't rebuild SSL!)). Please drop the classic "off-line" PKI scheme and present us an elegant and robust on-line system. +++chefren From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:49:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C8B716A403 for ; Thu, 16 Nov 2006 20:49:24 +0000 (UTC) (envelope-from beck@bofh.cns.ualberta.ca) Received: from bofh.cns.ualberta.ca (bofh.cns.ualberta.ca [129.128.11.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 37C7643D4C for ; Thu, 16 Nov 2006 20:49:24 +0000 (GMT) (envelope-from beck@bofh.cns.ualberta.ca) Received: (qmail 31987 invoked from network); 16 Nov 2006 20:49:22 -0000 Received: from localhost (HELO bofh.cns.ualberta.ca) (127.0.0.1) by bofh.cns.ualberta.ca with SMTP; 16 Nov 2006 20:49:22 -0000 Received: (from beck@localhost) by bofh.cns.ualberta.ca (8.13.3/8.12.10/Submit) id kAGKnLFo018051; Thu, 16 Nov 2006 13:49:21 -0700 (MST) Date: Thu, 16 Nov 2006 13:49:21 -0700 From: Bob Beck To: Nick Bender Message-ID: <20061116204921.GX26418@bofh.cns.ualberta.ca> Mail-Followup-To: Nick Bender , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org References: <20061115142820.GB14649@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Thu, 16 Nov 2006 20:55:14 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 20:49:24 -0000 I would think it would be nice if "CAL" had a way of saying "these are the ones to be revoked" so no shutdown, just propagate the bad one - but I'm talking to daniel offline about it.. * Nick Bender [2006-11-16 13:23]: > >+SECURITY IMPLICATIONS > >+ > >+The CA, specifically the holder of the CA private key (and its password, > >if it > >+is password encrypted), holds broad control over hosts and user accounts > >set > >+up in this way. Should the CA private key become compromised, all user > >+accounts become compromised. > >+ > >+There is no way to revoke a certificate once it has been published, the > >+certificate is valid until it reaches the expiry date set by the CA. > >+ > > After spending a good part of a night locking down a network when an > admin "left" this leaves me feeling cold. > > I think the addition of CAL gives you at least a prayer of addressing > this in a timely manner. In the event that you need to reauthorize > from the top: > > 1. Shutdown your CAL servers. > 2. Generate and distribute new CA cert. > 3. Generate and distribute new host certs. > 4. Startup CAL servers. > 5. Generate and distribute new user certs. > > Did I miss anything? > > The vulnerability window is now time from compromise to time of shutdown > of CAL servers. > > Note that there is one other time where the same procedure is required > but without the time pressure - at CA cert expiry time. > > I think the procedure should at least be included in the documentation > if not supported in some way by software... > > -N > -- #!/usr/bin/perl if ((not 0 && not 1) != (! 0 && ! 1)) { print "Larry and Tom must smoke some really primo stuff...\n"; } From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 20:57:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE4DB16A403 for ; Thu, 16 Nov 2006 20:57:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2195143D53 for ; Thu, 16 Nov 2006 20:57:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 37065 invoked from network); 16 Nov 2006 20:50:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 20:50:14 -0000 Message-ID: <455CD0D8.6070404@freebsd.org> Date: Thu, 16 Nov 2006 21:58:00 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: chefren References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> <20061116180141.GH14649@insomnia.benzedrine.cx> <455CC70D.4010607@pi.net> In-Reply-To: <455CC70D.4010607@pi.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: markus@openbsd.org, freebsd-current@freebsd.org, beck@bofh.cns.ualberta.ca, tech@openbsd.org, Daniel Hartmeier , openssh-unix-dev@mindrot.org Subject: Re: OpenSSH Certkey (PKI) adding CAL (online verification) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 20:58:00 -0000 chefren wrote: > On 11/16/06 19:01, Daniel Hartmeier wrote: > > On Wed, Nov 15, 2006 at 10:47:47AM -0700, Bob Beck wrote: > > > >>So, My two cents, make it complete first. Making an archetecture > >>for ssh that makes it easy to add trust centrally WITHOUT MAKING IT > >>EASY TO REMOVE IT is irresponsible. > > > > Thank you for the rant ;) > > > > Here's the result. Adding a simple daemon that the OpenSSH servers > > can query (over UDP port 22) to check user keys. See the first patch > > chunk for details. > > > > Is this what you had in mind? > > > > Daniel > > Gentlemen, > > I fully agree with the concerns of Bob Beck and I'm happy with the > attention of Daniel Hartmeier. And while everything is better than SSL... > > The security and thus revocation should always be on, by default. As soon as you configure the CAL server it is enabled. If you don't, well... UNIX and especially the *BSD's are about tools, not policy. We provide good tools to implement a wide range of sound policies. It's up to each admin to weight the tradeoffs and implement what is actually the most appropriate approach for their situation. > So it's a certificate system with off-line use of certificates with > inherent bad revocation since you cannot revoke a certificate without > being on-line with the authorizing server. If you configure online certificate verification it will fail closed. So if there is no response, the users will be denied access. > Or it should be an on-line (might of course be local) system where the > authorizing server (and hopefully a well designed backup...) is at least > always asked if access is OK at the beginning of a session (hopefully > possible to limit with time or amount of traffic or packets or or... > (but don't rebuild SSL!)). Have ever tried to read the patch Daniel posted with the message you are replying to? Apparently not so, it would have answered all that. > Please drop the classic "off-line" PKI scheme and present us an elegant > and robust on-line system. I don't think you are in the position to make any demands here... and most certainly not ridiculous ones. If you really want this, then do it yourself and post the patch. Sounds fair, doesn't it? -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 21:03:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89CD116A40F; Thu, 16 Nov 2006 21:03:57 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4364843D5D; Thu, 16 Nov 2006 21:03:56 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id kAGL3v0g012882 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Nov 2006 22:03:57 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id kAGL3vMR001938; Thu, 16 Nov 2006 22:03:57 +0100 (MET) Date: Thu, 16 Nov 2006 22:03:56 +0100 From: Daniel Hartmeier To: Andre Oppermann , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org, markus@openbsd.org Message-ID: <20061116210356.GL14649@insomnia.benzedrine.cx> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> <20061116180141.GH14649@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061116180141.GH14649@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.10i Cc: Subject: Re: OpenSSH Certkey (PKI) adding CAL (online verification) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 21:03:57 -0000 On Thu, Nov 16, 2006 at 07:01:41PM +0100, Daniel Hartmeier wrote: > +When Certkey user authentication fails either because no CAL server can be > +reached or because one CAL server delivers a valid reply marking the user key > +as invalid, the user key can still be used with other authentication methods > +(publickey) to gain access (if found in authorized_keys). Maybe it should be possible to enable CAL even for the traditional publickey authentication. That would enforce an online check even if Certkey isn't used. You could then revoke user keys and they wouldn't work even if they're present in the traditional authorized_keys files. Of course, if you do that and the CALs go down, the only way to login is using passwords. You don't expect CALs to disable these, too, I hope ;) Daniel From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 21:24:21 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A6DF16A415; Thu, 16 Nov 2006 21:24:21 +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 0BD1343D7D; Thu, 16 Nov 2006 21:24:12 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id kAGLNajb058333; Thu, 16 Nov 2006 16:23:46 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 16 Nov 2006 16:23:07 -0500 User-Agent: KMail/1.6.2 References: <200611162005.kAGK58cB084521@ambrisko.com> In-Reply-To: <200611162005.kAGK58cB084521@ambrisko.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200611161623.10758.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2200/Thu Nov 16 09:10:16 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-fs@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS patches 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, 16 Nov 2006 21:24:21 -0000 On Thursday 16 November 2006 03:05 pm, Doug Ambrisko wrote: > This is on i386: > one% grep memset zfs_20061117.patch > + (void) memset(p, 0, n); > + (void) memset(wp, 0, sizeof (*wp)); > + (void) memset(wp, 0, sizeof (*wp)); > +zap_memset(void *a, int c, size_t n) > + zap_memset(&l->l_phys->l_hdr, 0, sizeof (struct > zap_leaf_header)); + zap_memset(l->l_phys->l_hash, CHAIN_END, > 2*ZAP_LEAF_HASH_NUMENTRIES(l)); + > zap_memset(l->l_phys->l_hash, CHAIN_END, > 2*ZAP_LEAF_HASH_NUMENTRIES(l)); one% > > In contrib/opensolaris/lib/libuutil/common/uu_alloc.c > +void * > +uu_zalloc(size_t n) > +{ > + void *p = malloc(n); > + > + if (p == NULL) { > + uu_set_error(UU_ERROR_SYSTEM); > + return (NULL); > + } > + > + (void) memset(p, 0, n); > + > + return (p); > +} > + > > %nm dmu_objset.o | grep memset > U memset > % > > If I run it compile -E I see > static __inline void * > memset(void *b, int c, size_t len) > { > char *bb; > > if (c == 0) > bzero(b, len); > else > for (bb = (char *)b; len--; ) > *bb++ = c; > return (b); > } > > and nothing calling it unless it is what Max. is talking about. > I don't see other stuff breaking. It seems the memset() is not used in the kernel part. However, there are at least three places, which does 'struct foo bar = { 0 }': %grep '{ 0 }' zfs_20061117_sys.patch + struct oscarg oa = { 0 }; + struct snaparg sn = { 0 }; + zfs_create_data_t cbdata = { 0 }; (Note: zfs_20061117_sys.patch is extracted from the original patch.) The first two are from dmu_objset_create() and dmu_objset_snapshot() in sys/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c and that is what you saw. The third one is from zfs_ioc_create() in sys/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c. FYI... Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 22:01:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 179EC16A407; Thu, 16 Nov 2006 22:01:35 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B37BA43D46; Thu, 16 Nov 2006 22:01:34 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 16 Nov 2006 13:58:49 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id kAGM1WFO090828; Thu, 16 Nov 2006 14:01:32 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id kAGM1W2w090827; Thu, 16 Nov 2006 14:01:32 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200611162201.kAGM1W2w090827@ambrisko.com> In-Reply-To: <200611161623.10758.jkim@FreeBSD.org> To: Jung-uk Kim Date: Thu, 16 Nov 2006 14:01:32 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-fs@FreeBSD.org, Pawel Jakub Dawidek , freebsd-current@FreeBSD.org Subject: Re: ZFS patches 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, 16 Nov 2006 22:01:35 -0000 Okay, I have it compile and linked in: %kldload zfs ZFS filesystem version 3 ZFS storage pool version 3 %kldstat Id Refs Address Size Name 1 15 0xc0400000 662a78 kernel 2 1 0xc0a63000 1ff8 mfi_linux.ko 3 4 0xc0a65000 237c8 linux.ko 4 1 0xc0a89000 a690 mfi.ko 5 1 0xc0a94000 5b700 acpi.ko 6 1 0xc4df6000 6000 linprocfs.ko 7 1 0xc4dfd000 3000 linsysfs.ko 8 1 0xc5051000 9b000 zfs.ko % I "fixed" it by uncommented out: CFLAGS+=-O0 then it works. So it appears to be a compiler thing. Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 22:31:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3EA816A47C for ; Thu, 16 Nov 2006 22:31:22 +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 B17E943D46 for ; Thu, 16 Nov 2006 22:31:21 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GkplM-0006kt-EZ for freebsd-current@freebsd.org; Thu, 16 Nov 2006 23:31:16 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 23:31:16 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 23:31:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Thu, 16 Nov 2006 14:30:47 -0800 Lines: 38 Message-ID: References: <455CB311.8040301@freebsd.org> 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.4 Sender: news Cc: freebsd-net@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 22:31:23 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. The patch at this address seems incomplete and only contains changes to tcp_output.c. Notably missing is the SB_AUTOSIZE bitfield definition. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 22:43:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD44116A403 for ; Thu, 16 Nov 2006 22:43:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D283243D46 for ; Thu, 16 Nov 2006 22:43:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 38251 invoked from network); 16 Nov 2006 22:35:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 22:35:59 -0000 Message-ID: <455CE9A2.6030900@freebsd.org> Date: Thu, 16 Nov 2006 23:43:46 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andre Oppermann References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 22:43:48 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff The patch was missing the changes to tcp_usrreq.c and socketvar.h. I've replaced it with an updated one. Please fetch again. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 22:49:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FCC16A416 for ; Thu, 16 Nov 2006 22:49:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B79443D4C for ; Thu, 16 Nov 2006 22:49:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 38329 invoked from network); 16 Nov 2006 22:41:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 22:41:17 -0000 Message-ID: <455CEAE0.1060603@freebsd.org> Date: Thu, 16 Nov 2006 23:49:04 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Morgan References: <00f701c709cf$6c371d20$152ea8c0@phobos> In-Reply-To: <00f701c709cf$6c371d20$152ea8c0@phobos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 22:49:04 -0000 Morgan wrote: >> This is a patch adding automatic TCP send socket buffer >> sizing. > > > >> The patch is available here: >> >> http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff >> >> Any testers, especially with busy FTP servers, are very welcome. >> > > > Very nice indeed! I've actually been looking for something like this :-) I > would very much like to try it out but I need to know if I can benefit from > it with my setup. My network knowledge on this deep level is very limited so > I need to ask a few questions that probably sounds stupid... but here we go: > > Would this patch only benefit traffic generated from or destined to the > FreeBSD box itself or would it also benefit traffic generated behind it on a > LAN if the FreeBSD box was configured as: > > a) a router with NAT > > b) a router without NAT > > c) a bridge only > > Add to this the extra complexity of pf with synproxy and modulate state. I > simply don't know how (if at all) FreeBSD interacts with or manipulates > packets going through it under any of these circumstances, so I have to ask > to learn :-) It helps only if the FreeBSD box is the sender of data on a TCP connection. In all the cases you've listed there it doesn't (and can't) help. It would help though if you were running a full http proxy on it. > The patch didn't apply cleanly to my 6.1-RELEASE. Since this patch was > cross-posted to -current I guess it wasn't meant for me. Any chance you can > provide a patch for 6.1-RELEASE? This is the output: I'll do a backport to RELENG_6 tomorrow when I'm back in the office. > # patch Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: tcp_output.c > |=================================================================== > |RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v > |retrieving revision 1.121 > |diff -u -p -r1.121 tcp_output.c > |--- tcp_output.c 22 Oct 2006 11:52:16 -0000 1.121 > |+++ tcp_output.c 16 Nov 2006 18:35:43 -0000 > -------------------------- > File to patch: /usr/src/sys/netinet/tcp_output.c > Patching file /usr/src/sys/netinet/tcp_output.c using Plan A... > Hunk #1 succeeded at 49 (offset 1 line). > Hunk #2 failed at 105. > Hunk #3 failed at 395. > 2 out of 3 hunks failed--saving rejects to > /usr/src/sys/netinet/tcp_output.c.rej > Done > > > > Lastly, is it enough to rebuild only the kernel after applying this patch? Yes. > Once again, sorry for these stupid questions but this is the only way for me > to learn and I really would like to have this patch running on my system. No problem. Your effort is appreciated. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 23:24:53 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD21216A412 for ; Thu, 16 Nov 2006 23:24:53 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from alias2.ihug.co.nz (alias2.ihug.co.nz [203.96.222.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 793AC43D45 for ; Thu, 16 Nov 2006 23:24:53 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from ironport3.ihug.co.nz [203.109.254.23] by alias2.ihug.co.nz with esmtp (Exim 3.36 #1 (Debian)) id 1GkqZL-0005G2-00; Fri, 17 Nov 2006 12:22:55 +1300 Received: from 203-109-251-39.static.bliink.ihug.co.nz (HELO heff.fud.org.nz) ([203.109.251.39]) by ironport3.ihug.co.nz with ESMTP; 17 Nov 2006 12:25:14 +1300 X-Ironport-Seen: Yes Received: by heff.fud.org.nz (Postfix, from userid 1001) id AFD0E1CC29; Fri, 17 Nov 2006 12:24:50 +1300 (NZDT) Date: Fri, 17 Nov 2006 12:24:50 +1300 From: Andrew Thompson To: current@freebsd.org Message-ID: <20061116232450.GA16087@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: audit records X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 23:24:53 -0000 Hi, I thought i'd try out the new audit system and simulate an invalid login. I was suprised to see that ssh connections to localhost show up as 255.255.255.255, is this an error? % ssh df@localhost header,94,10,OpenSSH login,0,Fri Nov 17 12:16:44 2006, + 100 msec subject,-1,-1,-1,-1,-1,1378,1378,60666,255.255.255.255 text,invalid user name "df" return,failure : No such process,4294967295 trailer,94 % ssh df@192.168.0.182 header,95,10,OpenSSH login,0,Fri Nov 17 12:17:26 2006, + 892 msec subject,-1,-1,-1,-1,-1,1385,1385,58511,192.168.0.182 text,invalid user name "df" return,failure : No such process,4294967295 trailer,95 Andrew From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 21:52:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BBB416A49E for ; Thu, 16 Nov 2006 21:52:10 +0000 (UTC) (envelope-from sfrost@kenobi.snowman.net) Received: from kenobi.snowman.net (kenobi.snowman.net [70.84.9.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B0DB43D72 for ; Thu, 16 Nov 2006 21:50:53 +0000 (GMT) (envelope-from sfrost@kenobi.snowman.net) Received: by kenobi.snowman.net (Postfix, from userid 1000) id DA4025804C; Thu, 16 Nov 2006 15:50:52 -0600 (CST) Date: Thu, 16 Nov 2006 16:50:52 -0500 From: Stephen Frost To: Daniel Hartmeier Message-ID: <20061116215052.GI24675@kenobi.snowman.net> Mail-Followup-To: Daniel Hartmeier , tech@openbsd.org, freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org References: <20061115142820.GB14649@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vuSKPN9Gaa4EcW8B" Content-Disposition: inline In-Reply-To: <20061115142820.GB14649@insomnia.benzedrine.cx> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.16-2-vserver-686 (i686) X-Uptime: 16:43:51 up 59 days, 21:53, 24 users, load average: 0.62, 0.63, 0.55 User-Agent: Mutt/1.5.13 (2006-08-11) X-Mailman-Approved-At: Fri, 17 Nov 2006 01:01:33 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 21:52:10 -0000 --vuSKPN9Gaa4EcW8B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greetings, Overall I'd like to see OpenSSH support PKI in addition to the existing methods. I'm more keen on it being used for host authentication than for user certificates, personally. I did want to comment on this though: * Daniel Hartmeier (daniel@benzedrine.cx) wrote: > +Certkey does not involve online verfication, the CA is not contacted by either > +client or server. Instead, the CA generates certificates which are (once) > +distributed to hosts and users. Any subsequent logins take place without the > +involvment of the CA, based solely on the certificates provided between client > +and server. Would you consider adding support for OCSP? I saw alot of discussion regarding CRLs (and some of their rather well known downsides) but only once saw mention of OCSP, and that with no response. While CRLs are useful in some circumstances I believe OCSP is generally a better approach. Ideally, both would be supported. If I had to pick one I'd rather see OCSP than CRL support though. Thanks, Stephen --vuSKPN9Gaa4EcW8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFXN08rzgMPqB3kigRAuUEAJ9z/iOdxkg9bcIYlY1mpSsjJNuyMwCgmr11 wPK2LW0p+dvGNFv0kC9pb3w= =3xzk -----END PGP SIGNATURE----- --vuSKPN9Gaa4EcW8B-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 22:35:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A9DF16A62B; Thu, 16 Nov 2006 22:35:02 +0000 (UTC) (envelope-from pp@pp.dyndns.biz) Received: from mxfep03.bredband.com (mxfep03.bredband.com [195.54.107.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CBD843D76; Thu, 16 Nov 2006 22:34:54 +0000 (GMT) (envelope-from pp@pp.dyndns.biz) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep03.bredband.com with ESMTP id <20061116223453.NQFF2545.mxfep03.bredband.com@ironport2.bredband.com>; Thu, 16 Nov 2006 23:34:53 +0100 Received: from c-58d8e055.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.224.216.88]) by ironport2.bredband.com with ESMTP/TLS/AES256-SHA; 16 Nov 2006 23:34:53 +0100 Received: from phobos ([192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.13.6/8.13.6) with ESMTP id kAGMYmUb012901; Thu, 16 Nov 2006 23:34:52 +0100 (CET) (envelope-from pp@pp.dyndns.biz) From: "Morgan" Sender: "pp" To: Date: Thu, 16 Nov 2006 23:34:47 +0100 Message-ID: <00f701c709cf$6c371d20$152ea8c0@phobos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <455CB311.8040301@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccJsFUZ53nADhP1RDycyhIlM7RtTgAHKF0A X-Mailman-Approved-At: Fri, 17 Nov 2006 01:01:45 +0000 Cc: freebsd-net@freebsd.org Subject: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Nov 2006 22:35:02 -0000 > This is a patch adding automatic TCP send socket buffer > sizing. > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. > Very nice indeed! I've actually been looking for something like this :-) I would very much like to try it out but I need to know if I can benefit from it with my setup. My network knowledge on this deep level is very limited so I need to ask a few questions that probably sounds stupid... but here we go: Would this patch only benefit traffic generated from or destined to the FreeBSD box itself or would it also benefit traffic generated behind it on a LAN if the FreeBSD box was configured as: a) a router with NAT b) a router without NAT c) a bridge only Add to this the extra complexity of pf with synproxy and modulate state. I simply don't know how (if at all) FreeBSD interacts with or manipulates packets going through it under any of these circumstances, so I have to ask to learn :-) The patch didn't apply cleanly to my 6.1-RELEASE. Since this patch was cross-posted to -current I guess it wasn't meant for me. Any chance you can provide a patch for 6.1-RELEASE? This is the output: # patch X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 696A116A40F for ; Fri, 17 Nov 2006 00:14:34 +0000 (UTC) (envelope-from M.Denis@stud.elka.pw.edu.pl) Received: from higgs.elka.pw.edu.pl (higgs.elka.pw.edu.pl [194.29.160.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFD2843D4C for ; Fri, 17 Nov 2006 00:14:33 +0000 (GMT) (envelope-from M.Denis@stud.elka.pw.edu.pl) Received: from hadron.elka.pw.edu.pl ([194.29.160.27]:42854 "EHLO localhost") by higgs.elka.pw.edu.pl with ESMTP id S101434AbWKQAOZ (ORCPT ); Fri, 17 Nov 2006 01:14:25 +0100 Received: from higgs.elka.pw.edu.pl ([194.29.160.5]) by localhost (hadron [194.29.160.27]) (amavisd-new, port 251) with ESMTP id 16889-01-4 for ; Fri, 17 Nov 2006 01:14:08 +0100 (CET) Received: from mion.elka.pw.edu.pl ([194.29.160.35]:51174 "EHLO mion.elka.pw.edu.pl") by higgs.elka.pw.edu.pl with ESMTP id S54100AbWKPUH7 (ORCPT ); Thu, 16 Nov 2006 21:07:59 +0100 Received: from chello084010131213.chello.pl ([84.10.131.213]:65109 "EHLO localhost" ident: "TIMEDOUT" smtp-auth: "mdenis" TLS-CIPHER: TLS-PEER-CN1: ) by mion.elka.pw.edu.pl with ESMTPA id S108800AbWKPUH5 (ORCPT ); Thu, 16 Nov 2006 21:07:57 +0100 X-Comment: RFC 2476 MSA function at mion.elka.pw.edu.pl logged sender identity as: mdenis Date: Thu, 16 Nov 2006 22:07:52 +0100 From: Marek Denis To: freebsd-current@freebsd.org Message-Id: <20061116220752.f0c947c3.m.denis@stud.elka.pw.edu.pl> Organization: WEiTI - Politechnika Warszawska X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.8.19; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AmaVisD-new at elka.pw.edu.pl X-Mailman-Approved-At: Fri, 17 Nov 2006 01:02:01 +0000 Subject: FreeBSD CURRENT on HP nx7400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 00:14:34 -0000 Hi, About 2 months ago I was surfing the Internet, trying to find any tips how to install FreeBSD on my nx7400 laptop. The main problem was that FreeBSD didn't recognise sata drivers. In October, a new release of FreeBSD 7-cure has been released, and I would like to ask you, whether anybody has any version of fbsd on any nx7400 or similar hardware? Thanks in advance Marek Denis From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 02:56:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83D7016A416 for ; Fri, 17 Nov 2006 02:56:47 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07ECE43D49 for ; Fri, 17 Nov 2006 02:56:45 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so716204wxc for ; Thu, 16 Nov 2006 18:56:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=mu7dc/RhClrdLnWlTYVKXtI00Wup2RZA0OoPEShUZWLaqsKrb5H2/9hgiZs8yWbN7WQ45WAOI6BnMzRZlj8jGwqLyjs7WjnDaXAwCDHpLhvhHIGOChte0N2lSNGWapROi4wcSD1AA0jxt+XIzinZiHCS84fToZT/S3IBmeBRdpk= Received: by 10.90.25.7 with SMTP id 7mr1159365agy.1163732205269; Thu, 16 Nov 2006 18:56:45 -0800 (PST) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id 34sm4803445wra.2006.11.16.18.56.44; Thu, 16 Nov 2006 18:56:44 -0800 (PST) Date: Thu, 16 Nov 2006 21:56:39 -0500 From: Alexander Kabaev To: Jung-uk Kim Message-ID: <20061116215639.73d00824@kan.dnsalias.net> In-Reply-To: <200611161506.58128.jkim@FreeBSD.org> References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <200611161506.58128.jkim@FreeBSD.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_Fy.h/80.Q_ScLGLPieVjIY3"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: ZFS patches 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, 17 Nov 2006 02:56:47 -0000 --Sig_Fy.h/80.Q_ScLGLPieVjIY3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 16 Nov 2006 15:06:56 -0500 Jung-uk Kim wrote: > On Thursday 16 November 2006 02:15 pm, Andriy Gapon wrote: > > Hmm, I saw errors like this with some other 3rd party kernel module > > when its sources had constructs like: > > > > struct some_struct s =3D {0}; > > > > Changing the above initialization to explicit bzero() call helped > > in that case, but I think that there should be some compiler flags > > or something to handle this. >=20 > AFAIK, there was no way to handle this GCC bug with compiler flags. =20 > '-ffreestanding' should prevent this to happen but it does not. As=20 > Max Laier pointed out, it was discussed long time ago. Bruce Evans=20 > had good analysis on this issue, too. >=20 > Jung-uk Kim > _______________________________________________ > 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" This is not a GCC bug. -ffreestanding is _documented_ as requiring memset and friends as resolvable extern symbols. We were just lucky to get away without it before. --=20 Alexander Kabaev --Sig_Fy.h/80.Q_ScLGLPieVjIY3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXSTqQ6z1jMm+XZYRAsjxAKCSietsAqGiPX6N3SQOBlHy3fuLXACg52MT DLASmMhgEraxIEFNxiNU9wI= =rzgl -----END PGP SIGNATURE----- --Sig_Fy.h/80.Q_ScLGLPieVjIY3-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 07:57:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D529716A407; Fri, 17 Nov 2006 07:57:23 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FEEC43D55; Fri, 17 Nov 2006 07:57:22 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 43C3F5E25; Fri, 17 Nov 2006 10:57:21 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 2150F5DEA; Fri, 17 Nov 2006 10:57:21 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kAH7vOiX021821; Fri, 17 Nov 2006 10:57:24 +0300 (MSK) (envelope-from ru) Date: Fri, 17 Nov 2006 10:57:24 +0300 From: Ruslan Ermilov To: Alexander Kabaev Message-ID: <20061117075724.GB21627@rambler-co.ru> References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <200611161506.58128.jkim@FreeBSD.org> <20061116215639.73d00824@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20061116215639.73d00824@kan.dnsalias.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon , Jung-uk Kim Subject: Re: ZFS patches 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, 17 Nov 2006 07:57:23 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 09:56:39PM -0500, Alexander Kabaev wrote: > On Thu, 16 Nov 2006 15:06:56 -0500 > Jung-uk Kim wrote: >=20 > > On Thursday 16 November 2006 02:15 pm, Andriy Gapon wrote: > > > Hmm, I saw errors like this with some other 3rd party kernel module > > > when its sources had constructs like: > > > > > > struct some_struct s =3D {0}; > > > > > > Changing the above initialization to explicit bzero() call helped > > > in that case, but I think that there should be some compiler flags > > > or something to handle this. > >=20 > > AFAIK, there was no way to handle this GCC bug with compiler flags. =20 > > '-ffreestanding' should prevent this to happen but it does not. As=20 > > Max Laier pointed out, it was discussed long time ago. Bruce Evans=20 > > had good analysis on this issue, too. > >=20 > This is not a GCC bug. -ffreestanding is _documented_ as requiring > memset and friends as resolvable extern symbols. We were just lucky to > get away without it before. >=20 Yes. But to make it clear: it's there in libkern.h, just not external. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXWtkqRfpzJluFF4RAnONAKCEnwh1SR3Qxv+Y5PlgplswawZ6nQCfRCbN mkPoAAB1u+A9sDnSaqaANzY= =dmYW -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 09:04:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7894A16A403 for ; Fri, 17 Nov 2006 09:04:03 +0000 (UTC) (envelope-from drbrain@segment7.net) Received: from toxic.magnesium.net (toxic.magnesium.net [207.154.84.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38CC243D53 for ; Fri, 17 Nov 2006 09:04:03 +0000 (GMT) (envelope-from drbrain@segment7.net) Received: from [10.101.28.113] (ziz.jijo.segment7.net [216.254.21.90]) by toxic.magnesium.net (Postfix) with ESMTP id C3C77DA89E; Fri, 17 Nov 2006 01:04:02 -0800 (PST) In-Reply-To: <200610311629.06271.nb_root@videotron.ca> References: <200610311629.06271.nb_root@videotron.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E1778A4-F9FE-4391-AB80-E7785A57A19C@segment7.net> Content-Transfer-Encoding: 7bit From: Eric Hodel Date: Fri, 17 Nov 2006 01:04:13 -0800 To: Nicolas Blais X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org Subject: Re: Hifn 7955/7956 crypto accelerator questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 09:04:03 -0000 On Oct 31, 2006, at 1:29 PM, Nicolas Blais wrote: > Hi, > > I'm looking to get a couple of Soekris vpn1401 (hifn 7955) or > vpn1461 (hifn > 7956) to do some performance tests in a military environment with > FreeBSD > systems. Since this is a big project and I don't want to jump in > something > destined to fail, I'll ask your expertise. Also, scan the soekris-tech list archives here: http://lists.soekris.com/pipermail/soekris-tech The answers are generally net4xxx specific, but may be of some help. -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 12:06:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC7316A4D8 for ; Fri, 17 Nov 2006 12:06:01 +0000 (UTC) (envelope-from TEvans@mintel.com) Received: from rocky.mintel.co.uk (rocky2.mintel.com [217.206.187.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BE043D7C for ; Fri, 17 Nov 2006 12:05:37 +0000 (GMT) (envelope-from TEvans@mintel.com) Received: from notes03.mintel.co.uk (notes03.mintel.co.uk [10.0.11.9]) by rocky.mintel.co.uk (8.13.4/8.13.4) with SMTP id kAHC5Z5c051104; Fri, 17 Nov 2006 12:05:35 GMT (envelope-from TEvans@mintel.com) Received: by notes03.mintel.co.uk(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80257229.00425158 ; Fri, 17 Nov 2006 12:04:22 +0000 X-Lotus-FromDomain: MINTEL From: "Tom Evans" To: Marek Denis Message-ID: <80257229.00425124.00@notes03.mintel.co.uk> Date: Fri, 17 Nov 2006 12:05:21 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD CURRENT on HP nx7400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 12:06:01 -0000 Hi Marek I'm running -current on a HP 6320 with very few problems. It seems a very similar spec to the 7400 (Core (2) Duo, i945GM chipset, Intel 3945ABG wifi). I also had problems running -stable with the SATA drives in native mode= , which is why I'm running -current. The drive works fine in 'compatible'= mode in the BIOS in -stable. The only things currently not working 100% for me are: =A0 =A0 =A0 =A0 DVD insists on running PIO4 mode =A0 =A0 =A0 =A0 No DRI in X =A0 =A0 =A0 =A0 No drivers for 3945ABG =A0 =A0 =A0 =A0 Fingerprint reader doesnt work =A0 =A0 =A0 =A0 Bluetooth probably doesnt work (I have no bluetooth dev= ices, so never tried) Of these things, the only one I care enough to mess around with is the fingerprint reader (sounds fun :) I'm sure many of them are fixable. Of course, HP dont ship a video bios that actually supports the native resolution of the panel included, but sysutils/915resolution can fix that. Audio works fine following ariff@'s excellent work on snd_hda. I've not tried -stable for a few months, so it is more than possible that these fixes have been MFC'ed already - I think snd_hda has for sure. If you'd like my dmesg.boot / kernel configs, give us a shout. Cheers Tom |+---------------------------+-----------------------------------------= | || Marek Denis | = | || | freebsd-current@freebsd.org = | || Sent by: | =A0 =A0 =A0 =A0 cc: = | || owner-freebsd-current@fr| =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0= FreeBSD | || eebsd.org | CURRENT on HP nx7400 = | || | = | || 11/16/2006 09:07 PM | = | || | = | |+---------------------------+-----------------------------------------= | Hi, =A0 About 2 months ago I was surfing the Internet, trying to find any t= ips how to install FreeBSD on my nx7400 laptop. The main problem was that FreeBSD didn't recognise sata drivers. In October, a new release of FreeBSD 7-cure has been released, and I would like to ask you, whether anybody has any version of fbsd on any nx7400 or similar hardware? Thanks in advance Marek Denis _______________________________________________ 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 Nov 17 10:08:19 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89AFC16A407; Fri, 17 Nov 2006 10:08:19 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24AD943D58; Fri, 17 Nov 2006 10:08:19 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 889FA5A0538; Fri, 17 Nov 2006 21:08:17 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 5B6998C13; Fri, 17 Nov 2006 21:08:16 +1100 (EST) Date: Fri, 17 Nov 2006 21:08:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jung-uk Kim In-Reply-To: <200611161506.58128.jkim@FreeBSD.org> Message-ID: <20061117210000.S11101@delplex.bde.org> References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <200611161506.58128.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 17 Nov 2006 12:48:02 +0000 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: ZFS patches 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, 17 Nov 2006 10:08:19 -0000 On Thu, 16 Nov 2006, Jung-uk Kim wrote: > On Thursday 16 November 2006 02:15 pm, Andriy Gapon wrote: >> Hmm, I saw errors like this with some other 3rd party kernel module >> when its sources had constructs like: >> >> struct some_struct s = {0}; >> >> Changing the above initialization to explicit bzero() call helped >> in that case, but I think that there should be some compiler flags >> or something to handle this. > > AFAIK, there was no way to handle this GCC bug with compiler flags. > '-ffreestanding' should prevent this to happen but it does not. As > Max Laier pointed out, it was discussed long time ago. Bruce Evans > had good analysis on this issue, too. Source code that triggers this bug might be broken anyway. gcc should only call a function to do the zeroing for large structs, but large structs might be too large for the kernel stack. Bruce From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:02:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD87316A403 for ; Fri, 17 Nov 2006 13:02:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4F643D64 for ; Fri, 17 Nov 2006 13:02:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48134 invoked from network); 17 Nov 2006 12:54:46 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 12:54:46 -0000 Message-ID: <455DB2EE.8010804@freebsd.org> Date: Fri, 17 Nov 2006 14:02:38 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Bob Beck References: <20061115142820.GB14649@insomnia.benzedrine.cx> <20061116204921.GX26418@bofh.cns.ualberta.ca> In-Reply-To: <20061116204921.GX26418@bofh.cns.ualberta.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nick Bender , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 13:02:46 -0000 Bob Beck wrote: > > I would think it would be nice if "CAL" had a way of > saying "these are the ones to be revoked" so no shutdown, just > propagate the bad one - but I'm talking to daniel offline about it.. That's easy. echo "ab:cd:ef..." > /etc/ssh/blacklist Or use a prediodic rsync to do that. Every pubkey fingerprint listed in it is denied access. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:05:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42AC216A412 for ; Fri, 17 Nov 2006 13:05:52 +0000 (UTC) (envelope-from st41ker@megacom.ua) Received: from ferry.megacom.ua (ferry.megacom.ua [193.28.177.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C383243D58 for ; Fri, 17 Nov 2006 13:05:49 +0000 (GMT) (envelope-from st41ker@megacom.ua) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A46EACA7CC for ; Fri, 17 Nov 2006 15:05:47 +0200 (EET) Received: from ferry.megacom.ua ([127.0.0.1]) by localhost (ferry [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 34462-02 for ; Fri, 17 Nov 2006 15:05:47 +0200 (EET) Received: from cyber.megacom.ua (cyber.megacom.ua [193.28.177.17]) by ferry.megacom.ua (Postfix) with ESMTP id 60096CA7B1 for ; Fri, 17 Nov 2006 15:05:47 +0200 (EET) From: st41ker To: freebsd-current@freebsd.org Date: Fri, 17 Nov 2006 15:06:19 +0200 User-Agent: KMail/1.9.4 References: <200610311629.06271.nb_root@videotron.ca> <6E1778A4-F9FE-4391-AB80-E7785A57A19C@segment7.net> In-Reply-To: <6E1778A4-F9FE-4391-AB80-E7785A57A19C@segment7.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611171506.20398.st41ker@megacom.ua> X-Virus-Scanned: by clamav at megacom dot biz Subject: libdl.so bulked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 13:05:52 -0000 Hi, list I'm using CURRENT & have cleaned out old libs, thus i need to recompile all the stuff i know, but I have no time for doing it now =( Where is the sources for "lilbdl.so" library or how can I recompile only that one? ThankZ. From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:10:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F19E316A412 for ; Fri, 17 Nov 2006 13:10:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F03643D45 for ; Fri, 17 Nov 2006 13:10:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48232 invoked from network); 17 Nov 2006 13:02:08 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 13:02:08 -0000 Message-ID: <455DB4A7.60200@freebsd.org> Date: Fri, 17 Nov 2006 14:09:59 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Stephen Frost References: <20061115142820.GB14649@insomnia.benzedrine.cx> <20061116215052.GI24675@kenobi.snowman.net> In-Reply-To: <20061116215052.GI24675@kenobi.snowman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Hartmeier , tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 13:10:04 -0000 Stephen Frost wrote: > Greetings, > > Overall I'd like to see OpenSSH support PKI in addition to the existing > methods. I'm more keen on it being used for host authentication than > for user certificates, personally. I did want to comment on this > though: Like I said in another email the PKI support for host authentication is separate from accepting certificates for user authentication/authorization. > * Daniel Hartmeier (daniel@benzedrine.cx) wrote: > >>+Certkey does not involve online verfication, the CA is not contacted by either >>+client or server. Instead, the CA generates certificates which are (once) >>+distributed to hosts and users. Any subsequent logins take place without the >>+involvment of the CA, based solely on the certificates provided between client >>+and server. > > > Would you consider adding support for OCSP? I saw alot of > discussion regarding CRLs (and some of their rather well known > downsides) but only once saw mention of OCSP, and that with no response. > While CRLs are useful in some circumstances I believe OCSP is generally > a better approach. Ideally, both would be supported. If I had to pick > one I'd rather see OCSP than CRL support though. Nothing precludes an OCSP implementation and it can be easily inserted should someone write it. We don't do it because the goal of our OpenSSH PKI is to be completely self-contained w/o any external dependencies. Working right out of the box with minimal configuration effort. Only security that is easy to use will get used in a safe way. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:17:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6156516A407 for ; Fri, 17 Nov 2006 13:17:23 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D714643D49 for ; Fri, 17 Nov 2006 13:17:22 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9DF17383D5; Fri, 17 Nov 2006 14:17:21 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 743B0383CB; Fri, 17 Nov 2006 14:17:21 +0100 (CET) Received: from dude.automatvapen.se (81-234-214-163-no68.tbcn.telia.com [81.234.214.163]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 55BE037FA8; Fri, 17 Nov 2006 14:17:20 +0100 (CET) From: Joel Dahl To: Marek Denis In-Reply-To: <20061116220752.f0c947c3.m.denis@stud.elka.pw.edu.pl> References: <20061116220752.f0c947c3.m.denis@stud.elka.pw.edu.pl> Content-Type: text/plain Date: Fri, 17 Nov 2006 14:17:23 +0100 Message-Id: <1163769443.672.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD CURRENT on HP nx7400 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 13:17:23 -0000 On Thu, 2006-11-16 at 22:07 +0100, Marek Denis wrote: > Hi, > > About 2 months ago I was surfing the Internet, trying > to find any tips how to install FreeBSD on my nx7400 laptop. > The main problem was that FreeBSD didn't recognise sata > drivers. In October, a new release of FreeBSD 7-cure has > been released, and I would like to ask you, whether > anybody has any version of fbsd on any nx7400 or similar > hardware? 7-CURRENT works great on my HP nx7400: - The onbard network works with bfe(4). - The SATA hdd is detected without any problems. - To get the default 1280x800 resolution I need sysutils/915resolution from ports. - Touchpad works fine. - High Definition Audio works great with the snd_hda(4) driver. This laptop was used for some of the early debugging of the driver, so I can guarantee you that it will work (thanks to ariff@!). :-) - The wireless Intel 3945ABG does not work, but I guess wpi(4) will be ported from OpenBSD at some point (haven't tried the patches floating around on the lists yet). - ACPI seems to work ok and I get almost 3 hours of life in battery mode. I see "acpi_tz0: _CRT value is absurd, ignored (256.0C)" on the console sometimes however (more detailed report can be found on the freebsd-acpi@ list). -- Joel From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:29:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D8A516A403 for ; Fri, 17 Nov 2006 13:29:58 +0000 (UTC) (envelope-from dl@leo.org) Received: from tortuga.leo.org (tortuga.leo.org [83.220.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D37D743D46 for ; Fri, 17 Nov 2006 13:29:57 +0000 (GMT) (envelope-from dl@leo.org) Received: by tortuga.leo.org (Postfix, from userid 1000) id 923B2E09BE; Fri, 17 Nov 2006 14:29:56 +0100 (CET) Date: Fri, 17 Nov 2006 14:29:56 +0100 From: Daniel Lang To: "Wolfgang S. Rupprecht" Message-ID: <20061117132956.GB26343@tortuga.leo.org> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> <87ac2rjqaf.fsf@arbol.wsrcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ac2rjqaf.fsf@arbol.wsrcc.com> X-Geek: GCS/CC d-- s: a C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r+++ y+++ User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, tech@openbsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 13:29:58 -0000 Hi, Wolfgang S. Rupprecht wrote on Thu, Nov 16, 2006 at 08:43:20AM -0800: [..] > Oops. I quoted the wrong section. I had meant to quote the section > about the user_certificates. This is what I meant to cite: > > +A user certificate is an authorization made by the CA that the > +holder of a specific private key may login to the server as a > +specific user, without the need of an authorized_keys file being > +present. The CA gains the power to grant individual users access > +to the server, and users do no longer need to maintain > +authorized_keys files of their own. > > I don't see a problem with the host certificates methodology. (In > fact I'd love to see the known_hosts files fade away as more hosts > transition to using host certificates.) Ok, I see. A user certificate just means that the user is authenticated, so I agree that the difference between authentication and authorisation can be mixed up here and becomes blurred. In fact, it would mean, that you could abandon the authorized_keys file, but you would still need an "authorized_users" file, that would need to contain the DN (or a similar identifier) of the user that matches the certificate. So not a lot is saved, but things may become less transparent.... Cheers, Daniel From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:33:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A731916A417 for ; Fri, 17 Nov 2006 13:33:20 +0000 (UTC) (envelope-from kabaev@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 7283443D53 for ; Fri, 17 Nov 2006 13:33:18 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so830621wxc for ; Fri, 17 Nov 2006 05:33:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=Ud86v0LGt1ZOpA/RiuiixFzocEdogwuhLyTPJrV+lQ3dphjfaW5tGrTLjaywu2e4eYb3QpbIvKAlgQ9wbpJmTt6AET2qJD1H9tVRGX1/4GXe6I9t0gNtDm0vduoVEQDrkCc4dTefNjDo4gBy/MPrI8CY/GM3wO6H1GiEJX6uVvQ= Received: by 10.70.76.13 with SMTP id y13mr3105687wxa.1163770397391; Fri, 17 Nov 2006 05:33:17 -0800 (PST) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id i11sm4514444wxd.2006.11.17.05.33.15; Fri, 17 Nov 2006 05:33:16 -0800 (PST) Date: Fri, 17 Nov 2006 08:33:11 -0500 From: Alexander Kabaev To: Ruslan Ermilov Message-ID: <20061117083311.5ec6aee2@kan.dnsalias.net> In-Reply-To: <20061117075724.GB21627@rambler-co.ru> References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <200611161506.58128.jkim@FreeBSD.org> <20061116215639.73d00824@kan.dnsalias.net> <20061117075724.GB21627@rambler-co.ru> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_yFa1scru.N6g2kcEU0vGrD3; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon , Jung-uk Kim Subject: Re: ZFS patches 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, 17 Nov 2006 13:33:20 -0000 --Sig_yFa1scru.N6g2kcEU0vGrD3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 17 Nov 2006 10:57:24 +0300 Ruslan Ermilov wrote: > On Thu, Nov 16, 2006 at 09:56:39PM -0500, Alexander Kabaev wrote: > > On Thu, 16 Nov 2006 15:06:56 -0500 > > Jung-uk Kim wrote: > >=20 > > > On Thursday 16 November 2006 02:15 pm, Andriy Gapon wrote: > > > > Hmm, I saw errors like this with some other 3rd party kernel > > > > module when its sources had constructs like: > > > > > > > > struct some_struct s =3D {0}; > > > > > > > > Changing the above initialization to explicit bzero() call > > > > helped in that case, but I think that there should be some > > > > compiler flags or something to handle this. > > >=20 > > > AFAIK, there was no way to handle this GCC bug with compiler > > > flags. '-ffreestanding' should prevent this to happen but it does > > > not. As Max Laier pointed out, it was discussed long time ago. > > > Bruce Evans had good analysis on this issue, too. > > >=20 > > This is not a GCC bug. -ffreestanding is _documented_ as requiring > > memset and friends as resolvable extern symbols. We were just lucky > > to get away without it before. > >=20 > Yes. But to make it clear: it's there in libkern.h, just not > external. >=20 inline definitions do not satisfy the requirement. So memset is NOT there. I implemented simple-minded amd64 and i386 vesrions for GCC4 import. =20 --=20 Alexander Kabaev --Sig_yFa1scru.N6g2kcEU0vGrD3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXboaQ6z1jMm+XZYRAhc+AJ9Ih12+/0eewcWbCkWR5O00Xz5vuwCgi/NO zgmz97+DwmSD1g1CbSoOTDs= =5Ty4 -----END PGP SIGNATURE----- --Sig_yFa1scru.N6g2kcEU0vGrD3-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 13:40:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90A1316A47E; Fri, 17 Nov 2006 13:40:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA33E43D6D; Fri, 17 Nov 2006 13:40:08 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27017; Fri, 17 Nov 2006 15:40:05 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <455DBBB4.7010501@icyb.net.ua> Date: Fri, 17 Nov 2006 15:40:04 +0200 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Alexander Kabaev References: <1163701391.00638085.1163691003@10.7.7.3> <455CB8CA.8040603@icyb.net.ua> <200611161506.58128.jkim@FreeBSD.org> <20061116215639.73d00824@kan.dnsalias.net> <20061117075724.GB21627@rambler-co.ru> <20061117083311.5ec6aee2@kan.dnsalias.net> In-Reply-To: <20061117083311.5ec6aee2@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: ZFS patches 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, 17 Nov 2006 13:40:40 -0000 on 17/11/2006 15:33 Alexander Kabaev said the following: > On Fri, 17 Nov 2006 10:57:24 +0300 > Ruslan Ermilov wrote: > >> On Thu, Nov 16, 2006 at 09:56:39PM -0500, Alexander Kabaev wrote: >>> This is not a GCC bug. -ffreestanding is _documented_ as requiring >>> memset and friends as resolvable extern symbols. We were just lucky >>> to get away without it before. >>> >> Yes. But to make it clear: it's there in libkern.h, just not >> external. >> > > inline definitions do not satisfy the requirement. So memset is NOT > there. I implemented simple-minded amd64 and i386 vesrions for GCC4 > import. And just for the record: I got an impression from a message in a parallel branch of this discussion thread that the compiler behavior in this respect might also depend on optimization level, which probably doesn't mean much for practical usage, but might be an interesting factoid. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 14:02:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F74A16A407 for ; Fri, 17 Nov 2006 14:02:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EEF43D70 for ; Fri, 17 Nov 2006 14:02:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48802 invoked from network); 17 Nov 2006 13:54:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 13:54:36 -0000 Message-ID: <455DC0F4.1070309@freebsd.org> Date: Fri, 17 Nov 2006 15:02:28 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 14:02:46 -0000 Andre Oppermann wrote: > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. A RELENG_6 version (for FreeBSD 6.x) of the patch is here: http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELENG_6.diff Just apply this patch and recompile your kernel. It is activated by default. Be aware that all socket buffer sizing events get logged to syslog under LOG_DEBUG. This may affect overall system performance and you may want to disable logging to disk of this in syslogd.conf. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 15:16:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 313C516A4A0 for ; Fri, 17 Nov 2006 15:16:52 +0000 (UTC) (envelope-from garyj@jennejohn.org) Received: from mail08b.verio.de (mail08b.verio.de [213.198.55.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 08C3243D60 for ; Fri, 17 Nov 2006 15:16:50 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from mx90.stngva01.us.mxservers.net (198.173.112.7) by mail08b.verio.de (RS ver 1.0.95vs) with SMTP id 2-0447546607; Fri, 17 Nov 2006 16:16:49 +0100 (CET) Received: from www.jennejohn.org [213.198.5.174] (EHLO peedub.jennejohn.org) by mx90.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id c42dd554.10890.178.mx90.stngva01.us.mxservers.net; Fri, 17 Nov 2006 10:16:28 -0500 (EST) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.8/8.11.6) with ESMTP id kAHFGhbE011551; Fri, 17 Nov 2006 16:16:43 +0100 (CET) (envelope-from garyj@jennejohn.org) Message-Id: <200611171516.kAHFGhbE011551@peedub.jennejohn.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: st41ker In-Reply-To: Message from st41ker of "Fri, 17 Nov 2006 15:06:19 +0200." <200611171506.20398.st41ker@megacom.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 2006 16:16:43 +0100 From: Gary Jennejohn X-Spam: [F=0.0458967564; heur=0.500(-9900); stat=0.045; spamtraq-heur=0.500(2006111703)] X-MAIL-FROM: X-SOURCE-IP: [213.198.5.174] X-Loop-Detect: 1 X-DistLoop-Detect: 1 Cc: freebsd-current@freebsd.org Subject: Re: libdl.so bulked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 15:16:52 -0000 st41ker writes: > I'm using CURRENT & have cleaned out old libs, thus i need to recompile all > the stuff i know, but I have no time for doing it now =( > Where is the sources for "lilbdl.so" library or how can I recompile only that > > one? > There's no such thing as "lilbdl.so". I assume you mean libdl.so. libdl.so is a Linux library and is installed as part of one of the Linux base ports. You can't compile this library yourself. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 17:22:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3625816A412 for ; Fri, 17 Nov 2006 17:22:54 +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 D653543D69 for ; Fri, 17 Nov 2006 17:22:47 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl7QG-0005Vr-3n for freebsd-current@freebsd.org; Fri, 17 Nov 2006 18:22:40 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 18:22:40 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 18:22:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Fri, 17 Nov 2006 09:22:22 -0800 Lines: 72 Message-ID: References: <200611152004.kAFK4vfe058983@repoman.freebsd.org> 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.4 Sender: news Subject: Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.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: Fri, 17 Nov 2006 17:22:54 -0000 (moving to current to avoid dirtying src further) John Baldwin wrote: > jhb 2006-11-15 20:04:57 UTC > > FreeBSD src repository > > Modified files: > sys/dev/bce if_bce.c > sys/dev/em if_em.c if_em.h > sys/dev/mpt mpt.h mpt_pci.c > Log: > Add MSI support to em(4), bce(4), and mpt(4). For now, we only support > devices that support a maximum of 1 message, and we use that 1 message > instead of the INTx rid 0 IRQ with the same interrupt handler, etc. > > Revision Changes Path > 1.19 +11 -3 src/sys/dev/bce/if_bce.c > 1.164 +11 -2 src/sys/dev/em/if_em.c > 1.56 +1 -0 src/sys/dev/em/if_em.h > 1.31 +1 -0 src/sys/dev/mpt/mpt.h > 1.39 +14 -1 src/sys/dev/mpt/mpt_pci.c > _______________________________________________ > cvs-src@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-src > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" This is great, I don't know if you plan on adding MSI support to all network drivers that could support it, but here's the output from the Tyan S2895 (k8WE) for the nve0 and nve1 devices, which report supporting 2 messages. pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LMAC:0) pci_link8: Picked IRQ 21 with weight 1 pcib0: slot 10 INTA routed to irq 21 via \\_SB_.PCI0.LMAC found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit [...] pcib6: matched entry for 128.10.INTA (src \\_SB_.PCI1.LMAC:0) pci_link22: Picked IRQ 52 with weight 0 ioapic3: Changing polarity for pin 20 to high pcib6: slot 10 INTA routed to irq 52 via \\_SB_.PCI1.LMAC found-> vendor=0x10de, dev=0x005d, revid=0xa3 bus=128, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit nve0@pci0:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Ethernet Controller' class = bridge nve1@pci128:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Ethernet Controller' class = bridge -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 17:59:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A55716A494 for ; Fri, 17 Nov 2006 17:59:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5226B43D75 for ; Fri, 17 Nov 2006 17:59:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 51730 invoked from network); 17 Nov 2006 17:51:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 17:51:29 -0000 Message-ID: <455DF87D.8040604@freebsd.org> Date: Fri, 17 Nov 2006 18:59:25 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Morgan References: <013901c70a6f$84d7eee0$152ea8c0@phobos> In-Reply-To: <013901c70a6f$84d7eee0$152ea8c0@phobos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 17:59:30 -0000 Morgan wrote: >> A RELENG_6 version (for FreeBSD 6.x) of the patch is here: >> >> http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELE >> NG_6.diff >> >> Just apply this patch and recompile your kernel. It is >> activated by default. > > Downloaded, applied, recompiled, installed and rebooted without any errors. Good. > I did however add the sysctl variables to my /etc/sysctl.conf just in case. Unnecessary. ;-) >> Be aware that all socket buffer sizing events get logged to >> syslog under LOG_DEBUG. > > Does this mean they will automatically show up in /var/log/debug.log? Yes, or in /var/log/messages. >> This may affect overall system >> performance and you may want to disable logging to disk of >> this in syslogd.conf. > > I could use some help with the syntax for this... :-) I'd remove "kern.debug" from the /var/log/messages line and comment out the /var/log/debug.log line for the time being after you see a couple of lines with tcp_output: ... > And a final question: Will this feature work regardless of what side > initiates the TCP connection? Or will I have to instruct my ftp-users to use > active mode only when they transfer files to/from my FreeBSD box? It doesn't matter which side opens the connection. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 18:13:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5074416A403 for ; Fri, 17 Nov 2006 18:13:26 +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 6229B43D53 for ; Fri, 17 Nov 2006 18:13:24 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAHIDHkE028093; Fri, 17 Nov 2006 11:13:22 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455DFBBB.7020307@samsco.org> Date: Fri, 17 Nov 2006 11:13:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mark Atkinson References: <200611152004.kAFK4vfe058983@repoman.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.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: Fri, 17 Nov 2006 18:13:26 -0000 Mark Atkinson wrote: > (moving to current to avoid dirtying src further) > > John Baldwin wrote: >> jhb 2006-11-15 20:04:57 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/dev/bce if_bce.c >> sys/dev/em if_em.c if_em.h >> sys/dev/mpt mpt.h mpt_pci.c >> Log: >> Add MSI support to em(4), bce(4), and mpt(4). For now, we only support >> devices that support a maximum of 1 message, and we use that 1 message >> instead of the INTx rid 0 IRQ with the same interrupt handler, etc. >> >> Revision Changes Path >> 1.19 +11 -3 src/sys/dev/bce/if_bce.c >> 1.164 +11 -2 src/sys/dev/em/if_em.c >> 1.56 +1 -0 src/sys/dev/em/if_em.h >> 1.31 +1 -0 src/sys/dev/mpt/mpt.h >> 1.39 +14 -1 src/sys/dev/mpt/mpt_pci.c >> _______________________________________________ >> cvs-src@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/cvs-src >> To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > > This is great, I don't know if you plan on adding MSI support to all network > drivers that could support it, but here's the output from the Tyan S2895 > (k8WE) for the nve0 and nve1 devices, which report supporting 2 messages. > The challenge is knowing what meaning the chip assigns to each of those messages, as well as knowing what errata come with it. It's not just a mechanical code change to the driver. You could always try the simple route with only allocating a single message, but you'd then have to make sure that it actually works reliably for everyone. Scott From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 18:41:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B01E816A4A7; Fri, 17 Nov 2006 18:41:12 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFDA643D49; Fri, 17 Nov 2006 18:41:11 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.11] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 4D63B61C25; Fri, 17 Nov 2006 19:41:10 +0100 (CET) Message-ID: <455E0244.1070903@thedarkside.nl> Date: Fri, 17 Nov 2006 19:41:08 +0100 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.7 (X11/20061018) MIME-Version: 1.0 To: Andre Oppermann References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 18:41:12 -0000 Andre Oppermann wrote: > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. Are you planning to implement something similar for the receive path? -- Pieter From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 18:59:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 216DD16A417 for ; Fri, 17 Nov 2006 18:59:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31DCF43D4C for ; Fri, 17 Nov 2006 18:59:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 52696 invoked from network); 17 Nov 2006 18:51:31 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 18:51:31 -0000 Message-ID: <455E068D.1030000@freebsd.org> Date: Fri, 17 Nov 2006 19:59:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Pieter de Boer References: <455CB311.8040301@freebsd.org> <455E0244.1070903@thedarkside.nl> In-Reply-To: <455E0244.1070903@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 18:59:28 -0000 Pieter de Boer wrote: > Andre Oppermann wrote: > > >> With automatic TCP send socket buffers we can start with a small buffer >> and quickly grow it in parallel with the TCP congestion window to match >> real network conditions. > > Are you planning to implement something similar for the receive path? Yes, but it's a bit harder. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 19:12:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 909B216A407 for ; Fri, 17 Nov 2006 19:12:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05CF843D55 for ; Fri, 17 Nov 2006 19:12:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kAHJCakb051880; Fri, 17 Nov 2006 14:12:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Nov 2006 13:17:14 -0500 User-Agent: KMail/1.9.1 References: <200611152004.kAFK4vfe058983@repoman.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611171317.14909.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 17 Nov 2006 14:12:36 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2201/Fri Nov 17 07:16:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mark Atkinson Subject: Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.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: Fri, 17 Nov 2006 19:12:41 -0000 On Friday 17 November 2006 12:22, Mark Atkinson wrote: > (moving to current to avoid dirtying src further) > > John Baldwin wrote: > > jhb 2006-11-15 20:04:57 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/dev/bce if_bce.c > > sys/dev/em if_em.c if_em.h > > sys/dev/mpt mpt.h mpt_pci.c > > Log: > > Add MSI support to em(4), bce(4), and mpt(4). For now, we only support > > devices that support a maximum of 1 message, and we use that 1 message > > instead of the INTx rid 0 IRQ with the same interrupt handler, etc. > > > > Revision Changes Path > > 1.19 +11 -3 src/sys/dev/bce/if_bce.c > > 1.164 +11 -2 src/sys/dev/em/if_em.c > > 1.56 +1 -0 src/sys/dev/em/if_em.h > > 1.31 +1 -0 src/sys/dev/mpt/mpt.h > > 1.39 +14 -1 src/sys/dev/mpt/mpt_pci.c > > _______________________________________________ > > cvs-src@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/cvs-src > > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > > This is great, I don't know if you plan on adding MSI support to all network > drivers that could support it, but here's the output from the Tyan S2895 > (k8WE) for the nve0 and nve1 devices, which report supporting 2 messages. > > pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LMAC:0) > pci_link8: Picked IRQ 21 with weight 1 > pcib0: slot 10 INTA routed to irq 21 via \\_SB_.PCI0.LMAC > found-> vendor=0x10de, dev=0x005d, revid=0xa3 > bus=0, slot=14, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > > [...] > > pcib6: matched entry for 128.10.INTA (src \\_SB_.PCI1.LMAC:0) > pci_link22: Picked IRQ 52 with weight 0 > ioapic3: Changing polarity for pin 20 to high > pcib6: slot 10 INTA routed to irq 52 via \\_SB_.PCI1.LMAC > found-> vendor=0x10de, dev=0x005d, revid=0xa3 > bus=128, slot=14, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > > nve0@pci0:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'nForce4 Ethernet Controller' > class = bridge > > nve1@pci128:10:0: class=0x068000 card=0x289510f1 chip=0x005710de rev=0xa3 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'nForce4 Ethernet Controller' > class = bridge For devices that support more than 1 message you really need docs to figure out what conditions the different messages are tied to (and if it will work if the system only gives it 1 message instead of 2, etc.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 19:22:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F1A316A47B for ; Fri, 17 Nov 2006 19:22:45 +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 3737B43D55 for ; Fri, 17 Nov 2006 19:22:42 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl9II-00021O-Do for freebsd-current@freebsd.org; Fri, 17 Nov 2006 20:22:34 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 20:22:34 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 20:22:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Fri, 17 Nov 2006 11:22:09 -0800 Lines: 50 Message-ID: References: <455CB311.8040301@freebsd.org> 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.4 Sender: news Cc: freebsd-net@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 19:22:45 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. Did some minimal testing and it appears to apply cleanly and log: ov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 33304, new 41496, sb_cc 31776, snd_wnd 40544, sendwnd 20272 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 41496, new 49688, sb_cc 38232, snd_wnd 46336, sendwnd 27512 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 49688, new 57880, sb_cc 46960, snd_wnd 63712, sendwnd 40544 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 57880, new 66072, sb_cc 55568, snd_wnd 63712, sendwnd 60816 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 66072, new 74264, sb_cc 65168, snd_wnd 63712, sendwnd 63712 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 74264, new 82456, sb_cc 65168, snd_wnd 63712, sendwnd 63712 -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 16:19:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 669C916A40F for ; Fri, 17 Nov 2006 16:19:34 +0000 (UTC) (envelope-from aleksey.kvyato@electro-com.ru) Received: from mail.electro-com.ru (mail.electro-com.ru [86.110.161.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E723F43D70 for ; Fri, 17 Nov 2006 16:19:33 +0000 (GMT) (envelope-from aleksey.kvyato@electro-com.ru) Received: from [212.118.59.3] (helo=[10.10.101.183]) by mail.electro-com.ru with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gl6RA-000E4g-Dl for current@freebsd.org; Fri, 17 Nov 2006 19:19:32 +0300 From: Alex Kvyato To: current@freebsd.org Content-Type: text/plain Organization: ElectroCom Date: Fri, 17 Nov 2006 19:19:03 +0300 Message-Id: <1163780343.964.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Nov 2006 20:52:26 +0000 Cc: Subject: snd_hda poblem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aleksey.kvyato@electro-com.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:19:34 -0000 laptop computer: acer 2441 problem: soundcard driver is working incorrectly - sound is hoarse and noisy # uname -a FreeBSD 7.0-CURRENT-200610 FreeBSD 7.0-CURRENT-200610 #0: Mon Oct 2 09:23:54 UTC 2006 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # kldstat Id Refs Address Size Name 1 15 0xc0400000 798d68 kernel 2 1 0xc0b99000 ea80 snd_hda.ko 3 2 0xc0ba8000 361b8 sound.ko 4 1 0xc0bdf000 2ef4 wlan_acl.ko 5 1 0xc0be2000 1b98 wlan_xauth.ko 6 1 0xc0be4000 5b388 acpi.ko 7 1 0xc29e9000 1c000 linux.ko 8 1 0xc2bb6000 3000 daemon_saver.ko # dmesg Copyright (c) 1992-2006 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-200610 #0: Mon Oct 2 09:23:54 UTC 2006 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M CPU 410 @ 1.46GHz (1463.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xafe9fbff Features2=0xc109> AMD Features=0x100000 real memory = 468320256 (446 MB) avail memory = 444366848 (423 MB) ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xd8000000-0xdfffffff,0xd0100000-0xd010ffff irq 17 at device 5.0 on pci1 pcib2: at device 4.0 on pci0 pci2: on pcib2 pcib3: at device 6.0 on pci0 pci5: on pcib3 ohci0: mem 0xd0005000-0xd0005fff irq 19 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xd0006000-0xd0006fff irq 19 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ehci0: mem 0xd0007000-0xd0007fff irq 19 at device 19.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 8 ports with 8 removable, self powered ugen0: on uhub2 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8460-0x846f at device 20.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: mem 0xd0000000-0xd0003fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci10: on pcib4 cbb0: at device 0.0 on pci10 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 rl0: port 0xa000-0xa0ff mem 0xd0202000-0xd02020ff irq 20 at device 1.0 on pci10 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:16:d3:45:59:7b pci10: at device 6.0 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 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 battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1463015851 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 ral0: mem 0xd0204000-0xd0205fff at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:13:d4:d2:03:44 acd0: DVDR at ata0-slave UDMA33 pcm0: pcm0: Trying to mount root from ufs:/dev/ad0s2a WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ums0: on uhub0 ums0: 3 buttons and Z dir. rl0: link state changed to DOWN rl0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 17:21:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B428116A416 for ; Fri, 17 Nov 2006 17:21:21 +0000 (UTC) (envelope-from redchrom@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2309043D6B for ; Fri, 17 Nov 2006 17:21:13 +0000 (GMT) (envelope-from redchrom@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so682055uge for ; Fri, 17 Nov 2006 09:21:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:reply-to:mail-followup-to:mime-version:content-type:content-disposition:user-agent:x-useless-header; b=rl7OmKtxYdApoCdKmTaupqiM8hKf4oWHrZ+h3YNcp/4lcXA6IVprLrBYTNas6NRBbtfJW6Sp8sPFw0owR7bx3ZMfmKIylzW8TScBLgboHHCwpv582Hm4TpktehDyiWM8geqVUbIMRnaY8aU/FMqWMDRW9u255Aj1KVJsSpX4Z2k= Received: by 10.67.21.11 with SMTP id y11mr73041ugi.1163784072121; Fri, 17 Nov 2006 09:21:12 -0800 (PST) Received: from localhost ( [80.83.238.249]) by mx.google.com with ESMTP id 59sm4266696ugf.2006.11.17.09.21.02; Fri, 17 Nov 2006 09:21:11 -0800 (PST) Date: Sat, 18 Nov 2006 01:21:02 +0800 From: Stepan Zastupov To: acpi@freebsd.org, current@freebsd.org Message-ID: <20061117172102.GA836@stepan.ispsystem.net> Mail-Followup-To: acpi@freebsd.org, current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Useless-Header: They killed Kenny! THOSE BASTARDS! X-Mailman-Approved-At: Fri, 17 Nov 2006 20:52:38 +0000 Cc: Subject: Add suspend/resume support for the bfe driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stepan Zastupov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 17:21:21 -0000 A couple of weeks ago I wrote patch which added suspend/resume support for the bfe driver. It just attach/deattach device when suspend/resume as it done in Linux driver. In pr I wrote that it dosen'y help but now I know that it dose! Just need to stop devd before suspend, I do it from the /etc/rc.suspend and start from /etc/rc.resume. I hope somebody commit the patch into kernel tree. Here is the pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/104652 -- Best regards, Stepan Zastupov aka RedChrom ISPSystem From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 17:40:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD34716A415; Fri, 17 Nov 2006 17:40:58 +0000 (UTC) (envelope-from pp@pp.dyndns.biz) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C74F43D45; Fri, 17 Nov 2006 17:40:56 +0000 (GMT) (envelope-from pp@pp.dyndns.biz) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep01.bredband.com with ESMTP id <20061117174056.KFC17968.mxfep01.bredband.com@ironport2.bredband.com>; Fri, 17 Nov 2006 18:40:56 +0100 Received: from c-58d8e055.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.224.216.88]) by ironport2.bredband.com with ESMTP/TLS/AES256-SHA; 17 Nov 2006 18:40:55 +0100 Received: from phobos ([192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.13.6/8.13.6) with ESMTP id kAHHkSKp001185; Fri, 17 Nov 2006 18:46:32 +0100 (CET) (envelope-from pp@pp.dyndns.biz) From: "Morgan" Sender: "pp" To: Date: Fri, 17 Nov 2006 18:40:48 +0100 Message-ID: <013901c70a6f$84d7eee0$152ea8c0@phobos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <455DC0F4.1070309@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccKUb82ur/NrvZ0Ri67/tQE/3b1QwAHM5Zg X-Mailman-Approved-At: Fri, 17 Nov 2006 20:54:52 +0000 Cc: freebsd-net@freebsd.org Subject: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 17:40:58 -0000 > A RELENG_6 version (for FreeBSD 6.x) of the patch is here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELE > NG_6.diff > > Just apply this patch and recompile your kernel. It is > activated by default. Downloaded, applied, recompiled, installed and rebooted without any errors. I did however add the sysctl variables to my /etc/sysctl.conf just in case. > Be aware that all socket buffer sizing events get logged to > syslog under LOG_DEBUG. Does this mean they will automatically show up in /var/log/debug.log? > This may affect overall system > performance and you may want to disable logging to disk of > this in syslogd.conf. I could use some help with the syntax for this... :-) And a final question: Will this feature work regardless of what side initiates the TCP connection? Or will I have to instruct my ftp-users to use active mode only when they transfer files to/from my FreeBSD box? Regards Morgan From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 19:12:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88A7416A4F0; Fri, 17 Nov 2006 19:12:57 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 912D443D45; Fri, 17 Nov 2006 19:12:56 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kAHJCn3L051885; Fri, 17 Nov 2006 14:12:50 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-acpi@freebsd.org, Stepan Zastupov Date: Fri, 17 Nov 2006 14:12:34 -0500 User-Agent: KMail/1.9.1 References: <20061117172102.GA836@stepan.ispsystem.net> In-Reply-To: <20061117172102.GA836@stepan.ispsystem.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611171412.35214.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 17 Nov 2006 14:12:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2201/Fri Nov 17 07:16:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx X-Mailman-Approved-At: Fri, 17 Nov 2006 20:55:46 +0000 Cc: current@freebsd.org Subject: Re: Add suspend/resume support for the bfe 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, 17 Nov 2006 19:12:57 -0000 On Friday 17 November 2006 12:21, Stepan Zastupov wrote: > A couple of weeks ago I wrote patch which added suspend/resume support > for the bfe driver. It just attach/deattach device when suspend/resume > as it done in Linux driver. In pr I wrote that it dosen'y help but now I > know that it dose! Just need to stop devd before suspend, I do it from > the /etc/rc.suspend and start from /etc/rc.resume. I hope somebody > commit the patch into kernel tree. > Here is the pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/104652 Usually drivers don't detach on suspend. How about this patch instead: Index: if_bfe.c =================================================================== RCS file: /usr/cvs/src/sys/dev/bfe/if_bfe.c,v retrieving revision 1.40 diff -u -r1.40 if_bfe.c --- if_bfe.c 28 May 2006 20:35:39 -0000 1.40 +++ if_bfe.c 17 Nov 2006 19:11:47 -0000 @@ -87,6 +87,8 @@ static int bfe_probe (device_t); static int bfe_attach (device_t); static int bfe_detach (device_t); +static int bfe_suspend (device_t); +static int bfe_resume (device_t); static void bfe_release_resources (struct bfe_softc *); static void bfe_intr (void *); static void bfe_start (struct ifnet *); @@ -136,6 +138,8 @@ DEVMETHOD(device_attach, bfe_attach), DEVMETHOD(device_detach, bfe_detach), DEVMETHOD(device_shutdown, bfe_shutdown), + DEVMETHOD(device_suspend, bfe_suspend), + DEVMETHOD(device_resume, bfe_resume), /* bus interface */ DEVMETHOD(bus_print_child, bus_generic_print_child), @@ -480,6 +484,39 @@ } static int +bfe_suspend(device_t dev) +{ + struct bfe_softc *sc; + + sc = device_get_softc(dev); + BFE_LOCK(sc); + bfe_stop(sc); + BFE_UNLOCK(sc); + + return (0); +} + +static int +bfe_resume(device_t dev) +{ + struct bfe_softc *sc; + struct ifnet *ifp; + + sc = device_get_softc(dev); + ifp = sc->bfe_ifp; + BFE_LOCK(sc); + if (ifp->if_flags & IFF_UP) { + bfe_init_locked(sc); + if (ifp->if_drv_flags & IFF_DRV_RUNNING && + !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + bfe_start_locked(ifp); + } + BFE_UNLOCK(sc); + + return (0); +} + +static int bfe_miibus_readreg(device_t dev, int phy, int reg) { struct bfe_softc *sc; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 17 20:02:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C41916A403 for ; Fri, 17 Nov 2006 20:02:57 +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 CDC8743D46 for ; Fri, 17 Nov 2006 20:02:54 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl9vJ-0001ZD-QO for freebsd-current@freebsd.org; Fri, 17 Nov 2006 21:02:53 +0100 Received: from wsrcc-nat.wsrcc.com ([64.142.50.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 21:02:53 +0100 Received: from wolfgang+gnus200611 by wsrcc-nat.wsrcc.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 21:02:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wolfgang S. Rupprecht" Date: Fri, 17 Nov 2006 12:02:37 -0800 Organization: W S Rupprecht Computer Consulting, Fremont CA Lines: 26 Message-ID: <87ejs1c04i.fsf@arbol.wsrcc.com> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> <87ac2rjqaf.fsf@arbol.wsrcc.com> <20061117132956.GB26343@tortuga.leo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: wsrcc-nat.wsrcc.com X-WSRCC: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:BV3CzN4WulsdSA42AUxq1mZaqGI= Sender: news X-Mailman-Approved-At: Fri, 17 Nov 2006 20:56:41 +0000 Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Nov 2006 20:02:57 -0000 Daniel Lang writes: > In fact, it would mean, that you could abandon the authorized_keys > file, but you would still need an "authorized_users" file, that > would need to contain the DN (or a similar identifier) of the user > that matches the certificate. So not a lot is saved, but things > may become less transparent.... The advantage of splitting the authorization / authentication is it opens up the possibility of a single certificate being used to identify a user over quite a large range of non-cooperating organizations. That way a potential user can approach the system admin with their company-wide (or Internet-wide) certificate and the system admin can enter that certificate into the a user's list (or into the user's authorized_keys file etc). I'd much rather they use the whole certificate as the test instead of just the DN it contains. That way, the only aspect of the PKI they need to trust is that the key is strong enough to resist breaking. They don't really need to trust that the DN is their true name or that there won't be a DN name-clash a few months down the road. They just need to trust that the PKI works. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 11:49:40 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFF2716A403 for ; Sat, 18 Nov 2006 11:49:40 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2E6843D45 for ; Sat, 18 Nov 2006 11:49:37 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id kAIBnb6W054327; Sat, 18 Nov 2006 11:49:38 GMT (envelope-from ariff@FreeBSD.org) Date: Sat, 18 Nov 2006 19:49:02 +0800 From: Ariff Abdullah To: aleksey.kvyato@electro-com.ru Message-Id: <20061118194902.1e32be52.ariff@FreeBSD.org> In-Reply-To: <1163780343.964.5.camel@localhost.localdomain> References: <1163780343.964.5.camel@localhost.localdomain> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__18_Nov_2006_19_49_02_+0800_5UOtOJ9llDqw2tuz" Cc: current@FreeBSD.org Subject: Re: snd_hda poblem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2006 11:49:41 -0000 --Signature=_Sat__18_Nov_2006_19_49_02_+0800_5UOtOJ9llDqw2tuz Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 17 Nov 2006 19:19:03 +0300 Alex Kvyato wrote: >=20 > laptop computer: acer 2441 >=20 > problem: soundcard driver is working incorrectly - sound is hoarse > and noisy >=20 [...] > pcm0: > pcm0: ^^^^^^^^^^^^^ way too old. Please update your sources first. If the problem persist, send me the verbose dmesg. > Trying to mount root from ufs:/dev/ad0s2a > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > ums0: addr 2> on uhub0 > ums0: 3 buttons and Z dir. > rl0: link state changed to DOWN > rl0: link state changed to UP >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sat__18_Nov_2006_19_49_02_+0800_5UOtOJ9llDqw2tuz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXvM5lr+deMUwTNoRAmZxAKDOYsQAwMnPCdYfBumG1+yPQoquzACePArS ikVRw+QS5NxlenDTzc9Ikng= =BFW7 -----END PGP SIGNATURE----- --Signature=_Sat__18_Nov_2006_19_49_02_+0800_5UOtOJ9llDqw2tuz-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 08:31:56 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE49016A407; Sat, 18 Nov 2006 08:31:56 +0000 (UTC) (envelope-from aleksey.kvyato@electro-com.ru) Received: from mail.electro-com.ru (mail.electro-com.ru [86.110.161.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E134743D45; Sat, 18 Nov 2006 08:31:52 +0000 (GMT) (envelope-from aleksey.kvyato@electro-com.ru) Received: from [212.118.59.3] (helo=[10.10.101.183]) by mail.electro-com.ru with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GlLc8-00001z-Ek; Sat, 18 Nov 2006 11:31:53 +0300 From: Alex Kvyato To: Andrew Pantyukhin In-Reply-To: References: <1163780343.964.5.camel@localhost.localdomain> Content-Type: text/plain; charset=KOI8-R Organization: ElectroCom Date: Sat, 18 Nov 2006 11:31:22 +0300 Message-Id: <1163838682.937.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 18 Nov 2006 13:10:16 +0000 Cc: current@freebsd.org Subject: Re: snd_hda poblem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aleksey.kvyato@electro-com.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 08:31:56 -0000 ÷ ÓÂ, 18/11/2006 × 01:26 +0300, Andrew Pantyukhin ÐÉÛÅÔ: > On 11/17/06, Alex Kvyato wrote: > > > > laptop computer: acer 2441 > > 1. echo 'boot_verbose="YES"' >> /boot/loader.conf > 2. CC "Ariff Abdullah" Copyright (c) 1992-2006 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-200610 #0: Mon Oct 2 09:23:54 UTC 2006 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Using 64 colors for the VM-PQ tuning (1024, 4) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0c41000. Preloaded elf module "/boot/kernel/snd_hda.ko" at 0xc0c4119c. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0c41248. Preloaded elf module "/boot/kernel/wlan_acl.ko" at 0xc0c412f4. Preloaded elf module "/boot/kernel/wlan_xauth.ko" at 0xc0c413a4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0c41454. MP Configuration Table version 1.4 found at 0xc009e171 Table 'FACP' at 0x1beaaeb0 Table 'APIC' at 0x1beaaf24 MADT: Found table at 0x1beaaf24 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) INTR: Adding local APIC 0 as a target ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193201 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1463009152 Hz CPU: Intel(R) Celeron(R) M CPU 410 @ 1.46GHz (1463.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xafe9fbff Features2=0xc109> AMD Features=0x100000 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 1 MB, 4-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 1024 kbytes, 4-way associative, 64 bytes/line real memory = 468320256 (446 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000001b681fff, 442867712 bytes (108122 pages) avail memory = 444366848 (423 MB) bios32: Found BIOS32 Service Directory header at 0xc00f85a0 bios32: Entry = 0xfd984 (c00fd984) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd980+0x0 pnpbios: Found PnP BIOS data at 0xc00f8630 pnpbios: Entry = e736:a022 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Interrupt override: source 9, irq 21 ioapic0: intpin 9 disabled ioapic0: intpin 21 trigger: level ioapic0: intpin 21 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 MAC ACL support> wlan: mac acl policy registered wlan: <802.11 Link Layer> ath_rate: version 1.2 random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Oct 2 2006 09:23:20) npx0: INT 16 interface acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a104 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=5a311002) pcibios: BIOS_PRESENT call failed AcpiOsDerivePciId: bus 0 dev 18 func 0 AcpiOsDerivePciId: bus 0 dev 20 func 1 acpi0: Power Button (fixed) acpi0: wakeup code va 0xcb3b4000 pa 0x9c000 AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 11 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 7 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x8010 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1002, dev=0x5a31, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a3f, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a36, revid=0x00 bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a38, revid=0x00 bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4374, revid=0x80 bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type 1, range 32, base d0005000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4375, revid=0x80 bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type 1, range 32, base d0006000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4373, revid=0x80 bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base d0007000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4372, revid=0x83 bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00008450, size 4, enabled map[14]: type 1, range 32, base d0004400, size 10, enabled found-> vendor=0x1002, dev=0x4376, revid=0x80 bus=0, slot=20, func=1 class=01-01-82, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 1 message map[20]: type 4, range 32, base 00008460, size 4, enabled found-> vendor=0x1002, dev=0x437b, revid=0x01 bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base d0000000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4377, revid=0x80 bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4371, revid=0x80 bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x9000-0x9fff pcib1: memory decode 0xd0100000-0xd01fffff pcib1: prefetched decode 0xd8000000-0xdfffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x5a62, revid=0x00 bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type 3, range 32, base d8000000, size 27, enabled pcib1: (null) requested memory range 0xd8000000-0xdfffffff: good map[14]: type 4, range 32, base 00009000, size 8, enabled pcib1: (null) requested I/O range 0x9000-0x90ff: in range map[18]: type 1, range 32, base d0100000, size 16, enabled pcib1: (null) requested memory range 0xd0100000-0xd010ffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 17 vgapci0: port 0x9000-0x90ff mem 0xd8000000-0xdfffffff,0xd0100000-0xd010ffff irq 17 at device 5.0 on pci1 pcib2: at device 4.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 4 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0x0-0x0 pcib2: prefetched decode 0x0-0x0 pci2: on pcib2 pci2: physical bus=2 pcib3: at device 6.0 on pci0 pcib3: secondary bus 5 pcib3: subordinate bus 7 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0x0-0x0 pcib3: prefetched decode 0x0-0x0 pci5: on pcib3 pci5: physical bus=5 ohci0: mem 0xd0005000-0xd0005fff irq 19 at device 19.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0005000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xd0006000-0xd0006fff irq 19 at device 19.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0006000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ehci0: mem 0xd0007000-0xd0007fff irq 19 at device 19.2 on pci0 ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0007000 ehci0: [GIANT-LOCKED] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 8 ports with 8 removable, self powered ugen0: on uhub2 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8460-0x846f at device 20.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8460 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 50 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 51 ata1: [MPSAFE] pcm0: mem 0xd0000000-0xd0003fff irq 16 at device 20.2 on pci0 pcm0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0000000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 pcm0: [MPSAFE] isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: secondary bus 10 pcib4: subordinate bus 12 pcib4: I/O decode 0xa000-0xafff pcib4: memory decode 0xd0200000-0xd02fffff pcib4: prefetched decode 0xfff00000-0xfffff pcib4: Subtractively decoded bridge. pci10: on pcib4 pci10: physical bus=10 found-> vendor=0x1524, dev=0x1410, revid=0x01 bus=10, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc5 (49250 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=10, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 8, enabled pcib4: (null) requested I/O range 0xa000-0xa0ff: in range map[14]: type 1, range 32, base d0202000, size 8, enabled pcib4: (null) requested memory range 0xd0202000-0xd02020ff: good pcib4: matched entry for 10.1.INTA pcib4: slot 1 INTA hardwired to IRQ 20 found-> vendor=0x14e4, dev=0x4318, revid=0x02 bus=10, slot=6, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base d0200000, size 13, enabled pcib4: (null) requested memory range 0xd0200000-0xd0201fff: good pcib4: matched entry for 10.6.INTA pcib4: slot 6 INTA hardwired to IRQ 23 cbb0: at device 0.0 on pci10 pcib4: cbb0 requested memory range 0xd0200000-0xd02fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xd0203000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib4: matched entry for 10.0.INTA pcib4: slot 0 INTA hardwired to IRQ 22 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x14101524 0x02100007 0x06070001 0x00024010 0x10: 0xd0203000 0x020000a0 0x200c0b0a 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07450116 0x40: 0x00801025 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x08405021 0x00000000 0x00000000 0x01aa1b22 0x90: 0x604402c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe010001 0x00c00000 0x00000003 0x0000001f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00001000 0x00800080 0x06080600 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xa000 pcib4: rl0 requested I/O range 0xa000-0xa0ff: in range pcib4: rl0 requested I/O range 0xa000-0xa0ff: in range rl0: port 0xa000-0xa0ff mem 0xd0202000-0xd02020ff irq 20 at device 1.0 on pci10 pcib4: rl0 requested I/O range 0xa000-0xa0ff: in range miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:16:d3:45:59:7b ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54 rl0: [MPSAFE] pci10: at device 6.0 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 56 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 battery0: on acpi0 acpi_acad0: on acpi0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4001 0x4001 0x4001 0x4001 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x4001 0x4001 0x4001 0x4001 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4001 0x4001 0x4001 0x4001 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices ums0: on uhub0 ums0: 3 buttons and Z dir. Device configuration finished. procfs registered lapic: Divisor 2, Frequency 66500433 hz Timecounter "TSC" frequency 1463009152 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. battery0: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times pcib4: (null) requested memory range 0xd0200000-0xd02fffff: good cbb0: Opening memory: cbb0: Normal: 0xd0204000-0xd0205fff unknown: Lazy allocation of 0x2000 bytes rid 0x10 type 3 at 0xd0204000 cbb0: Opening memory: map[10]: type 1, range 32, base d0204000, size 13, enabled pcib4: (null) requested memory range 0xd0204000-0xd0205fff: good found-> vendor=0x1814, dev=0x0201, revid=0x01 bus=11, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0410, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 ral0: mem 0xd0204000-0xd0205fff at device 0.0 on cardbus0 ral0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xd0204000 cbb0: Opening memory: cbb0: Normal: 0xd0204000-0xd0205fff ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: bpf attached ral0: Ethernet address: 00:13:d4:d2:03:44 ral0: bpf attached ral0: bpf attached ral0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ral0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ral0: [MPSAFE] battery0: battery initialization done, tried 1 times ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on IXP400 chip ad0: setting UDMA100 on IXP400 chip ad0: 57231MB at ata0-master UDMA100 ad0: 117210240 sectors [116280C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Silicon Image check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on IXP400 chip acd0: setting UDMA33 on IXP400 chip acd0: DVDR drive at ata0 as slave acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: HDA_DEBUG: Starting CORB Engine... pcm0: HDA_DEBUG: Starting RIRB Engine... pcm0: HDA_DEBUG: Enabling controller interrupt... pcm0: HDA_DEBUG: Scanning HDA codecs... pcm0: hdac_probe_codec: Probing codec: 0 pcm0: hdac_probe_codec: startnode=1 endnode=2 pcm0: hdac_probe_codec: Found AFG nid=1 [startnode=1 endnode=2] pcm0: HDA_DEBUG: Parsing AFG nid=1 cad=0 pcm0: Vendor: 0x000010ec pcm0: Device: 0x00000883 pcm0: Revision: 0x00000000 pcm0: Stepping: 0x00000002 pcm0: PCI Subvendor: 0x010b1025 pcm0: Nodes: start=2 endnode=39 total=37 pcm0: HDA_DEBUG: Parsing Ctls... pcm0: HDA_DEBUG: Parsing vendor patch... pcm0: HDA_DEBUG: Building AFG tree... pcm0: HWiP: HDA Widget Parser - Revision 1 pcm0: HWiP: Found 10 DAC(s) using HDA_PARSE_MIXER strategy. pcm0: HDA_DEBUG: AFG commit... pcm0: HDA_DEBUG: Ctls commit... pcm0: [ 6] Ctl nid=11 childnid=27 DISABLED pcm0: [ 7] Ctl nid=11 childnid=28 DISABLED pcm0: [ 8] Ctl nid=11 childnid=29 DISABLED pcm0: [ 9] Ctl nid=11 childnid=20 Bind to NONE pcm0: [10] Ctl nid=11 childnid=21 Bind to NONE pcm0: [11] Ctl nid=11 childnid=22 DISABLED pcm0: [12] Ctl nid=11 childnid=23 DISABLED pcm0: [13] Ctl nid=12 Bind to NONE pcm0: [15] Ctl nid=12 childnid=11 Bind to NONE pcm0: [16] Ctl nid=13 Bind to NONE pcm0: [18] Ctl nid=13 childnid=11 Bind to NONE pcm0: [19] Ctl nid=14 Bind to NONE pcm0: [21] Ctl nid=14 childnid=11 Bind to NONE pcm0: [22] Ctl nid=15 Bind to NONE pcm0: [24] Ctl nid=15 childnid=11 Bind to NONE pcm0: [25] Ctl nid=20 Bind to NONE pcm0: [26] Ctl nid=20 Bind to NONE pcm0: [27] Ctl nid=21 Bind to NONE pcm0: [28] Ctl nid=21 Bind to NONE pcm0: [29] Ctl nid=22 DISABLED pcm0: [30] Ctl nid=22 DISABLED pcm0: [31] Ctl nid=23 DISABLED pcm0: [32] Ctl nid=23 DISABLED pcm0: [33] Ctl nid=24 Bind to NONE pcm0: [34] Ctl nid=24 Bind to NONE pcm0: [35] Ctl nid=25 Bind to NONE pcm0: [36] Ctl nid=25 Bind to NONE pcm0: [37] Ctl nid=26 Bind to NONE pcm0: [38] Ctl nid=26 Bind to NONE pcm0: [39] Ctl nid=27 DISABLED pcm0: [40] Ctl nid=27 DISABLED pcm0: [41] Ctl nid=34 childnid=24 Bind to NONE pcm0: [42] Ctl nid=34 childnid=25 Bind to NONE pcm0: [43] Ctl nid=34 childnid=26 Bind to NONE pcm0: [44] Ctl nid=34 childnid=27 DISABLED pcm0: [45] Ctl nid=34 childnid=28 DISABLED pcm0: [46] Ctl nid=34 childnid=29 DISABLED pcm0: [47] Ctl nid=34 childnid=20 Bind to NONE pcm0: [48] Ctl nid=34 childnid=21 Bind to NONE pcm0: [49] Ctl nid=34 childnid=22 DISABLED pcm0: [50] Ctl nid=34 childnid=23 DISABLED pcm0: [51] Ctl nid=34 childnid=11 Bind to NONE pcm0: [52] Ctl nid=35 childnid=24 Bind to NONE pcm0: [53] Ctl nid=35 childnid=25 Bind to NONE pcm0: [54] Ctl nid=35 childnid=26 Bind to NONE pcm0: [55] Ctl nid=35 childnid=27 DISABLED pcm0: [56] Ctl nid=35 childnid=28 DISABLED pcm0: [57] Ctl nid=35 childnid=29 DISABLED pcm0: [58] Ctl nid=35 childnid=20 Bind to NONE pcm0: [59] Ctl nid=35 childnid=21 Bind to NONE pcm0: [60] Ctl nid=35 childnid=22 DISABLED pcm0: [61] Ctl nid=35 childnid=23 DISABLED pcm0: [62] Ctl nid=35 childnid=11 Bind to NONE pcm0: [63] Ctl nid=38 Bind to NONE pcm0: [65] Ctl nid=38 childnid=11 Bind to NONE pcm0: HDA_DEBUG: PCMDIR_PLAY setup... pcm0: HDA_DEBUG: PCMDIR_REC setup... pcm0: HDA_DEBUG: OSS mixer initialization... pcm0: Enabling Soft PCM volume pcm0: Mixer "vol": child=0x00000010 pcm0: Mixer "pcm": parent="vol" pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: Soft PCM mixer ENABLED pcm0: HDA_DEBUG: Registering PCM channels... pcm0: sndbuf_setmap 1b461000, 4000; 0xd2901000 -> 1b461000 pcm0: sndbuf_setmap 1b450000, 4000; 0xd2905000 -> 1b450000 pcm0: pcm0: pcm0: pcm0: HDA quirks: GPIO1 FIXEDRATE FORCESTEREO pcm0: pcm0: +-------------------+ pcm0: | DUMPING HDA NODES | pcm0: +-------------------+ pcm0: pcm0: Default Parameter pcm0: ----------------- pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: IN amp: 0x00000000 pcm0: OUT amp: 0x00000000 pcm0: pcm0: nid: 2 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000011 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 3 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000011 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 4 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000011 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 5 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000011 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 6 [DIGITAL] [DISABLED] pcm0: name: audio output pcm0: widget_cap: 0x00000211 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x001e0560 pcm0: PCM size: 16 20 24 32 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 7 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 8 [ANALOG] pcm0: name: audio input pcm0: widget_cap: 0x0010011b pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000800 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x00060160 pcm0: PCM size: 16 20 pcm0: PCM rate: 22 44 48 pcm0: Input amp: 0x80051f08 pcm0: mute=1 step=31 size=5 offset=8 pcm0: connections: 1 pcm0: | pcm0: + <- nid=35 [audio mixer] pcm0: pcm0: nid: 9 [ANALOG] pcm0: name: audio input pcm0: widget_cap: 0x0010011b pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000800 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x00060160 pcm0: PCM size: 16 20 pcm0: PCM rate: 22 44 48 pcm0: Input amp: 0x80051f08 pcm0: mute=1 step=31 size=5 offset=8 pcm0: connections: 1 pcm0: | pcm0: + <- nid=34 [audio mixer] pcm0: pcm0: nid: 10 [DIGITAL] [DISABLED] pcm0: name: audio input pcm0: widget_cap: 0x00100391 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x001e0560 pcm0: PCM size: 16 20 24 32 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 1 pcm0: | pcm0: + <- nid=31 [pin: speaker (none)] [DISABLED] pcm0: pcm0: nid: 11 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010b pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x000000c1 pcm0: Input amp: 0x80051f17 pcm0: mute=1 step=31 size=5 offset=23 pcm0: connections: 10 pcm0: | pcm0: + <- nid=24 [pin: Mic in (jack)] pcm0: | pcm0: + <- nid=25 [pin: Mic in (fixed)] pcm0: | pcm0: + <- nid=26 [pin: line in (jack)] pcm0: | pcm0: + <- nid=27 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=28 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=29 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=20 [pin: headphones out (jack)] pcm0: | pcm0: + <- nid=21 [pin: line out (fixed)] pcm0: | pcm0: + <- nid=22 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=23 [pin: speaker (none)] [DISABLED] pcm0: pcm0: nid: 12 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x000000d1 pcm0: Output amp: 0x51f1f pcm0: mute=0 step=31 size=5 offset=31 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=2 [audio output] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 13 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Output amp: 0x51f1f pcm0: mute=0 step=31 size=5 offset=31 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=3 [audio output] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 14 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Output amp: 0x51f1f pcm0: mute=0 step=31 size=5 offset=31 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=4 [audio output] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 15 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Output amp: 0x51f1f pcm0: mute=0 step=31 size=5 offset=31 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=5 [audio output] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 16 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 17 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 18 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 19 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 20 [ANALOG] pcm0: name: pin: headphones out (jack) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000003e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x0121401f pcm0: Pin control: 0x000000c0 HP OUT pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] (selected) pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 21 [ANALOG] pcm0: name: pin: line out (fixed) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000003e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x99030110 pcm0: Pin control: 0x00000040 OUT pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] (selected) pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 22 [ANALOG] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000003e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x000000e0 HP IN OUT pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 23 [ANALOG] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000003e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x000000e0 HP IN OUT pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 24 [ANALOG] pcm0: name: pin: Mic in (jack) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Pin cap: 0x0000173e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x01a1983f pcm0: Pin control: 0x00000021 IN pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] (selected) pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 25 [ANALOG] pcm0: name: pin: Mic in (fixed) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000081 pcm0: Pin cap: 0x0000173e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x99a30130 pcm0: Pin control: 0x00000020 IN pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] (selected) pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 26 [ANALOG] pcm0: name: pin: line in (jack) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000002 pcm0: Ctl flags: 0x00000041 pcm0: Pin cap: 0x0000173e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x01813031 pcm0: Pin control: 0x00000020 IN pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] (selected) pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 27 [ANALOG] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x0040018f pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x0000173e pcm0: TRQD HP OUT IN : UNSOL pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x000000e0 HP IN OUT pcm0: Output amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: Input amp: 0x270300 pcm0: mute=0 step=3 size=39 offset=0 pcm0: connections: 5 pcm0: | pcm0: + <- nid=12 [audio mixer] pcm0: | pcm0: + <- nid=13 [audio mixer] pcm0: | pcm0: + <- nid=14 [audio mixer] pcm0: | pcm0: + <- nid=15 [audio mixer] pcm0: | pcm0: + <- nid=38 [audio mixer] pcm0: pcm0: nid: 28 [ANALOG] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x00400001 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000020 pcm0: IN pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x00000020 IN pcm0: connections: 0 pcm0: pcm0: nid: 29 [ANALOG] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x00400000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000020 pcm0: IN pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x00000020 IN pcm0: connections: 0 pcm0: pcm0: nid: 30 [DIGITAL] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x00400300 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000010 pcm0: OUT pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x00000040 OUT pcm0: connections: 1 pcm0: | pcm0: + <- nid=6 [audio output] [DISABLED] pcm0: pcm0: nid: 31 [DIGITAL] [DISABLED] pcm0: name: pin: speaker (none) pcm0: widget_cap: 0x00400200 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: Pin cap: 0x00000020 pcm0: IN pcm0: Pin config: 0x411111f0 pcm0: Pin control: 0x00000020 IN pcm0: connections: 0 pcm0: pcm0: nid: 32 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00040 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 33 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 34 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000006 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x0 pcm0: mute=0 step=0 size=0 offset=0 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 11 pcm0: | pcm0: + <- nid=24 [pin: Mic in (jack)] pcm0: | pcm0: + <- nid=25 [pin: Mic in (fixed)] pcm0: | pcm0: + <- nid=26 [pin: line in (jack)] pcm0: | pcm0: + <- nid=27 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=28 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=29 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=20 [pin: headphones out (jack)] pcm0: | pcm0: + <- nid=21 [pin: line out (fixed)] pcm0: | pcm0: + <- nid=22 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=23 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 35 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000006 pcm0: Ctl flags: 0x00000000 pcm0: Output amp: 0x0 pcm0: mute=0 step=0 size=0 offset=0 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 11 pcm0: | pcm0: + <- nid=24 [pin: Mic in (jack)] pcm0: | pcm0: + <- nid=25 [pin: Mic in (fixed)] pcm0: | pcm0: + <- nid=26 [pin: line in (jack)] pcm0: | pcm0: + <- nid=27 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=28 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=29 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=20 [pin: headphones out (jack)] pcm0: | pcm0: + <- nid=21 [pin: line out (fixed)] pcm0: | pcm0: + <- nid=22 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=23 [pin: speaker (none)] [DISABLED] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: nid: 36 [ANALOG] pcm0: name: vendor widget pcm0: widget_cap: 0x00f00000 pcm0: Parse flags: 0x00000000 pcm0: Ctl flags: 0x00000000 pcm0: connections: 0 pcm0: pcm0: nid: 37 [ANALOG] pcm0: name: audio output pcm0: widget_cap: 0x00000011 pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: connections: 0 pcm0: pcm0: nid: 38 [ANALOG] pcm0: name: audio mixer pcm0: widget_cap: 0x0020010f pcm0: Parse flags: 0x00000001 pcm0: Ctl flags: 0x00000011 pcm0: Output amp: 0x51f1f pcm0: mute=0 step=31 size=5 offset=31 pcm0: Input amp: 0x80000000 pcm0: mute=1 step=0 size=0 offset=0 pcm0: connections: 2 pcm0: | pcm0: + <- nid=37 [audio output] pcm0: | pcm0: + <- nid=11 [audio mixer] pcm0: pcm0: +------------------------+ pcm0: | DUMPING HDA AMPLIFIERS | pcm0: +------------------------+ pcm0: pcm0: 1: nid=8 dir=0x2 index=0 ossmask=0x00000800 ossdev=0 pcm0: 2: nid=9 dir=0x2 index=0 ossmask=0x00000800 ossdev=0 pcm0: 3: nid=11 cnid=24 dir=0x2 index=0 ossmask=0x00000081 ossdev=7 pcm0: 4: nid=11 cnid=25 dir=0x2 index=1 ossmask=0x00000081 ossdev=7 pcm0: 5: nid=11 cnid=26 dir=0x2 index=2 ossmask=0x00000041 ossdev=6 pcm0: 6: nid=11 cnid=27 dir=0x2 index=3 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 7: nid=11 cnid=28 dir=0x2 index=4 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 8: nid=11 cnid=29 dir=0x2 index=5 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 9: nid=11 cnid=20 dir=0x2 index=6 ossmask=0x00000000 ossdev=0 pcm0: 10: nid=11 cnid=21 dir=0x2 index=7 ossmask=0x00000000 ossdev=0 pcm0: 11: nid=11 cnid=22 dir=0x2 index=8 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 12: nid=11 cnid=23 dir=0x2 index=9 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 13: nid=12 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 14: nid=12 cnid=2 dir=0x2 index=0 ossmask=0x00000011 ossdev=4 pcm0: 15: nid=12 cnid=11 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 16: nid=13 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 17: nid=13 cnid=3 dir=0x2 index=0 ossmask=0x00000011 ossdev=4 pcm0: 18: nid=13 cnid=11 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 19: nid=14 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 20: nid=14 cnid=4 dir=0x2 index=0 ossmask=0x00000011 ossdev=4 pcm0: 21: nid=14 cnid=11 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 22: nid=15 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 23: nid=15 cnid=5 dir=0x2 index=0 ossmask=0x00000011 ossdev=4 pcm0: 24: nid=15 cnid=11 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 25: nid=20 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 26: nid=20 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 27: nid=21 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 28: nid=21 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 29: nid=22 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 30: nid=22 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 31: nid=23 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 32: nid=23 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 33: nid=24 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 34: nid=24 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 35: nid=25 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 36: nid=25 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 37: nid=26 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 38: nid=26 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 39: nid=27 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 40: nid=27 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 41: nid=34 cnid=24 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 42: nid=34 cnid=25 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 43: nid=34 cnid=26 dir=0x2 index=2 ossmask=0x00000000 ossdev=0 pcm0: 44: nid=34 cnid=27 dir=0x2 index=3 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 45: nid=34 cnid=28 dir=0x2 index=4 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 46: nid=34 cnid=29 dir=0x2 index=5 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 47: nid=34 cnid=20 dir=0x2 index=6 ossmask=0x00000000 ossdev=0 pcm0: 48: nid=34 cnid=21 dir=0x2 index=7 ossmask=0x00000000 ossdev=0 pcm0: 49: nid=34 cnid=22 dir=0x2 index=8 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 50: nid=34 cnid=23 dir=0x2 index=9 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 51: nid=34 cnid=11 dir=0x2 index=10 ossmask=0x00000000 ossdev=0 pcm0: 52: nid=35 cnid=24 dir=0x2 index=0 ossmask=0x00000000 ossdev=0 pcm0: 53: nid=35 cnid=25 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: 54: nid=35 cnid=26 dir=0x2 index=2 ossmask=0x00000000 ossdev=0 pcm0: 55: nid=35 cnid=27 dir=0x2 index=3 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 56: nid=35 cnid=28 dir=0x2 index=4 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 57: nid=35 cnid=29 dir=0x2 index=5 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 58: nid=35 cnid=20 dir=0x2 index=6 ossmask=0x00000000 ossdev=0 pcm0: 59: nid=35 cnid=21 dir=0x2 index=7 ossmask=0x00000000 ossdev=0 pcm0: 60: nid=35 cnid=22 dir=0x2 index=8 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 61: nid=35 cnid=23 dir=0x2 index=9 ossmask=0x00000000 ossdev=0 [DISABLED] pcm0: 62: nid=35 cnid=11 dir=0x2 index=10 ossmask=0x00000000 ossdev=0 pcm0: 63: nid=38 dir=0x1 index=0 ossmask=0x00000000 ossdev=0 pcm0: 64: nid=38 cnid=37 dir=0x2 index=0 ossmask=0x00000011 ossdev=4 pcm0: 65: nid=38 cnid=11 dir=0x2 index=1 ossmask=0x00000000 ossdev=0 pcm0: pcm0: +-----------------------------------+ pcm0: | DUMPING HDA AUDIO/VOLUME CONTROLS | pcm0: +-----------------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- nid: 11 index: 0 (nid: 24) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000081 pcm0: | pcm0: +- nid: 11 index: 1 (nid: 25) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000081 pcm0: | pcm0: +- nid: 11 index: 2 (nid: 26) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000041 pcm0: | pcm0: +- nid: 12 index: 0 (nid: 2) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 13 index: 0 (nid: 3) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 14 index: 0 (nid: 4) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 15 index: 0 (nid: 5) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 38 index: 0 (nid: 37) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- nid: 12 index: 0 (nid: 2) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 13 index: 0 (nid: 3) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 14 index: 0 (nid: 4) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 15 index: 0 (nid: 5) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: | pcm0: +- nid: 38 index: 0 (nid: 37) mute: 1 step: 0 size: 0 off: 0 dir=0x2 ossmask=0x00000011 pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- nid: 11 index: 0 (nid: 24) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000081 pcm0: | pcm0: +- nid: 11 index: 1 (nid: 25) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000081 pcm0: pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- nid: 11 index: 2 (nid: 26) mute: 1 step: 31 size: 5 off: 23 dir=0x2 ossmask=0x00000041 pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- nid: 8 index: 0 mute: 1 step: 31 size: 5 off: 8 dir=0x2 ossmask=0x00000800 pcm0: | pcm0: +- nid: 9 index: 0 mute: 1 step: 31 size: 5 off: 8 dir=0x2 ossmask=0x00000800 pcm0: pcm0: Recording sources: pcm0: pcm0: nid=34 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic in (jack)] [recsrc: vol, mic] pcm0: | pcm0: + <- nid=25 [pin: Mic in (fixed)] [recsrc: vol, mic] pcm0: | pcm0: + <- nid=26 [pin: line in (jack)] [recsrc: vol, line] pcm0: | pcm0: + <- nid=20 [pin: headphones out (jack)] pcm0: | pcm0: + <- nid=21 [pin: line out (fixed)] pcm0: | pcm0: + <- nid=11 [audio mixer] [recsrc: vol, line, mic] pcm0: pcm0: nid=35 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic in (jack)] [recsrc: vol, mic] pcm0: | pcm0: + <- nid=25 [pin: Mic in (fixed)] [recsrc: vol, mic] pcm0: | pcm0: + <- nid=26 [pin: line in (jack)] [recsrc: vol, line] pcm0: | pcm0: + <- nid=20 [pin: headphones out (jack)] pcm0: | pcm0: + <- nid=21 [pin: line out (fixed)] pcm0: | pcm0: + <- nid=11 [audio mixer] [recsrc: vol, line, mic] pcm0: pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: PCM Playback: 1 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x000e0560 pcm0: PCM size: 16 20 24 pcm0: PCM rate: 11 22 44 48 pcm0: DAC: 2 3 4 5 37 pcm0: pcm0: PCM Record: 1 pcm0: Stream cap: 0x00000001 pcm0: Format: PCM pcm0: PCM cap: 0x00060160 pcm0: PCM size: 16 20 pcm0: PCM rate: 22 44 48 pcm0: ADC: 8 9 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init Linux ELF exec handler installed splash: image decoder found: daemon_saver acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0519: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-0610: *** Error: Method execution failed [\ \_SB_.PCI0.LPC0.EC0_.GBST] (Node 0xc2666b60), AE_NO_HARDWARE_RESPONSE ACPI-0610: *** Error: Method execution failed [\ \_SB_.PCI0.LPC0.EC0_.BAT0._BST] (Node 0xc2666a20), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery status -- AE_NO_HARDWARE_RESPONSE rl0: link state changed to DOWN rl0: link state changed to UP acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0519: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-0610: *** Error: Method execution failed [\ \_SB_.PCI0.LPC0.EC0_.GBST] (Node 0xc2666b60), AE_NO_HARDWARE_RESPONSE ACPI-0610: *** Error: Method execution failed [\ \_SB_.PCI0.LPC0.EC0_.BAT0._BST] (Node 0xc2666a20), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery status -- AE_NO_HARDWARE_RESPONSE From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 13:58:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC43216A403; Sat, 18 Nov 2006 13:58:37 +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 15D9943D45; Sat, 18 Nov 2006 13:58:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAIDwa2f011354; Sat, 18 Nov 2006 08:58:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAIDwa8k038417; Sat, 18 Nov 2006 08:58:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8203D73068; Sat, 18 Nov 2006 08:58:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061118135836.8203D73068@freebsd-current.sentex.ca> Date: Sat, 18 Nov 2006 08:58:36 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 13:58:38 -0000 TB --- 2006-11-18 12:46:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-18 12:46:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-11-18 12:46:59 - cleaning the object tree TB --- 2006-11-18 12:48:26 - checking out the source tree TB --- 2006-11-18 12:48:26 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-11-18 12:48:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-18 13:05:02 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-18 13:05:02 - cd /src TB --- 2006-11-18 13:05:02 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 18 13:05:03 UTC 2006 >>> 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 Sat Nov 18 13:58:35 UTC 2006 TB --- 2006-11-18 13:58:35 - generating LINT kernel config TB --- 2006-11-18 13:58:35 - cd /src/sys/sun4v/conf TB --- 2006-11-18 13:58:35 - /usr/bin/make -B LINT TB --- 2006-11-18 13:58:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-18 13:58:35 - cd /src TB --- 2006-11-18 13:58:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 18 13:58:35 UTC 2006 >>> stage 1: configuring the kernel [...] config: 1 errors WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-18 13:58:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-18 13:58:36 - ERROR: failed to build lint kernel TB --- 2006-11-18 13:58:36 - tinderbox aborted TB --- 0.55 user 2.11 system 4296.42 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 15:59:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D66C816A407; Sat, 18 Nov 2006 15:59:55 +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 9AC9543D46; Sat, 18 Nov 2006 15:59:51 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAIFxsnb058420; Sat, 18 Nov 2006 10:59:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAIFxsaX071856; Sat, 18 Nov 2006 10:59:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EAB7E73068; Sat, 18 Nov 2006 10:59:53 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061118155953.EAB7E73068@freebsd-current.sentex.ca> Date: Sat, 18 Nov 2006 10:59:53 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 15:59:56 -0000 TB --- 2006-11-18 14:25:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-18 14:25:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-11-18 14:25:01 - cleaning the object tree TB --- 2006-11-18 14:26:40 - checking out the source tree TB --- 2006-11-18 14:26:40 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-11-18 14:26:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-18 14:39:41 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-18 14:39:41 - cd /src TB --- 2006-11-18 14:39:41 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 18 14:39:42 UTC 2006 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Nov 18 15:57:54 UTC 2006 TB --- 2006-11-18 15:57:54 - generating LINT kernel config TB --- 2006-11-18 15:57:54 - cd /src/sys/amd64/conf TB --- 2006-11-18 15:57:54 - /usr/bin/make -B LINT TB --- 2006-11-18 15:57:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-18 15:57:54 - cd /src TB --- 2006-11-18 15:57:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 18 15:57:54 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding /src/sys/compat/linux/linux_getcwd.c:429:64: macro "ARGS" passed 4 arguments, but takes just 2 mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-18 15:59:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-18 15:59:53 - ERROR: failed to build lint kernel TB --- 2006-11-18 15:59:53 - tinderbox aborted TB --- 0.98 user 3.37 system 5692.63 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 16:44:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD83516A47C; Sat, 18 Nov 2006 16:44:51 +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 1326443D72; Sat, 18 Nov 2006 16:44:44 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAIGilQL061982; Sat, 18 Nov 2006 11:44:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAIGilhm085669; Sat, 18 Nov 2006 11:44:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5BC7D73068; Sat, 18 Nov 2006 11:44:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061118164447.5BC7D73068@freebsd-current.sentex.ca> Date: Sat, 18 Nov 2006 11:44:47 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 16:44:52 -0000 TB --- 2006-11-18 15:35:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-18 15:35:59 - starting HEAD tinderbox run for i386/i386 TB --- 2006-11-18 15:35:59 - cleaning the object tree TB --- 2006-11-18 15:36:59 - checking out the source tree TB --- 2006-11-18 15:36:59 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-11-18 15:36:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-18 15:47:10 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-18 15:47:10 - cd /src TB --- 2006-11-18 15:47:10 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 18 15:47:12 UTC 2006 >>> 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 Sat Nov 18 16:42:35 UTC 2006 TB --- 2006-11-18 16:42:35 - generating LINT kernel config TB --- 2006-11-18 16:42:35 - cd /src/sys/i386/conf TB --- 2006-11-18 16:42:35 - /usr/bin/make -B LINT TB --- 2006-11-18 16:42:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-18 16:42:35 - cd /src TB --- 2006-11-18 16:42:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 18 16:42:36 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 /src/sys/compat/linux/linux_getcwd.c:429:64: macro "ARGS" passed 4 arguments, but takes just 2 mkdep: compile failed *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-18 16:44:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-18 16:44:47 - ERROR: failed to build lint kernel TB --- 2006-11-18 16:44:47 - tinderbox aborted TB --- 0.88 user 2.74 system 4127.90 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 17:08:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56AA316A4A0; Sat, 18 Nov 2006 17:08:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A57D543D5A; Sat, 18 Nov 2006 17:08:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAIH8SUo063499; Sat, 18 Nov 2006 12:08:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAIH8Rh2030867; Sat, 18 Nov 2006 12:08:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BB06573068; Sat, 18 Nov 2006 12:08:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061118170827.BB06573068@freebsd-current.sentex.ca> Date: Sat, 18 Nov 2006 12:08:27 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 17:08:38 -0000 TB --- 2006-11-18 15:59:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-18 15:59:54 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-11-18 15:59:54 - cleaning the object tree TB --- 2006-11-18 16:00:25 - checking out the source tree TB --- 2006-11-18 16:00:25 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-11-18 16:00:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-18 16:11:24 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-18 16:11:24 - cd /src TB --- 2006-11-18 16:11:24 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 18 16:11:26 UTC 2006 >>> 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 Sat Nov 18 17:06:41 UTC 2006 TB --- 2006-11-18 17:06:41 - generating LINT kernel config TB --- 2006-11-18 17:06:41 - cd /src/sys/pc98/conf TB --- 2006-11-18 17:06:41 - /usr/bin/make -B LINT TB --- 2006-11-18 17:06:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-11-18 17:06:41 - cd /src TB --- 2006-11-18 17:06:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 18 17:06:41 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=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 /src/sys/compat/linux/linux_getcwd.c:429:64: macro "ARGS" passed 4 arguments, but takes just 2 mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-18 17:08:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-18 17:08:27 - ERROR: failed to build lint kernel TB --- 2006-11-18 17:08:27 - tinderbox aborted TB --- 0.74 user 2.76 system 4113.36 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 17:22:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 963CE16A415; Sat, 18 Nov 2006 17:22:00 +0000 (UTC) (envelope-from csjp@FreeBSD.ORG) Received: from ems01.seccuris.com (ems01.seccuris.com [204.112.0.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9458043D53; Sat, 18 Nov 2006 17:21:47 +0000 (GMT) (envelope-from csjp@FreeBSD.ORG) Received: from [10.8.0.2] (unknown [10.8.0.2]) by ems01.seccuris.com (Postfix) with ESMTP id 46D2E462E5C; Sat, 18 Nov 2006 12:22:30 -0600 (CST) Message-ID: <455F4120.4060607@FreeBSD.ORG> Date: Sat, 18 Nov 2006 11:21:36 -0600 From: "Christian S.J. Peron" User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Andrew Thompson , current@freebsd.org References: <20061116232450.GA16087@heff.fud.org.nz> In-Reply-To: <20061116232450.GA16087@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: audit records X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2006 17:22:00 -0000 Andrew, 'localhost' does not resolve to 127.0.0.1 by default, instead it will resolve to ::1 (IPv6). Currently, we are using just a regular subject token which only supports IPv4 tokens, when we should be using subject_ex which allows us to have an IPv6 address for termid. I have some patches that add support for extended subject tokens in the kernel, but there are a few bugs to work through yet, but I am optimistic we can remedy this soon. Thanks! Andrew Thompson wrote: > Hi, > > > I thought i'd try out the new audit system and simulate an invalid login. > I was suprised to see that ssh connections to localhost show up as > 255.255.255.255, is this an error? > > % ssh df@localhost > header,94,10,OpenSSH login,0,Fri Nov 17 12:16:44 2006, + 100 msec > subject,-1,-1,-1,-1,-1,1378,1378,60666,255.255.255.255 > text,invalid user name "df" > return,failure : No such process,4294967295 > trailer,94 > > % ssh df@192.168.0.182 > header,95,10,OpenSSH login,0,Fri Nov 17 12:17:26 2006, + 892 msec > subject,-1,-1,-1,-1,-1,1385,1385,58511,192.168.0.182 > text,invalid user name "df" > return,failure : No such process,4294967295 > trailer,95 > > > > Andrew > _______________________________________________ > 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 Nov 18 20:45:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AC7916A415 for ; Sat, 18 Nov 2006 20:45:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A39643D5D for ; Sat, 18 Nov 2006 20:45:30 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [127.0.0.1] (localhost.cse.buffalo.edu [127.0.0.1]) by opus.cse.buffalo.edu (8.13.8/8.12.4) with ESMTP id kAIKjYJK091004 for ; Sat, 18 Nov 2006 15:45:35 -0500 (EST) From: Ken Smith To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DpgjkzL12N4P+sW53Ycq" Organization: U. Buffalo CSE Department Date: Sat, 18 Nov 2006 15:45:34 -0500 Message-Id: <1163882734.89154.18.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Subject: November HEAD Snapshots available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 20:45:36 -0000 --=-DpgjkzL12N4P+sW53Ycq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =46rom the "better late than never" Department... Sorry I think I got distracted by 6.2-RELEASE stuff at the wrong time and forgot to announce that November's HEAD snapshots are available. They've been on the FTP sites for quite a while now. ISOs are available at the "predictable" place: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200611/ Checksums: MD5 (7.0-CURRENT-200611-amd64-bootonly.iso) =3D 65effe95d81f17aa0f097affbac= 203ee MD5 (7.0-CURRENT-200611-amd64-disc1.iso) =3D b7196d68476be62ffc1188a407a250= 60 MD5 (7.0-CURRENT-200611-amd64-disc2.iso) =3D 778c777b943d2a0b4ef5c50f8c6174= 24 MD5 (7.0-CURRENT-200611-i386-bootonly.iso) =3D deb1ef612404cb9f37f55cba4380= d605 MD5 (7.0-CURRENT-200611-i386-disc1.iso) =3D a73841430c9d5c2477be0581423e9ea= b MD5 (7.0-CURRENT-200611-i386-disc2.iso) =3D 8114c9525d2eadbe3b49bc70b1dfe73= 2 MD5 (7.0-CURRENT-200611-ia64-bootonly.iso) =3D c97cf7c28541708a1f36950c887a= bf88 MD5 (7.0-CURRENT-200611-ia64-disc1.iso) =3D 8ae9503c7bb8b2628213187c6925b65= d MD5 (7.0-CURRENT-200611-ia64-livefs.iso) =3D 92b2cc021e32353350353286d5e7dc= 1b MD5 (7.0-CURRENT-200611-pc98-bootonly.iso) =3D 3d008c13ac26f54b7f9d66d8aaf7= 3153 MD5 (7.0-CURRENT-200611-pc98-disc1.iso) =3D e42d237fcb9a3a8c936f2ca9bf8176c= 5 MD5 (7.0-CURRENT-200611-powerpc-bootonly.iso) =3D 2bf10e5b8d3dd02c7d4b3a471= cf12292 MD5 (7.0-CURRENT-200611-powerpc-disc1.iso) =3D 0394ad063f078100bb1e8fd67d20= 05d8 SHA256 (7.0-CURRENT-200611-amd64-bootonly.iso) =3D 4e0e38e971463897c3be66f3= 2cb3f8dd5edd20d309eeff92843ba757809cb45b SHA256 (7.0-CURRENT-200611-amd64-disc1.iso) =3D 1c90711466f0a5c1a5a8b950c02= 17f276437129b3265dbfb82aba21fabc7c02d SHA256 (7.0-CURRENT-200611-amd64-disc2.iso) =3D cd3c0dd0ff5dcea0a9f2e355701= 2f6c80c2d2aaf5cea1a97d2191ed5041ce389 SHA256 (7.0-CURRENT-200611-i386-bootonly.iso) =3D 382a787e9aae4e5811e4b3f51= e2b7e879b1158aa55141833cda5ce4514a19024 SHA256 (7.0-CURRENT-200611-i386-disc1.iso) =3D eabadf289a286752aa2feae425bf= c2619cf21ed08e4cf12f070473de53c9486a SHA256 (7.0-CURRENT-200611-i386-disc2.iso) =3D 473169bbd86519c6287bd38c98b5= c002bbf4b3afa1287e95f149525ff2268aa9 SHA256 (7.0-CURRENT-200611-ia64-bootonly.iso) =3D 8827fe85bad454fd09b95d625= 81594040b40b5ebb81d2484ac9b6c510c67e29b SHA256 (7.0-CURRENT-200611-ia64-disc1.iso) =3D f640a4cd384f35e1be94c7d2ef13= 5b8405c87f54fbd39c8ad01eeb1a7392b9c5 SHA256 (7.0-CURRENT-200611-ia64-livefs.iso) =3D 08360c964b6685fd9d2fb744eef= f84203ea12c28669fcef34cf298aca97ecd49 SHA256 (7.0-CURRENT-200611-pc98-bootonly.iso) =3D 2258639632be44ed32aa40339= ab545627558a5c2a302fb3b86da836c8e73dab9 SHA256 (7.0-CURRENT-200611-pc98-disc1.iso) =3D 8e5f9dc90dfe21977f28dd83f30e= ebb68d59f0235fd9f4e1d5f70d3019e74e80 SHA256 (7.0-CURRENT-200611-powerpc-bootonly.iso) =3D 7b699599caa1207dc9f5fc= cd26875a19b9fe6318ece83ea60b3bf148080c67d0 SHA256 (7.0-CURRENT-200611-powerpc-disc1.iso) =3D b0d560902232219c44c6a5c61= 29005d4f7224081515150b22db46c353396ab07 --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-DpgjkzL12N4P+sW53Ycq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFX3Du/G14VSmup/YRAp/2AJ0dQAmkRZDHMFJ/qDx32GjlnXoz9wCcDw0K C4SZrnNvZ7qVRA2QNaudxi4= =8iAm -----END PGP SIGNATURE----- --=-DpgjkzL12N4P+sW53Ycq-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 20:58:05 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03AE516A415; Sat, 18 Nov 2006 20:58:05 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F5C343D49; Sat, 18 Nov 2006 20:57:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 80B1D1A4D84; Sat, 18 Nov 2006 12:58:04 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 752E2513FB; Sat, 18 Nov 2006 15:57:51 -0500 (EST) Date: Sat, 18 Nov 2006 15:57:51 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20061118205751.GA41726@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: jb@FreeBSD.org, mjacob@FreeBSD.org, jhb@FreeBSD.org Subject: mpt broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2006 20:58:05 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline After updating to recent current mpt is broken on this amd64 machine: mpt0: port 0x4000-0x40ff mem 0xf1110000-0xf111ffff,0xf1100000-0xf110ffff irq 29 at device 1.0 on pci14 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 mpt1: port 0x4400-0x44ff mem 0xf1130000-0xf113ffff,0xf1120000-0xf112ffff irq 30 at device 1.1 on pci14 mpt1: [GIANT-LOCKED] mpt1: MPI Version=1.2.12.0 ... Waiting 3 seconds for SCSI devices to settle mpt0: request 0xffffffff80a39050:96 timed out for ccb 0xffffff03e127a800 (req->ccb 0xffffff03e127a800) mpt1: request 0xffffffff80a47050:96 timed out for ccb 0xffffff03e124ac00 (req->ccb 0xffffff03e124ac00) mpt0: completing timedout/aborted req 0xffffffff80a39050:96 mpt0: Timedout requests already complete. Interrupts may not be functioning. mpt1: completing timedout/aborted req 0xffffffff80a47050:96 mpt1: Timedout requests already complete. Interrupts may not be functioning. mpt0: request 0xffffffff80a39100:98 timed out for ccb 0xffffff03e127a800 (req->ccb 0xffffff03e127a800) Kris --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFX3POWry0BWjoQKURAkQHAJ4sVyX5ETkdv09Ql4spFeAJiAYtagCcDvhr RQqgWMA+RSQDsC23+ooyAwg= =ro5M -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 21:20:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8194016A47E; Sat, 18 Nov 2006 21:20:23 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA4843D80; Sat, 18 Nov 2006 21:20:12 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id kAILK6Er035749; Sat, 18 Nov 2006 13:20:16 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id kAILK62o035746; Sat, 18 Nov 2006 13:20:06 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 18 Nov 2006 13:20:06 -0800 (PST) From: mjacob@freebsd.org X-X-Sender: mjacob@ns1.feral.com To: Kris Kennaway In-Reply-To: <20061118205751.GA41726@xor.obsecurity.org> Message-ID: <20061118131834.H35732@ns1.feral.com> References: <20061118205751.GA41726@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jb@freebsd.org, current@freebsd.org Subject: Re: mpt broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@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: Sat, 18 Nov 2006 21:20:23 -0000 Set hw.pci.msi.enable=0 hw.pci.msix.enable=0 and then get back to me if it doesn't work. > After updating to recent current mpt is broken on this amd64 machine: > > mpt0: port 0x4000-0x40ff mem 0xf1110000-0xf111ffff,0xf1100000-0xf110ffff irq 29 at device 1.0 on pci14 > mpt0: [GIANT-LOCKED] > mpt0: MPI Version=1.2.12.0 > mpt1: port 0x4400-0x44ff mem 0xf1130000-0xf113ffff,0xf1120000-0xf112ffff irq 30 at device 1.1 on pci14 > mpt1: [GIANT-LOCKED] > mpt1: MPI Version=1.2.12.0 > ... > Waiting 3 seconds for SCSI devices to settle > mpt0: request 0xffffffff80a39050:96 timed out for ccb 0xffffff03e127a800 (req->ccb 0xffffff03e127a800) > mpt1: request 0xffffffff80a47050:96 timed out for ccb 0xffffff03e124ac00 (req->ccb 0xffffff03e124ac00) > mpt0: completing timedout/aborted req 0xffffffff80a39050:96 > mpt0: Timedout requests already complete. Interrupts may not be functioning. > mpt1: completing timedout/aborted req 0xffffffff80a47050:96 > mpt1: Timedout requests already complete. Interrupts may not be functioning. > mpt0: request 0xffffffff80a39100:98 timed out for ccb 0xffffff03e127a800 (req->ccb 0xffffff03e127a800) > > Kris > From owner-freebsd-current@FreeBSD.ORG Sat Nov 18 23:23:27 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE39716A417 for ; Sat, 18 Nov 2006 23:23:27 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E33643D62 for ; Sat, 18 Nov 2006 23:23:20 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id EFA0588A6 for ; Sun, 19 Nov 2006 00:23:23 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 6E9C89B46E for ; Sat, 18 Nov 2006 23:23:52 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 50A48405B; Sun, 19 Nov 2006 00:23:52 +0100 (CET) Date: Sun, 19 Nov 2006 00:23:52 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20061118232352.GX20405@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: My bge(4) adapter don't work without device apic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Nov 2006 23:23:28 -0000 Hi, whenever I remove apic(4) from my kernel configuration file, my bge(4) adapter stops working and I have many watchdog timeout on it. INTERRUPTS: jarjarbinks:~:103# vmstat -i interrupt total rate irq1: atkbd0 49417 0 irq9: acpi0 86798 0 irq12: psm0 7809 0 irq14: ata0 344664 2 irq16: bge0 uhci3 480437 3 irq18: cbb0 uhci2+ 1 0 cpu0: timer 286195901 1999 Total 287165027 2006 DMESG: Copyright (c) 1992-2006 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 #2: Thu Nov 16 02:30:34 UTC 2006 root@jarjarbinks.octobre.int:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. module_register: module pci/bge already exists! Module pci/bge failed to register: 17 module_register: module bge/miibus already exists! Module bge/miibus failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.73GHz (1729.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 1072168960 (1022 MB) avail memory = 1035677696 (987 MB) ACPI APIC Table: ACPI-0390: *** Info: Table [SSDT] replaced by host OS ACPI-0390: *** Info: Table [SSDT] replaced by host OS ACPI-0390: *** Info: Table [SSDT] replaced by host OS ACPI: overriding DSDT/SSDT with custom table ACPI-0390: *** Info: Table [DSDT] replaced by host OS ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) unknown: I/O range not supported 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_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xc8100000-0xc810ffff irq 16 at device 0.0 on pci1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci10: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci2: on pcib4 uhci0: port 0x1800-0x181f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xc8000000-0xc80003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pci6: on pcib5 pci6:8:0: bad VPD cksum, remain 14 cbb0: mem 0xc8216000-0xc8216fff irq 18 at device 1.0 on pci6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xc8217000-0xc82177ff,0xc8210000-0xc8213fff irq 18 at device 1.2 on pci6 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:c0:9f:00:00:4b:f0:82 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:c0:9f:4b:f0:82 fwe0: Ethernet address: 02:c0:9f:4b:f0:82 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci6: at device 1.3 (no driver attached) pci6: at device 3.0 (no driver attached) bge0: mem 0xc8200000-0xc820ffff irq 16 at device 8.0 on pci6 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:c0:9f:94:39:8f pci0: at device 30.2 (no driver attached) pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 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 sio0 port 0x2f8-0x2ff irq 3 drq 1 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcdfff,0xce000-0xcf7ff,0xe0000-0xe17ff 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 Timecounter "TSC" frequency 1729012044 Hz quality 800 Timecounters tick every 1.000 msec ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 76319MB at ata0-master UDMA33 acd0: DVDR at ata0-slave UDMA33 cpu0: Cx states changed cpu0: Cx states changed cpu0: Cx states changed Trying to mount root from ufs:/dev/ad0s1a bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >